[gentoo-portage-dev] [PATCH] Replace implicit {FEATURES->USE}=test forcing with USE default
Use an explicit USE_ORDER entry to control mapping FEATURES=test into
default-enabled USE=test, rather than forcing/masking it depending
on the state of FEATURES.
This makes it possible for users to enable (or disable) USE=test
independently of FEATURES. An example use case is installing test
dependencies and building test cases without actually running tests
at a particular moment which is something I've been doing quite
frequently with LLVM.
---
cnf/make.globals | 2 +-
lib/portage/eapi.py | 2 +-
lib/portage/package/ebuild/config.py | 51 +
.../tests/resolver/test_features_test_use.py | 108 +++---
man/make.conf.5 | 6 +-
5 files changed, 101 insertions(+), 68 deletions(-)
diff --git a/cnf/make.globals b/cnf/make.globals
index 08a37a534..04a708af8 100644
--- a/cnf/make.globals
+++ b/cnf/make.globals
@@ -107,7 +107,7 @@ CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d"
# Disable auto-use
-USE_ORDER="env:pkg:conf:defaults:pkginternal:repo:env.d"
+USE_ORDER="env:pkg:conf:defaults:pkginternal:features:repo:env.d"
# Mode bits for ${WORKDIR} (see ebuild.5).
PORTAGE_WORKDIR_MODE="0700"
diff --git a/lib/portage/eapi.py b/lib/portage/eapi.py
index 158d58243..5e12e976d 100644
--- a/lib/portage/eapi.py
+++ b/lib/portage/eapi.py
@@ -170,7 +170,7 @@ def _get_eapi_attrs(eapi):
exports_EBUILD_PHASE_FUNC = (eapi is None or
eapi_exports_EBUILD_PHASE_FUNC(eapi)),
exports_PORTDIR = (eapi is None or eapi_exports_PORTDIR(eapi)),
exports_ECLASSDIR = (eapi is not None and
eapi_exports_ECLASSDIR(eapi)),
- feature_flag_test = True,
+ feature_flag_test = False,
feature_flag_targetroot = (eapi is not None and
eapi_has_targetroot(eapi)),
hdepend = (eapi is not None and eapi_has_hdepend(eapi)),
iuse_defaults = (eapi is None or eapi_has_iuse_defaults(eapi)),
diff --git a/lib/portage/package/ebuild/config.py
b/lib/portage/package/ebuild/config.py
index 320d9f6c0..e253b680b 100644
--- a/lib/portage/package/ebuild/config.py
+++ b/lib/portage/package/ebuild/config.py
@@ -294,6 +294,7 @@ class config(object):
self.configlist = [
self.configdict['env.d'],
self.configdict['repo'],
+ self.configdict['features'],
self.configdict['pkginternal'],
self.configdict['globals'],
self.configdict['defaults'],
@@ -461,13 +462,16 @@ class config(object):
# back up our incremental variables:
self.configdict={}
self._use_expand_dict = {}
- # configlist will contain: [ env.d, globals, defaults,
conf, pkg, backupenv, env ]
+ # configlist will contain: [ env.d, globals, features,
defaults, conf, pkg, backupenv, env ]
self.configlist.append({})
self.configdict["env.d"] = self.configlist[-1]
self.configlist.append({})
self.configdict["repo"] = self.configlist[-1]
+ self.configlist.append({})
+ self.configdict["features"] = self.configlist[-1]
+
self.configlist.append({})
self.configdict["pkginternal"] = self.configlist[-1]
@@ -868,7 +872,7 @@ class config(object):
# reasonable defaults; this is important as without
USE_ORDER,
# USE will always be "" (nothing set)!
if "USE_ORDER" not in self:
- self["USE_ORDER"] =
"env:pkg:conf:defaults:pkginternal:repo:env.d"
+ self["USE_ORDER"] =
"env:pkg:conf:defaults:pkginternal:features:repo:env.d"
self.backup_changes("USE_ORDER")
if "CBUILD" not in self and "CHOST" in self:
@@ -1292,6 +1296,7 @@ class config(object):
del self._penv[:]
self.configdict["pkg"].clear()
self.configdict["pkginternal"].clear()
+ self.configdict["features"].clear()
self.configdict["repo"].clear()
self.configdict["defaults"]["USE"] = \
" ".join(self.make_defaults_use)
@@ -1452,6 +1457,7 @@ class config(object):
cp = cpv_getkey(mycpv)
cpv_slot = self.mycpv
pkginternaluse = ""
+ feature_use = ""
iuse = ""
pkg_configdict = self.configdict["pkg"]
previous_iuse = pkg_configdict.get("IUSE")
@@ -1650,6
Re: [gentoo-dev] Add rust eclass to support multi-target compilation
Hi! On Mon, 30 Jul 2018 17:00:20 +0200 gibix wrote: > Hello, > > I opened a PR here: https://github.com/gentoo/gentoo/pull/9388 > > Here a copy of the message: > > # add support for rust multi-target > > - add rust.eclass (with rust-utils.class) to support rust multi-target with > multibuild > - modify cargo.class to support rust multi-target > - change dev-lang/rust slot system > > This will allows projects like rustfmt, clippy, bindgen that need runtime > linking with the proper rust version to work correctly. Beyond this while > rust is getting older as project we will see more projects that will > require a specific rust version for compilation. > > This PR replaces the need for rustup in gentoo for toolchain handling and > components. > > requires: > - [features in > > cargo-ebuild](https://github.com/cardoe/cargo-ebuild/pull/14/commits/1aefd302f9430c0b628923da23e2a8d74b83d1ec) > - [binaries support into > eselect-rust](https://github.com/jauhien/eselect-rust/pull/4) > > see first discussion on > [gentoo-rust](https://github.com/gentoo/gentoo-rust/pull/362) If you are submitting code to the main tree, please submit all requirements to the tree first. Your PR brokes tree: https://github.com/gentoo/gentoo/pull/9388#issuecomment-408914903 Please fix these issues as well, for both QA and CI checks. (These problems may be a result of §1 (not yet submitted changes to the tree). It would be easier if your will split your improvements into series of atomic changes and submit them individually for review. Best regards, Andrew Savchenko pgpyqcZzV6va0.pgp Description: PGP signature
[gentoo-dev] Add rust eclass to support multi-target compilation
Hello, I opened a PR here: https://github.com/gentoo/gentoo/pull/9388 Here a copy of the message: # add support for rust multi-target - add rust.eclass (with rust-utils.class) to support rust multi-target with multibuild - modify cargo.class to support rust multi-target - change dev-lang/rust slot system This will allows projects like rustfmt, clippy, bindgen that need runtime linking with the proper rust version to work correctly. Beyond this while rust is getting older as project we will see more projects that will require a specific rust version for compilation. This PR replaces the need for rustup in gentoo for toolchain handling and components. requires: - [features in cargo-ebuild](https://github.com/cardoe/cargo-ebuild/pull/14/commits/1aefd302f9430c0b628923da23e2a8d74b83d1ec) - [binaries support into eselect-rust](https://github.com/jauhien/eselect-rust/pull/4) see first discussion on [gentoo-rust](https://github.com/gentoo/gentoo-rust/pull/362) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
On Mon, Jul 30, 2018 at 8:52 AM Guilherme Amadio wrote: > If you introduce penalties for breaking prefix as well, I'm afraid many > people will be unnecessarily penalized. I think that such penalties are > counter productive in most cases. If someone is really being careless it > might make sense to get some warning and lose commit access temporarily. > If someone made a simple mistake that can be easily fixed, like version > bumping a package that starts to fail in some corner case, then > punishment doesn't make much sense. > The proposed policy already mentions that people will only be punished after two warnings. This seems enough for me -- if people keep breaking stuff despite warnings, a little penalty is probably a good thing. The proposed policy already goes out of its way to require two warnings for "independent" breakage, but it's not entirely clear what independent means here. If you commit three breakages that are technically unrelated on the same day, then you probably shouldn't be banned immediately. So I would suggest also making clear that the warnings should be sent at least a few days apart and that an initial penalty cannot happen until a few days apart the second warning. That said, I agree with those who are saying that breaking things should be obvious, things like ignoring repoman and/or other CI messaging. If the breakage is non-obvious and hard to spot locally, then we should instead invest in tooling to make it more obvious. By "ignoring" here I do mean that there needs to be a reasonable timeout -- sometimes if I commit a change and get a CI alert after a few hours, it might be tricky due to work/family/whatever concerns to fix it within, say, 24 hours. Regards, Dirkjan
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
Hello, I like the idea of enforcing quality rules in the tree, but I have a few reservations regarding the current plan. On Sun, Jul 29, 2018 at 04:47:47PM +0900, Alice Ferrazzi wrote: > Sent from my phone. Please excuse my brevity. > > On Sun, 29 Jul 2018, 16:39 Fabian Groffen, wrote: > > > Completely agreeing with Sergei, with some additional suggestions: > > > > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > > > On Sun, 29 Jul 2018 00:40:18 +0300 > > > Mikle Kolyada wrote: > > > > > > > Hello, > > > > > > > > The Gentoo QA team would like to introduce the following policy that > > > > would be applied to individuals breaking the state and quality of the > > > > main gentoo.git tree If you introduce penalties for breaking prefix as well, I'm afraid many people will be unnecessarily penalized. I think that such penalties are counter productive in most cases. If someone is really being careless it might make sense to get some warning and lose commit access temporarily. If someone made a simple mistake that can be easily fixed, like version bumping a package that starts to fail in some corner case, then punishment doesn't make much sense. I'd rather prefer to see improvements to our automated checks as the mean to improve the quality of the tree, and penalties for people that do not use repoman. Rather than a temporary ban, it would also make more sense to just require someone to go through the ebuild quiz again as penalty for breaking the tree many times. > > > > ( as we do not have this strictly documented yet): > > > > > > > > > > > > > > > > If recommended > > > > > > It's not called "recommended" but "enforced". > > > > I agree. If you put penalties on these, they become hard rules. I > > think that change should be discussed by the council perhaps? > > > > > > Gentoo workflow policies are not followed by an > > > > individual developer > > > > (e.g make major changes to the widely used eclasses without prior > > > > discussion on the mailing list or > > > > commit changes that lead to multiple CI checks failure) > > > > > > Here should go exhaustive list of links to the policies to be enforced. > > > > At least. And they should be clear and concise. No "common sense" or > > anything involved for exceptions and the like. In addition, new checks > > should be introduced to the community and possibly approved by council > > as to whether being enforced or not. > > > > Fabian > > > > > > > > > the standard QA > > > > procedure is: > > > > > > > > 1.) Two warnings granted by QA team, after two independent breakages > > > > 2.) Revoking the commit access for 14 days > > > > > > > > These violations will be evaluated individually by all QA team members. > > > > Warnings can be revoked, if during 6 months period a developer makes at > > > > least 20 non trivial changes not producing more breakages. > > > > > > > > > > > > > > -- > > > > > > if you want to enforce rules, would be productive to also have extensive > documentation on how to avoid to make such problems. > Better would be to invest more time in something like the breckage checker > script, similar at what mgorny is doing, than adding more ways to block > developers contributions. I agree with Alice here. We already have the devmanual and repoman, as well as the CI system, which are all very good. Extending them is the best way to keep Gentoo in good shape. Also, if we have enough resources, we can try to reject broken pushes, rather than punishing devs after broken changes reach the main tree. Cheers, -Guilherme
