[gentoo-dev] [PATCH] distutils-r1.eclass: Permit DISTUTILS_USE_SETUPTOOLS=manual
Add a new DISTUTILS_USE_SETUPTOOLS option to permit manually setting
the dependencies correctly and suppressing the check.
Requested by Arfrever.
Signed-off-by: Michał Górny
---
eclass/distutils-r1.eclass | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index fae25ea8a5ec..65294a065da7 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: distutils-r1.eclass
@@ -86,6 +86,8 @@ esac
# - no -- do not add the dependency (pure distutils package)
# - bdepend -- add it to BDEPEND (the default)
# - rdepend -- add it to BDEPEND+RDEPEND (when using entry_points)
+# - manual -- do not add the depedency and suppress the checks
+# (assumes you will take care of doing it correctly)
#
# This variable is effective only if DISTUTILS_OPTIONAL is disabled.
# It needs to be set before the inherit line.
@@ -116,7 +118,7 @@ _distutils_set_globals() {
local bdep=${rdep}
case ${DISTUTILS_USE_SETUPTOOLS} in
- no)
+ no|manual)
;;
bdepend)
bdep+=" dev-python/setuptools[${PYTHON_USEDEP}]"
@@ -436,6 +438,7 @@ distutils_enable_tests() {
# incorrectly.
_distutils_verify_use_setuptools() {
[[ ${DISTUTILS_OPTIONAL} ]] && return
+ [[ ${DISTUTILS_USE_SETUPTOOLS} == manual ]] && return
# ok, those are cheap greps. we can try toimprove them if we hit
# false positives.
--
2.24.1
Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation
> On Fri, 20 Dec 2019, Michael Orlitzky wrote: > Portage seems OK with the missing dependency, but for the overall plan > to work, you have to wait a long time before deleting virtual/emacs; > otherwise the upgrade path is broken. With virtual/emacs-26 installed > and "old" copies of the elisp ebuilds installed, you get unsatisfied > dependencies switching from emacs-vcs to a live slot of emacs. Everyone > in that situation must update to virtual/emacs-26-r1, which they can't > do after you delete it. > And of course you can't mask virtual/emacs in the meantime, because that > does kill the PM. I have no plans of masking the virtual. It will be simply removed, presumably after the app-editors/emacs-27.1 release (at which point any emacs-vcs-27.0* will be outdated, and be blocked against by the ebuild). > New revisions would still be the sane solution, now and in the future, > because they don't require investigative journalism to uncover exactly > what might go wrong when we bend the rules /this time/. They also don't > impose a cutoff date after which upgrading users are screwed. You just > automate the revbumps, commit them all at once, and make a pull request > against CI to verify that nothing is too borked. See? You say it yourself, with 400 revbumps there is quite some chance for breakage. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 3/3] elisp.eclass: Depend on app-editors/emacs directly.
> -RDEPEND=">=virtual/emacs-${NEED_EMACS:-23}"
> +RDEPEND=">=app-editors/emacs-${NEED_EMACS}:*"
... and of course, the slot operator isn't legal in EAPI 4. It is
trivial to fix, so I won't send a v3 for this.
signature.asc
Description: PGP signature
Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies
On Sat, 2019-12-21 at 08:21 +1300, Kent Fredric wrote: > On Fri, 20 Dec 2019 13:54:44 -0500 > Mike Gilbert wrote: > > > Yes, I think you misunderstand something, but I'm not sure exactly how. > > I think the missing part of my understanding might be that IDEPEND > needs to be satisfied by: > > - Packages installing binpkg's ( which don't need src_fetch, unpack, etc ) > - Package managers *removing* packages. > > As in, if a package declares IDEPEND="foo" > > And "foo" is not available when asking portage to "emerge -C bar" > > Portage must demand that "foo" is reinstalled to allow "bar" to be > removed ( as foo needs to be there to complete pkg_*rm ) > > This probably gonna make package manager fun :) Hence, ebuilds will need to account for the dependencies actually being missing in pkg_*rm. And the package managers must not implement proactive depcleaning of IDEPEND. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies
On Fri, 20 Dec 2019 13:54:44 -0500 Mike Gilbert wrote: > Yes, I think you misunderstand something, but I'm not sure exactly how. I think the missing part of my understanding might be that IDEPEND needs to be satisfied by: - Packages installing binpkg's ( which don't need src_fetch, unpack, etc ) - Package managers *removing* packages. As in, if a package declares IDEPEND="foo" And "foo" is not available when asking portage to "emerge -C bar" Portage must demand that "foo" is reinstalled to allow "bar" to be removed ( as foo needs to be there to complete pkg_*rm ) This probably gonna make package manager fun :) pgpF1V5i90ZMq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies
On Fri, Dec 20, 2019 at 1:41 PM Kent Fredric wrote: > > On Thu, 19 Dec 2019 20:40:26 +0100 > Michał Górny wrote: > > > The proposal is to add a new dependency type (codename: IDEPEND) which > > indicates dependencies used for pkg_*inst (and pkg_*rm?) phases > > Given the nature of this, I somewhat expect this to cover dependencies > required for src_unpack and src_fetch, and possibly src_prepare > > Am I misunderstanding? Yes, I think you misunderstand something, but I'm not sure exactly how. Tools used during src_unpack and src_prepare are generally covered by BDEPEND. src_fetch isn't formally defined yet, but probably needs its own dependency class if BDEPEND wont cover it.
Re: [gentoo-dev] [PATCH] virtualx.eclass: Append RESTRICT="!test? ( test )" by default
On Fri, 13 Dec 2019 12:50:00 +0100 Alexis Ballier wrote: > Seems a good candidate for a future EAPI In theory, there are packages that can execute src_test when USE="test" is not satisfied. Just I don't tend to see this in practice. pgpOyg14m2iTZ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies
On Thu, 19 Dec 2019 20:40:26 +0100 Michał Górny wrote: > The proposal is to add a new dependency type (codename: IDEPEND) which > indicates dependencies used for pkg_*inst (and pkg_*rm?) phases Given the nature of this, I somewhat expect this to cover dependencies required for src_unpack and src_fetch, and possibly src_prepare Am I misunderstanding? pgp0Q3rMWHAxO.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies
On Fri, 2019-12-20 at 18:55 +0100, Ulrich Mueller wrote: > > > > > > On Fri, 20 Dec 2019, Alexis Ballier wrote: > > Should we use this to drop RDEPEND from pkg_*inst/rm phases ? > > PMS states "RDEPEND (unless the particular dependency results in a > > circular dependency, in which case it may be installed later)" > > which is > > kind of "maybe maybe not" and I'm not sure how one can rely on > > RDEPEND > > for those phases in their ebuilds if another random ebuild can > > trigger > > a case where it's not satisfied. > > This wording has already been updated in git. It just says "RDEPEND" > now > for these four phases: > > https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-720008.1 > > Ok. My question still stands though, so that we can avoid mutual RDEPEND cycles and also, as you noted on the bug, in a x-compile setting, CHOST deps are not really needed at installation.
Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies
> On Fri, 20 Dec 2019, Alexis Ballier wrote: > Should we use this to drop RDEPEND from pkg_*inst/rm phases ? > PMS states "RDEPEND (unless the particular dependency results in a > circular dependency, in which case it may be installed later)" which is > kind of "maybe maybe not" and I'm not sure how one can rely on RDEPEND > for those phases in their ebuilds if another random ebuild can trigger > a case where it's not satisfied. This wording has already been updated in git. It just says "RDEPEND" now for these four phases: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-720008.1 Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies
On Thu, 2019-12-19 at 20:40 +0100, Michał Górny wrote:
> Hello,
>
> Here's another potential EAPI 8 feature I'd like to discuss. Please
> note that this is about *new dependency type*, so please don't hijack
> it
> into the big 'let's steal Exherbo syntax' debate.
>
> Bug: https://bugs.gentoo.org/660306
>
>
> The problem
> ===
>
> Right now we don't really have a clean way of specifying dependencies
> that are used during pkg_*inst (and pkg_*rm?) phases. So far RDEPEND
> was used as a 'close enough' alternative (except for a few developers
> who rejected it as 'invalid' and used DEPEND which is even more
> wrong).
> However, this is no longer sufficient with EAPI 7 cross support.
>
> By design, pkg_*inst phases are run in build host's environment when
> cross is used (because obviously you can't run target host
> executables).
> Therefore, the relevant dependencies need to be installed into CBUILD
> root, while RDEPEND is installed into CHOST root.
>
>
> The proposed solution
> =
>
> The proposal is to add a new dependency type (codename: IDEPEND)
> which
> indicates dependencies used for pkg_*inst (and pkg_*rm?)
> phases. Those
> dependencies would be installed into CBUILD root (like BDEPEND), and
> therefore would be runnable from build host. Similarly to RDEPEND,
> they
> would be installed for binary package installs but not for pure
> binpkg
> builds (without install).
>
> Example:
>
> inherit xdg-utils
>
> IDEPEND="dev-util/desktop-file-utils"
>
> pkg_postinst() {
> xdg_desktop_database_update
> }
>
>
> WDYT?
>
Should we use this to drop RDEPEND from pkg_*inst/rm phases ?
PMS states "RDEPEND (unless the particular dependency results in a
circular dependency, in which case it may be installed later)" which is
kind of "maybe maybe not" and I'm not sure how one can rely on RDEPEND
for those phases in their ebuilds if another random ebuild can trigger
a case where it's not satisfied.
Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies
On Thu, Dec 19, 2019 at 2:40 PM Michał Górny wrote:
>
> Hello,
>
> Here's another potential EAPI 8 feature I'd like to discuss. Please
> note that this is about *new dependency type*, so please don't hijack it
> into the big 'let's steal Exherbo syntax' debate.
>
> Bug: https://bugs.gentoo.org/660306
>
>
> The problem
> ===
>
> Right now we don't really have a clean way of specifying dependencies
> that are used during pkg_*inst (and pkg_*rm?) phases. So far RDEPEND
> was used as a 'close enough' alternative (except for a few developers
> who rejected it as 'invalid' and used DEPEND which is even more wrong).
> However, this is no longer sufficient with EAPI 7 cross support.
>
> By design, pkg_*inst phases are run in build host's environment when
> cross is used (because obviously you can't run target host executables).
> Therefore, the relevant dependencies need to be installed into CBUILD
> root, while RDEPEND is installed into CHOST root.
>
>
> The proposed solution
> =
>
> The proposal is to add a new dependency type (codename: IDEPEND) which
> indicates dependencies used for pkg_*inst (and pkg_*rm?) phases. Those
> dependencies would be installed into CBUILD root (like BDEPEND), and
> therefore would be runnable from build host. Similarly to RDEPEND, they
> would be installed for binary package installs but not for pure binpkg
> builds (without install).
>
> Example:
>
> inherit xdg-utils
>
> IDEPEND="dev-util/desktop-file-utils"
>
> pkg_postinst() {
> xdg_desktop_database_update
> }
>
>
> WDYT?
Sounds good to me.
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On Fri, Dec 20, 2019 at 8:41 AM Gerion Entrup wrote: > > Am Donnerstag, 19. Dezember 2019, 19:43:37 CET schrieb Sebastian Pipping: > > On 19.12.19 18:37, Michał Górny wrote: > > > We have a better alternative that lets us limit the impact on the users. > > > Why not use it? > > > > Which one? The CMake bootstrap copy? The adding to stage3 one? > > If an error message can be shown, maybe this is enough as a hint: > "expat and cmake have circular dependencies. Emerge it the first time with: > USE=bundled-cmake emerge -1 cmake expat > and then just don't care anymore about this use flag." > Not sure about custom error messages but in any case when using that bundled-cmake USE flag it would probably make sense to do an ewarn that the bundling took place and is only intended for temporary use, and that the package should be re-merged without the flag once expat is working. That would also cover users who inadvertently set the flag. I think that bundled-cmake also might make more sense than system-cmake, even though the latter is more established. We have a lot of users who set USE=-* and that means they're going to end up with lots of stuff bundled that doesn't need to be. I'm no fan of USE=-* in general but it seems like we should try to avoid making not setting a USE flag the less secure option since it does happen a lot. I'm just commenting on the USE-based solution. The compat package solution obviously bypasses this particular problem entirely. -- Rich
[gentoo-dev] [PATCH v2 3/3] elisp.eclass: Depend on app-editors/emacs directly.
This replaces the indirect dependency on virtual/emacs.
Update pkg_setup() to call elisp-check-emacs-version instead of the
now deprecated elisp-need-emacs.
Signed-off-by: Ulrich Müller
---
eclass/elisp.eclass | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/eclass/elisp.eclass b/eclass/elisp.eclass
index df160ea01e2..2b50111a535 100644
--- a/eclass/elisp.eclass
+++ b/eclass/elisp.eclass
@@ -30,8 +30,8 @@
# @DEFAULT_UNSET
# @DESCRIPTION:
# If you need anything different from Emacs 23, use the NEED_EMACS
-# variable before inheriting elisp.eclass. Set it to the major version
-# your package uses and the dependency will be adjusted.
+# variable before inheriting elisp.eclass. Set it to the version your
+# package uses and the dependency will be adjusted.
# @ECLASS-VARIABLE: ELISP_PATCHES
# @DEFAULT_UNSET
@@ -70,7 +70,7 @@ esac
EXPORT_FUNCTIONS src_{unpack,prepare,configure,compile,install} \
pkg_{setup,postinst,postrm}
-RDEPEND=">=virtual/emacs-${NEED_EMACS:-23}"
+RDEPEND=">=app-editors/emacs-${NEED_EMACS}:*"
case ${EAPI} in
4|5|6) DEPEND="${RDEPEND}" ;;
*) BDEPEND="${RDEPEND}" ;;
@@ -78,16 +78,11 @@ esac
# @FUNCTION: elisp_pkg_setup
# @DESCRIPTION:
-# Test if the eselected Emacs version is sufficient to fulfil the major
+# Test if the eselected Emacs version is sufficient to fulfil the
# version requirement of the NEED_EMACS variable.
elisp_pkg_setup() {
- elisp-need-emacs "${NEED_EMACS:-23}"
- case $? in
- 0) ;;
- 1) die "Emacs version too low" ;;
- *) die "Could not determine Emacs version" ;;
- esac
+ elisp-check-emacs-version
}
# @FUNCTION: elisp_src_unpack
--
2.24.1
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH v2 1/3] elisp-common.eclass: New function elisp-check-emacs-version.
Tests if the Emacs version is at least the (full) version specified
by NEED_EMACS, otherwise dies. Intended as a replacement for function
elisp-need-emacs, which did only a simple numeric comparison of the
major version.
Call the new function before doing any actual work in elisp-compile()
and elisp-make-autoload-file(), so ebuilds inheriting only
elisp-common.eclass (but not elisp.eclass) won't have to add a
pkg_setup phase function.
Drop support for EAPIs 0 to 3.
Signed-off-by: Ulrich Müller
---
v2: Don't change elisp-need-emacs() in place, but add a new function
for the new functionality, and and deprecate the old function.
eclass/elisp-common.eclass | 52 +-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index 05b03f49395..8e5d70046bc 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: elisp-common.eclass
@@ -156,6 +156,12 @@
# environment, so it is no problem when you unset USE=emacs between
# merge and unmerge of a package.
+case ${EAPI:-0} in
+ 4|5|6) inherit eapi7-ver ;;
+ 7) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
# @ECLASS-VARIABLE: SITELISP
# @DESCRIPTION:
# Directory where packages install Emacs Lisp files.
@@ -182,6 +188,17 @@ EMACSFLAGS="-batch -q --no-site-file"
# Emacs flags used for byte-compilation in elisp-compile().
BYTECOMPFLAGS="-L ."
+# @ECLASS-VARIABLE: NEED_EMACS
+# @DESCRIPTION:
+# The minimum Emacs version required for the package.
+: ${NEED_EMACS:=23.1}
+
+# @ECLASS-VARIABLE: _ELISP_EMACS_VERSION
+# @INTERNAL
+# @DESCRIPTION:
+# Cached value of Emacs version detected in elisp-check-emacs-version().
+_ELISP_EMACS_VERSION=""
+
# @FUNCTION: elisp-emacs-version
# @RETURN: exit status of Emacs
# @DESCRIPTION:
@@ -212,6 +229,35 @@ elisp-emacs-version() {
echo "${version}"
}
+# @FUNCTION: elisp-check-emacs-version
+# @USAGE: [version]
+# @DESCRIPTION:
+# Test if the eselected Emacs version is at least the version of
+# GNU Emacs specified in the NEED_EMACS variable, or die otherwise.
+
+elisp-check-emacs-version() {
+ if [[ -z ${_ELISP_EMACS_VERSION} ]]; then
+ local have_emacs
+ have_emacs=$(elisp-emacs-version) \
+ || die "Could not determine Emacs version"
+ elog "Emacs version: ${have_emacs}"
+ if [[ ${have_emacs} =~ XEmacs|Lucid ]]; then
+ die "XEmacs detected. This package needs GNU Emacs."
+ fi
+ # GNU Emacs versions have only numeric components.
+ if ! [[ ${have_emacs} =~ ^[0-9]+(\.[0-9]+)*$ ]]; then
+ die "Malformed version string: ${have_emacs}"
+ fi
+ _ELISP_EMACS_VERSION=${have_emacs}
+ fi
+
+ if ! ver_test "${_ELISP_EMACS_VERSION}" -ge "${NEED_EMACS}"; then
+ eerror "This package needs at least Emacs ${NEED_EMACS}."
+ eerror "Use \"eselect emacs\" to select the active version."
+ die "Emacs version too low"
+ fi
+}
+
# @FUNCTION: elisp-need-emacs
# @USAGE:
# @RETURN: 0 if true, 1 if false, 2 if trouble
@@ -249,6 +295,8 @@ elisp-need-emacs() {
# in case they require or load one another.
elisp-compile() {
+ elisp-check-emacs-version
+
ebegin "Compiling GNU Emacs Elisp files"
${EMACS} ${EMACSFLAGS} ${BYTECOMPFLAGS} -f batch-byte-compile "$@"
eend $? "elisp-compile: batch-byte-compile failed" || die
@@ -262,6 +310,8 @@ elisp-compile() {
elisp-make-autoload-file() {
local f="${1:-${PN}-autoloads.el}" null="" page=$'\f'
shift
+ elisp-check-emacs-version
+
ebegin "Generating autoload file for GNU Emacs"
cat >"${f}" <<-EOF
--
2.24.1
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH v2 2/3] elisp-common.eclass: Update documentation.
After the package split between emacs and emacs-vcs is gone, packages
can depend on app-editors/emacs directly.
Deprecate function elisp-need-emacs; ebuilds should assign variable
NEED_EMACS instead.
Signed-off-by: Ulrich Müller
---
eclass/elisp-common.eclass | 45 ++
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index 8e5d70046bc..aac50fc65f0 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -23,26 +23,25 @@
# When relying on the emacs USE flag, you need to add
#
# @CODE
-# emacs? ( virtual/emacs )
+# emacs? ( >=app-editors/emacs-23.1:* )
# @CODE
#
# to your DEPEND/RDEPEND line and use the functions provided here to
# bring the files to the correct locations.
#
-# If your package requires a minimum Emacs version, e.g. Emacs 24, then
-# the dependency should be on >=virtual/emacs-24 instead. Because the
-# user can select the Emacs executable with eselect, you should also
-# make sure that the active Emacs version is sufficient. This can be
-# tested with function elisp-need-emacs(), which would typically be
-# called from pkg_setup(), as in the following example:
+# If your package requires a minimum Emacs version, e.g. Emacs 26.1,
+# then the dependency should be on >=app-editors/emacs-26.1:* instead.
+# Because the user can select the Emacs executable with eselect, you
+# should also make sure that the active Emacs version is sufficient.
+# The eclass will automatically ensure this if you assign variable
+# NEED_EMACS with the Emacs version, as in the following example:
#
# @CODE
-# elisp-need-emacs 24 || die "Emacs version too low"
+# NEED_EMACS=26.1
# @CODE
#
-# Please note that such tests should be limited to packages that are
-# known to fail with lower Emacs versions; the standard case is to
-# depend on virtual/emacs without version.
+# Please note that this should be done only for packages that are known
+# to fail with lower Emacs versions.
#
# @ROFF .SS
# src_compile() usage:
@@ -134,6 +133,20 @@
# the differing name as second argument.
#
# @ROFF .SS
+# pkg_setup() usage:
+#
+# If your ebuild uses the elisp-compile eclass function to compile
+# its elisp files (see above), then you don't need a pkg_setup phase,
+# because elisp-compile and elisp-make-autoload-file do their own sanity
+# checks. On the other hand, if the elisp files are compiled by the
+# package's build system, then there is often no check for the Emacs
+# version. In this case, you can add an explicit check in pkg_setup:
+#
+# @CODE
+# elisp-check-emacs-version
+# @CODE
+#
+# @ROFF .SS
# pkg_postinst() / pkg_postrm() usage:
#
# After that you need to recreate the start-up file of Emacs after
@@ -151,10 +164,6 @@
#
# When having optional Emacs support, you should prepend "use emacs &&"
# to above calls of elisp-site-regen().
-# Don't use "has_version virtual/emacs"! When unmerging the state of
-# the emacs USE flag is taken from the package database and not from the
-# environment, so it is no problem when you unset USE=emacs between
-# merge and unmerge of a package.
case ${EAPI:-0} in
4|5|6) inherit eapi7-ver ;;
@@ -258,12 +267,10 @@ elisp-check-emacs-version() {
fi
}
-# @FUNCTION: elisp-need-emacs
-# @USAGE:
-# @RETURN: 0 if true, 1 if false, 2 if trouble
-# @DESCRIPTION:
# Test if the eselected Emacs version is at least the major version
# of GNU Emacs specified as argument.
+# Return 0 if true, 1 if false, 2 if trouble.
+# Deprecated, use elisp-check-emacs-version instead.
elisp-need-emacs() {
local need_emacs=$1 have_emacs
--
2.24.1
signature.asc
Description: PGP signature
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Am Donnerstag, 19. Dezember 2019, 19:43:37 CET schrieb Sebastian Pipping: > On 19.12.19 18:37, Michał Górny wrote: > > We have a better alternative that lets us limit the impact on the users. > > Why not use it? > > Which one? The CMake bootstrap copy? The adding to stage3 one? Is it possible to show a specific error message when running in a circular dependency? When I get it right, the problem occurs only one time when solved with a bundled use flag. As soon as expat and/or cmake are installed, follow up versions can be merge without problems. If an error message can be shown, maybe this is enough as a hint: "expat and cmake have circular dependencies. Emerge it the first time with: USE=bundled-cmake emerge -1 cmake expat and then just don't care anymore about this use flag." Of course, the same applies for other known circular dependencies, too. At least for me as a user, this would be enough. Best, Gerion signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction
> On Fri, 20 Dec 2019, Michał Górny wrote: >>> Example 3: removing fetch restriction while leaving mirror >>> restriction >>> RESTRICT="fetch" >>> SRC_URI="https://example.com/you-cant-fetch-this.zip >>> fetch+https://example.com/you-cant-mirror-this.tar.bz2"; >> I had already asked this in bug 371413 [1], but is there an actual >> usage case for example 3? Because if there isn't, we might get away >> with only supporting "mirror+", which should be less error prone. > Actually, what about the original example provided by Vadim? It's a > game + translations, all rights reserved. We can't mirror them but we > can fetch them. Thank you. That answers my question. signature.asc Description: PGP signature
[gentoo-dev] [PATCH 2/2] acct-user/xrootd: new user for UID 469
enewuser in net-libs/xrootd ebuilds has set the home directory to
"${EPREFIX}"/var/spool/xrootd but as far as I can recall from my
personal experience or see in the documentation, it isn't really
necessary for that user to have a home directory.
Package-Manager: Portage-2.3.79, Repoman-2.3.16
Signed-off-by: Marek Szuba
---
acct-user/xrootd/metadata.xml| 8
acct-user/xrootd/xrootd-0.ebuild | 12
2 files changed, 20 insertions(+)
create mode 100644 acct-user/xrootd/metadata.xml
create mode 100644 acct-user/xrootd/xrootd-0.ebuild
diff --git a/acct-user/xrootd/metadata.xml b/acct-user/xrootd/metadata.xml
new file mode 100644
index 000..46a304a17de
--- /dev/null
+++ b/acct-user/xrootd/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd";>
+
+
+ sci-phys...@gentoo.org
+ Gentoo Physics Project
+
+
diff --git a/acct-user/xrootd/xrootd-0.ebuild b/acct-user/xrootd/xrootd-0.ebuild
new file mode 100644
index 000..7b0eaaf9584
--- /dev/null
+++ b/acct-user/xrootd/xrootd-0.ebuild
@@ -0,0 +1,12 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="User for the XRootD server"
+ACCT_USER_ID=469
+ACCT_USER_GROUPS=( "${PN}" )
+
+acct-user_add_deps
--
2.24.1
[gentoo-dev] [PATCH 1/2] acct-group/xrootd: new group for GID 469
Package-Manager: Portage-2.3.79, Repoman-2.3.16 Signed-off-by: Marek Szuba --- acct-group/xrootd/metadata.xml| 8 acct-group/xrootd/xrootd-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/xrootd/metadata.xml create mode 100644 acct-group/xrootd/xrootd-0.ebuild diff --git a/acct-group/xrootd/metadata.xml b/acct-group/xrootd/metadata.xml new file mode 100644 index 000..46a304a17de --- /dev/null +++ b/acct-group/xrootd/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + sci-phys...@gentoo.org + Gentoo Physics Project + + diff --git a/acct-group/xrootd/xrootd-0.ebuild b/acct-group/xrootd/xrootd-0.ebuild new file mode 100644 index 000..7a62ea791cd --- /dev/null +++ b/acct-group/xrootd/xrootd-0.ebuild @@ -0,0 +1,9 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Group for the XRootD server" +ACCT_GROUP_ID=469 -- 2.24.1
Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl
On 2019-12-17 21:21, Matt Turner wrote: >> What do you think, guys? > > I don't love it. > > I don't like the mess that has become VIDEO_CARDS=... either. radeon > vs radeonsi vs amdgpu. [...] I hear you and very much agree, especially regarding the Radeon mess. That said, it seems what we are complaining about is the whole VIDEO_CARDS system rather than the introduction of 'iris' into virtual/opencl. The current situation with OpenCL providers for Intel GPUs ugly even disregarding the above. Basically, it is: 1. Set VIDEO_CARDS: i965 2a. If you do not set ABI_X86: 32 for virtual/opencl, it will pull in dev-libs/intel-neo 2a.1. NEO may or may not work but with the former more likely than the latter (it's been a few years since Broadwell architecture came out); 2b. If, however, you DO enable 32-bit x86 ABI it will pull dev-libs/beignet instead 2b.1. Beignet at least for the time being is likely to work even on modern systems but nowhere nearly as well as NEO would and without official upstream support. In contrast, reassigning NEO to video_cards_iris would make the Intel-GPU provider tree much more straightforward: 1. For i965, you would get dev-libs/beignet regardless of whether you want 32-bit x86 ABI or not; 2. For iris, you would get dev-libs/intel-neo for native 64 bits and nothing (okay, technically it would fall back to media-libs/mesa - but the fact Mesa is considered a fallback OpenCL provider for all GPUs is a completely different can of worms) for 32-bit x86 ABI. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction
Dnia December 16, 2019 1:16:12 PM UTC, Ulrich Mueller napisał(a): >> On Mon, 16 Dec 2019, Michał Górny wrote: > >> Proposed solution >> = >> The current proposal is based on extending the current URI syntax to >> permit excluding individual files from the restriction. The idea is >to >> prepend 'fetch+' to protocol to undo fetch restriction, or to prepend >> 'mirror+' to undo fetch & mirror restrictions. > >> Example 1: removing mirror restriction from files > >> RESTRICT="mirror" >> SRC_URI="https://example.com/you-cant-mirror-this.tar.bz2 >> mirror+https://example.com/but-you-can-mirror-this.tar.gz"; > >> Example 2: removing fetch & mirror restriction from files > >> RESTRICT="fetch" >> SRC_URI="https://example.com/you-cant-fetch-this.zip >> mirror+https://example.com/but-you-can-mirror-this.tar.gz"; > >> Example 3: removing fetch restriction while leaving mirror >restriction > >> RESTRICT="fetch" >> SRC_URI="https://example.com/you-cant-fetch-this.zip >>fetch+https://example.com/you-cant-mirror-this.tar.bz2"; > >Looks good, but what is slightly confusing is that it doesn't map >one-to-one to the RESTRICT tokens: > >- RESTRICT="mirror" enables mirror restriction, and it is undone by > "mirror+", as expected. > >- RESTRICT="fetch" enables both fetch and mirror restriction, but it is > undone by "mirror+" as well, not by "fetch+" (which disables only > fetch restriction). > >I had already asked this in bug 371413 [1], but is there an actual >usage >case for example 3? Because if there isn't, we might get away with only >supporting "mirror+", which should be less error prone. Actually, what about the original example provided by Vadim? It's a game + translations, all rights reserved. We can't mirror them but we can fetch them. > >Ulrich > >> [1] https://bugs.gentoo.org/371413 -- Best regards, Michał Górny
