Re: [gentoo-portage-dev] [PATCH] depgraph: account for binpkg-multi-instance in unused warning (bug 619620)

2017-05-29 Thread Brian Dolbec 
On Mon, 29 May 2017 15:11:41 -0700
Zac Medico  wrote:

> On Mon, May 29, 2017 at 3:03 PM, Brian Dolbec 
> wrote:
> 
> > On Sun, 28 May 2017 03:07:50 -0700
> > Zac Medico  wrote:
> >  
> > > With FEATURES=binpkg-multi-instance, it is normal to have some
> > > unused binary packages, so don't warn if the selected package
> > > is the latest version and the most recent build.
> > >  
> >^^^
> > is or isn't  the latest version?  
> 
> 
> is the latest version (in this case we "don't warn").


OK, WFM

-- 
Brian Dolbec

Re: [gentoo-portage-dev] [PATCH v2] emerge: warn for --autounmask-continue with --autounmask=n (bug 619612)

2017-05-29 Thread Zac Medico 
On Mon, May 29, 2017 at 3:10 PM, Brian Dolbec  wrote:

> On Mon, 29 May 2017 14:10:23 -0700
> Zac Medico  wrote:
>
> > In order to avoid possible confusion when the user has specified
> > --autounmask-continue and EMERGE_DEFAULT_OPTS contains
> > --autounmask=n, display a warning message as follows:
> >
> >  * --autounmask-continue has been disabled by --autounmask=n
> >
> > X-Gentoo-bug: 619612
> > X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=619612
> > ---
> > [PATCH v2] preserves previous behavior where --autounmask=n
> > overrides --autounmask-continue, as suggested by Alexander
> > Berntsen
> >
> >  pym/_emerge/actions.py  | 6 ++
> >  pym/portage/tests/emerge/test_simple.py | 5 -
> >  2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py
> > index 1bc20c3ed..c8a62fb01 100644
> > --- a/pym/_emerge/actions.py
> > +++ b/pym/_emerge/actions.py
> > @@ -2862,6 +2862,12 @@ def run_action(emerge_config):
> >   adjust_configs(emerge_config.opts, emerge_config.trees)
> >   apply_priorities(emerge_config.target_config.settings)
> >
> > + if ("--autounmask-continue" in emerge_config.opts and
> > + emerge_config.opts.get("--autounmask") == "n"):
> > + writemsg_level(
> > + " %s --autounmask-continue has been disabled
> > by --autounmask=n\n" %
> > + warn("*"), level=logging.WARNING,
> > noiselevel=-1) +
> >   for fmt in
> > emerge_config.target_config.settings.get("PORTAGE_BINPKG_FORMAT",
> > "").split(): if not fmt in portage.const.SUPPORTED_BINPKG_FORMATS: if
> > "--pkg-format" in emerge_config.opts: diff --git
> > a/pym/portage/tests/emerge/test_simple.py
> > b/pym/portage/tests/emerge/test_simple.py index 5930f6cc8..f99c77927
> > 100644 --- a/pym/portage/tests/emerge/test_simple.py +++
> > b/pym/portage/tests/emerge/test_simple.py @@ -311,7 +311,10 @@
> > pkg_preinst() { emerge_cmd + ("--unmerge", "--quiet", "dev-libs/A"),
> >   emerge_cmd + ("-C", "--quiet", "dev-libs/B"),
> >
> > - emerge_cmd + ("--autounmask-continue",
> > "dev-libs/C",),
> > + # If EMERGE_DEFAULT_OPTS contains
> > --autounmask=n, then --autounmask
> > + # must be specified with
> > --autounmask-continue.
> > + ({"EMERGE_DEFAULT_OPTS" :
> > "--autounmask=n"},) + \
> > + emerge_cmd + ("--autounmask",
> > "--autounmask-continue", "dev-libs/C",), # Verify that the above
> > --autounmask-continue command caused # USE=flag to be applied
> > correctly to dev-libs/D. portageq_cmd + ("match", eroot,
> > "dev-libs/D[flag]"),
>
>
> WFM
>

Thanks, pushed:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=565ceb1bebc83ec1a5572a672e2e08ea7d91e7a8

-- 
Thanks,
Zac

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Ciaran McCreesh 
On Tue, 30 May 2017 00:01:16 +0200
Ulrich Mueller  wrote:
> > On Mon, 29 May 2017, Michał Górny wrote:  
> > On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote:  
> >> Can you provide an efficient algorithm for the above syntax? That
> >> is, given a set of +/- useflags forced by user, output the set of
> >> effective useflags (or a rant if it is inconsistent).  
> 
> > I'd rather leave that to people who are good with algorithms. I find
> > the whole thing scary but I don't really see a sane alternative
> > here. Worst case, we have to figure out some arbitrary limitations
> > to keep things sane.  
> 
> IMHO the sanest alternative would be to restrict the syntax to USE
> conditional forms which have an obvious solution. One of the many
> problems of REQUIRED_USE is that it sometimes requires solving a
> Zebra Puzzle.

Solving zebra puzzles isn't really that bad in practice most of the
time. The tricky bit is finding the *right* solution, given poor input
data that doesn't really let you evaluate what right is. As a simple
example, in the olden days, the most obvious and shortest answer to
fixing Gnome resolution errors was to set USE=mips because that
disabled a whole load of browser dependencies...

-- 
Ciaran McCreesh

Re: [gentoo-portage-dev] [PATCH v2] man/portage.5: document -* in profile "packages" files (bug 610670)

2017-05-29 Thread Brian Dolbec 
On Sun, 28 May 2017 13:15:12 -0700
Zac Medico  wrote:

> The -* wildcard has been supported since portage-2.3.4, but it was
> not explicitly documented.
> 
> X-Gentoo-Bug: 610670
> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=610670
> ---
> [PATCH v2] clarifies that -* discards @system and @profile
> packages as suggested by Martin Vaeth.
> 
>  man/portage.5 | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/man/portage.5 b/man/portage.5
> index 82e979ecf..366a1fa85 100644
> --- a/man/portage.5
> +++ b/man/portage.5
> @@ -369,7 +369,8 @@ hurt \fBemerge\fR's ability to parallelize.
>  .I Note:
>  In a cascading profile setup, you can remove packages in children
>  profiles which were added by parent profiles by prefixing the atom
> with -a '\-'.
> +a '\-'. The '\-*' wildcard discards all @system and @profile packages
> +added by parent profiles.
>  
>  .I Example:
>  .nf


LGTM
-- 
Brian Dolbec

Re: [gentoo-portage-dev] [PATCH] depgraph: account for binpkg-multi-instance in unused warning (bug 619620)

2017-05-29 Thread Brian Dolbec 
On Sun, 28 May 2017 03:07:50 -0700
Zac Medico  wrote:

> With FEATURES=binpkg-multi-instance, it is normal to have some
> unused binary packages, so don't warn if the selected package
> is the latest version and the most recent build.
> 
   ^^^
is or isn't  the latest version?


> X-Gentoo-bug: 619620
> X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=619620
> ---
>  pym/_emerge/depgraph.py | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
> index 726835dd4..2dc432431 100644
> --- a/pym/_emerge/depgraph.py
> +++ b/pym/_emerge/depgraph.py
> @@ -876,6 +876,15 @@ class depgraph(object):
>   
> self._dynamic_config.ignored_binaries.pop(pkg)
>   break
>  
> + # NOTE: The Package.__ge__
> implementation accounts for
> + # differences in build_time, so the
> warning about "ignored"
> + # packages will be triggered if both
> packages are the same
> + # version and selected_pkg is not
> the most recent build.
> + if (selected_pkg.type_name ==
> "binary" and
> + selected_pkg >= pkg):
> +
> self._dynamic_config.ignored_binaries.pop(pkg)
> + break
> +
>   if selected_pkg.installed and \
>   selected_pkg.cpv == pkg.cpv
> and \ selected_pkg.build_time == pkg.build_time:



-- 
Brian Dolbec

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Ulrich Mueller 
> On Mon, 29 May 2017, Michał Górny wrote:

> On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote:
>> Can you provide an efficient algorithm for the above syntax? That
>> is, given a set of +/- useflags forced by user, output the set of
>> effective useflags (or a rant if it is inconsistent).

> I'd rather leave that to people who are good with algorithms. I find
> the whole thing scary but I don't really see a sane alternative here.
> Worst case, we have to figure out some arbitrary limitations to keep
> things sane.

IMHO the sanest alternative would be to restrict the syntax to USE
conditional forms which have an obvious solution. One of the many
problems of REQUIRED_USE is that it sometimes requires solving a
Zebra Puzzle.

Also, can we find a better name? Sorry for the bikeshedding at this
early stage, but I believe that ENFORCED_USE can be easily confused
with use.force in profiles. MAPPED_USE? USE_MAP?

Ulrich


pgpoQc77HrAEH.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] meson.eclass: implement basic cross-compiler support

2017-05-29 Thread Mike Gilbert 
On Mon, May 29, 2017 at 5:06 PM, Michał Górny  wrote:
> On pon, 2017-05-29 at 16:58 -0400, Mike Gilbert wrote:
>> + # system roughly corresponds to uname -s (lowercase)
>> + local system=unknown
>> + case ${CHOST} in
>> + *-aix*) system=aix ;;
>> + *-cygwin*)  system=cygwin ;;
>> + *-darwin*)  system=darwin ;;
>> + *-freebsd*) system=freebsd ;;
>> + *-linux*)   system=linux ;;
>> + *-solaris*) system=sunos ;;
>
> Don't you want to die on unknown system? Or is it likely to work anyway?

Good question.

The 'system' property controls some built-in logic in meson itself
(mainly for MS Windows), and may be referenced by project files as
'host_machine.system()'. Setting it to 'unknown' may cause failures
for projects that actually look at it.

However, I think most projects would work without having this set to a
known value.

>> + esac
>> +
>> + local cpu_family=$(tc-arch)
>> + case ${cpu_family} in
>> + amd64) cpu_family=x86_64 ;;
>> + arm64) cpu_family=aarch64 ;;
>
> That's purely mapping from known-wrong values, correct? Maybe it'd be
> reasonable to assert for all correct too, and fail on unknown?

Yes, it corrects two obvious deviations from uname -m on Linux. x86 is
ok since that is what meson expects/generates for i?86.

I'm not sure what you mean by "assert for all correct"; if you mean
check for all valid values for cpu_family, such a list does not exist.

Similar to 'system' this property may or may not be used depending on
the project. Defaulting to "unknown" should be fine in many cases. I
don't think we need to fail.

>> + # Both meson(1) and _meson_create_cross_file need these
>> + tc-export AR CC CXX STRIP
>
> Wouldn't it be reasonable to make them local first anyway? I would try
> to avoid polluting the environment.

Makes sense. I'll revise this to "local -x CC=$(tc-getCC)", etc.

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Ciaran McCreesh 
On Mon, 29 May 2017 23:23:55 +0200
Michał Górny  wrote:
> > Can you provide an efficient algorithm for the above syntax?
> > That is, given a set of +/- useflags forced by user, output the set
> > of effective useflags (or a rant if it is inconsistent).  
> 
> I'd rather leave that to people who are good with algorithms. I find
> the whole thing scary but I don't really see a sane alternative here.
> Worst case, we have to figure out some arbitrary limitations to keep
> things sane.

That bit is NP-complete by an easy reduction from SAT. That isn't
necessarily a problem, because resolution isn't even in NP yet we're
still managing to spit out decent answers most of the time. Rather, the
difficulty lies in spitting out a *good* solution to the problem from
a user's perspective, and that's something that can't be done without
extremely high quality inputs.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Michał Górny 
On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote:
> On Mon, 29 May 2017 17:33:13 +0200
> Michał Górny  wrote:
> 
> > In the basic form, it can be used to conditionally force a specific
> > flag to be enabled or disabled. For example:
> > 
> >   foo? ( bar )
> > 
> > would mean that the bar flag is implicitly enabled (forced) if foo is
> > enabled as well. Appropriately:
> > 
> >   foo? ( !bar )
> > 
> > would mean that the bar flag is implicitly disabled (masked) in that
> > case.
> 
> All good here.
> 
> 
> > It can also be used with multi-flag ??, ^^ and || constraints, i.e.:
> > 
> > - ?? means that at most one of the flags can be enabled. If user
> > configuration causes more than one of the flags to be enabled,
> > additional flags are implicitly disabled (masked) to satisfy
> > the constraint.
> > 
> > - || means that at least one of the flags must be enabled. If user
> > configuration causes none of the flags to be enabled, one of them is
> > enabled implicitly (forced).
> > 
> > - ^^ means that exactly one of the flags must be enabled. The behavior
> > is a combination of both above constraints.
> > 
> > The automated solving of USE constraints would require the developers
> > to consider the implicit effect of the constraints they are writing.
> 
> 
> Can you provide an efficient algorithm for the above syntax?
> That is, given a set of +/- useflags forced by user, output the set of
> effective useflags (or a rant if it is inconsistent).

I'd rather leave that to people who are good with algorithms. I find
the whole thing scary but I don't really see a sane alternative here.
Worst case, we have to figure out some arbitrary limitations to keep
things sane.

> Maybe I'm mistaken, but I doubt it is possible with n-ary constraints.
> 
> Now the extra question: Do those n-ary operators have any advantage ?

Yes, they do. They improve readability, compared to cascades of plain
constraints. I'm pretty sure users will be happier to see 'you need to
select one of foo, bar, baz' than 'if foo is disabled, then ...'

> The point is to express some preference, below you suggest to leave
> that to the user, but what about leaving that to the ebuild developer?

Well, I don't find that a killer feature but I don't see a reason to
take it away either. Either way we have some risks, especially when USE
dependencies and blockers are involved. In both scenarios, I find it
less risky to let user control the order than to rely on all developers
respecting the same preference order. Not saying the latter wouldn't
hurt anyway but the users would at least have an easy way out.

> That way, e.g., || can be rewritten as implications: '|| ( a b c )'
> becomes '!b? !c? a' meaning if none is enabled then a is automatically
> enabled.

Unless you are planning to cache the rewritten forms, I don't see
a problem, really. You just reorder the flags according to the apparent
preference before rewriting.

> 
> Note that with only unary constraints, computing the set of effective
> useflags becomes trivial (linear in the # of useflags + constraints):
> take the constraints as a list, solve the first one, add its
> consequences (if any) to the set of forced useflags, continue with next
> constraint or rant if the set of forced flags is inconsistent.

Sounds fine. But I'm not an expert to really judge that ;-).

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

[gentoo-portage-dev] [PATCH v2] emerge: warn for --autounmask-continue with --autounmask=n (bug 619612)

2017-05-29 Thread Zac Medico 
In order to avoid possible confusion when the user has specified
--autounmask-continue and EMERGE_DEFAULT_OPTS contains
--autounmask=n, display a warning message as follows:

 * --autounmask-continue has been disabled by --autounmask=n

X-Gentoo-bug: 619612
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=619612
---
[PATCH v2] preserves previous behavior where --autounmask=n
overrides --autounmask-continue, as suggested by Alexander
Berntsen

 pym/_emerge/actions.py  | 6 ++
 pym/portage/tests/emerge/test_simple.py | 5 -
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py
index 1bc20c3ed..c8a62fb01 100644
--- a/pym/_emerge/actions.py
+++ b/pym/_emerge/actions.py
@@ -2862,6 +2862,12 @@ def run_action(emerge_config):
adjust_configs(emerge_config.opts, emerge_config.trees)
apply_priorities(emerge_config.target_config.settings)
 
+   if ("--autounmask-continue" in emerge_config.opts and
+   emerge_config.opts.get("--autounmask") == "n"):
+   writemsg_level(
+   " %s --autounmask-continue has been disabled by 
--autounmask=n\n" %
+   warn("*"), level=logging.WARNING, noiselevel=-1)
+
for fmt in 
emerge_config.target_config.settings.get("PORTAGE_BINPKG_FORMAT", "").split():
if not fmt in portage.const.SUPPORTED_BINPKG_FORMATS:
if "--pkg-format" in emerge_config.opts:
diff --git a/pym/portage/tests/emerge/test_simple.py 
b/pym/portage/tests/emerge/test_simple.py
index 5930f6cc8..f99c77927 100644
--- a/pym/portage/tests/emerge/test_simple.py
+++ b/pym/portage/tests/emerge/test_simple.py
@@ -311,7 +311,10 @@ pkg_preinst() {
emerge_cmd + ("--unmerge", "--quiet", "dev-libs/A"),
emerge_cmd + ("-C", "--quiet", "dev-libs/B"),
 
-   emerge_cmd + ("--autounmask-continue", "dev-libs/C",),
+   # If EMERGE_DEFAULT_OPTS contains --autounmask=n, then 
--autounmask
+   # must be specified with --autounmask-continue.
+   ({"EMERGE_DEFAULT_OPTS" : "--autounmask=n"},) + \
+   emerge_cmd + ("--autounmask", 
"--autounmask-continue", "dev-libs/C",),
# Verify that the above --autounmask-continue command 
caused
# USE=flag to be applied correctly to dev-libs/D.
portageq_cmd + ("match", eroot, "dev-libs/D[flag]"),
-- 
2.13.0

Re: [gentoo-dev] [PATCH] meson.eclass: implement basic cross-compiler support

2017-05-29 Thread Michał Górny 
On pon, 2017-05-29 at 16:58 -0400, Mike Gilbert wrote:
> ---
>  eclass/meson.eclass | 74 
> +
>  1 file changed, 57 insertions(+), 17 deletions(-)
> 
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 758e4180ba7a..0fdb1d848973 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -39,8 +39,7 @@ esac
>  
>  if [[ -z ${_MESON_ECLASS} ]]; then
>  
> -# FIXME: We will need to inherit toolchain-funcs as well to support crossdev.
> -inherit ninja-utils
> +inherit ninja-utils toolchain-funcs
>  
>  fi
>  
> @@ -71,17 +70,52 @@ DEPEND=">=dev-util/meson-0.39.1
>  # Optional meson arguments as Bash array; this should be defined before
>  # calling meson_src_configure.
>  
> -# Create a cross file for meson
> -# fixme: This function should write a cross file as described at the
> -# following url.
> -# http://mesonbuild.com/Cross-compilation.html
> -# _meson_create_cross_file() {
> -#touch "${T}"/meson.crossfile
> -# }
> +# @FUNCTION: _meson_create_cross_file
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Creates a cross file. meson uses this to define settings for
> +# cross-compilers. This function is called from meson_src_configure.
> +_meson_create_cross_file() {
> + # Reference: http://mesonbuild.com/Cross-compilation.html
> +
> + # system roughly corresponds to uname -s (lowercase)
> + local system=unknown
> + case ${CHOST} in
> + *-aix*) system=aix ;;
> + *-cygwin*)  system=cygwin ;;
> + *-darwin*)  system=darwin ;;
> + *-freebsd*) system=freebsd ;;
> + *-linux*)   system=linux ;;
> + *-solaris*) system=sunos ;;

Don't you want to die on unknown system? Or is it likely to work anyway?

> + esac
> +
> + local cpu_family=$(tc-arch)
> + case ${cpu_family} in
> + amd64) cpu_family=x86_64 ;;
> + arm64) cpu_family=aarch64 ;;

That's purely mapping from known-wrong values, correct? Maybe it'd be
reasonable to assert for all correct too, and fail on unknown?

> + esac
> +
> + # This may require adjustment based on CFLAGS
> + local cpu=${CHOST%%-*}
> +
> + cat > "${T}/meson.${CHOST}" <<-EOF
> + [binaries]
> + ar = '${AR}'
> + c = '${CC}'
> + cpp = '${CXX}'
> + strip = '${STRIP}'
> +
> + [host_machine]
> + system = '${system}'
> + cpu_family = '${cpu_family}'
> + cpu = '${cpu}'
> + endian = '$(tc-endian)'
> + EOF
> +}
>  
>  # @FUNCTION: meson_src_configure
>  # @DESCRIPTION:
> -# This is the meson_src_configure function
> +# This is the meson_src_configure function.
>  meson_src_configure() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> @@ -94,13 +128,19 @@ meson_src_configure() {
>   --sysconfdir "${EPREFIX}/etc"
>   )
>  
> -# fixme: uncomment this for crossdev support
> -#if tc-is-cross-compiler; then
> -#_meson_create_cross_file || die "unable to write meson cross 
> file"
> -#mesonargs+=(
> -#--cross-file "${T}"/meson.crossfile
> -#)
> -#fi
> + # Both meson(1) and _meson_create_cross_file need these
> + tc-export AR CC CXX STRIP

Wouldn't it be reasonable to make them local first anyway? I would try
to avoid polluting the environment.

> +
> + if tc-is-cross-compiler; then
> + _meson_create_cross_file || die "unable to write meson cross 
> file"
> + mesonargs+=(
> + --cross-file "${T}"/meson.${CHOST}
> + )
> + # In cross mode, meson uses CC/CXX as the "build" compilers
> + local -x AR=$(tc-getBUILD_AR)
> + local -x CC=$(tc-getBUILD_CC)
> + local -x CXX=$(tc-getBUILD_CXX)
> + fi
>  
>   # Append additional arguments from ebuild
>   mesonargs+=("${emesonargs[@]}")

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] [PATCH] meson.eclass: implement basic cross-compiler support

2017-05-29 Thread Mike Gilbert 
---
 eclass/meson.eclass | 74 +
 1 file changed, 57 insertions(+), 17 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 758e4180ba7a..0fdb1d848973 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -39,8 +39,7 @@ esac
 
 if [[ -z ${_MESON_ECLASS} ]]; then
 
-# FIXME: We will need to inherit toolchain-funcs as well to support crossdev.
-inherit ninja-utils
+inherit ninja-utils toolchain-funcs
 
 fi
 
@@ -71,17 +70,52 @@ DEPEND=">=dev-util/meson-0.39.1
 # Optional meson arguments as Bash array; this should be defined before
 # calling meson_src_configure.
 
-# Create a cross file for meson
-# fixme: This function should write a cross file as described at the
-# following url.
-# http://mesonbuild.com/Cross-compilation.html
-# _meson_create_cross_file() {
-#  touch "${T}"/meson.crossfile
-# }
+# @FUNCTION: _meson_create_cross_file
+# @INTERNAL
+# @DESCRIPTION:
+# Creates a cross file. meson uses this to define settings for
+# cross-compilers. This function is called from meson_src_configure.
+_meson_create_cross_file() {
+   # Reference: http://mesonbuild.com/Cross-compilation.html
+
+   # system roughly corresponds to uname -s (lowercase)
+   local system=unknown
+   case ${CHOST} in
+   *-aix*) system=aix ;;
+   *-cygwin*)  system=cygwin ;;
+   *-darwin*)  system=darwin ;;
+   *-freebsd*) system=freebsd ;;
+   *-linux*)   system=linux ;;
+   *-solaris*) system=sunos ;;
+   esac
+
+   local cpu_family=$(tc-arch)
+   case ${cpu_family} in
+   amd64) cpu_family=x86_64 ;;
+   arm64) cpu_family=aarch64 ;;
+   esac
+
+   # This may require adjustment based on CFLAGS
+   local cpu=${CHOST%%-*}
+
+   cat > "${T}/meson.${CHOST}" <<-EOF
+   [binaries]
+   ar = '${AR}'
+   c = '${CC}'
+   cpp = '${CXX}'
+   strip = '${STRIP}'
+
+   [host_machine]
+   system = '${system}'
+   cpu_family = '${cpu_family}'
+   cpu = '${cpu}'
+   endian = '$(tc-endian)'
+   EOF
+}
 
 # @FUNCTION: meson_src_configure
 # @DESCRIPTION:
-# This is the meson_src_configure function
+# This is the meson_src_configure function.
 meson_src_configure() {
debug-print-function ${FUNCNAME} "$@"
 
@@ -94,13 +128,19 @@ meson_src_configure() {
--sysconfdir "${EPREFIX}/etc"
)
 
-# fixme: uncomment this for crossdev support
-#  if tc-is-cross-compiler; then
-#  _meson_create_cross_file || die "unable to write meson cross 
file"
-#  mesonargs+=(
-#  --cross-file "${T}"/meson.crossfile
-#  )
-#  fi
+   # Both meson(1) and _meson_create_cross_file need these
+   tc-export AR CC CXX STRIP
+
+   if tc-is-cross-compiler; then
+   _meson_create_cross_file || die "unable to write meson cross 
file"
+   mesonargs+=(
+   --cross-file "${T}"/meson.${CHOST}
+   )
+   # In cross mode, meson uses CC/CXX as the "build" compilers
+   local -x AR=$(tc-getBUILD_AR)
+   local -x CC=$(tc-getBUILD_CC)
+   local -x CXX=$(tc-getBUILD_CXX)
+   fi
 
# Append additional arguments from ebuild
mesonargs+=("${emesonargs[@]}")
-- 
2.13.0

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Michał Górny 
On pon, 2017-05-29 at 20:24 +0100, Ciaran McCreesh wrote:
> On Mon, 29 May 2017 17:33:13 +0200
> Michał Górny  wrote:
> > For a long time we seem to be missing appropriate tools to handle USE
> > flag constraints efficiently. EAPI 4 brought REQUIRED_USE but all
> > things considered, it has proven to be far from an optimal solution.
> > I would therefore like to discuss adding a better tool to amend or
> > replace it, to allow for automated handling of USE flag constraints.
> 
> REQUIRED_USE's problems all come from it being thrown in at the last
> minute without any testing of either the user experience or the
> feasibility of its implementation. Have you implemented a prototype to
> show that you can actually fix those problems?
> 

I tend to RFC before starting the implementation. Saves effort.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Ciaran McCreesh 
On Mon, 29 May 2017 21:42:33 +0200
Michał Górny  wrote:
> On pon, 2017-05-29 at 20:24 +0100, Ciaran McCreesh wrote:
> > On Mon, 29 May 2017 17:33:13 +0200
> > Michał Górny  wrote:  
> > > For a long time we seem to be missing appropriate tools to handle
> > > USE flag constraints efficiently. EAPI 4 brought REQUIRED_USE but
> > > all things considered, it has proven to be far from an optimal
> > > solution. I would therefore like to discuss adding a better tool
> > > to amend or replace it, to allow for automated handling of USE
> > > flag constraints.  
> > 
> > REQUIRED_USE's problems all come from it being thrown in at the last
> > minute without any testing of either the user experience or the
> > feasibility of its implementation. Have you implemented a prototype
> > to show that you can actually fix those problems?
> 
> I tend to RFC before starting the implementation. Saves effort.

Not the implementation. A prototype implementation. As we saw from
REQUIRED_USE, it really doesn't save effort to spend time specifying
something that can't even remotely work...

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Ciaran McCreesh 
On Mon, 29 May 2017 17:33:13 +0200
Michał Górny  wrote:
> For a long time we seem to be missing appropriate tools to handle USE
> flag constraints efficiently. EAPI 4 brought REQUIRED_USE but all
> things considered, it has proven to be far from an optimal solution.
> I would therefore like to discuss adding a better tool to amend or
> replace it, to allow for automated handling of USE flag constraints.

REQUIRED_USE's problems all come from it being thrown in at the last
minute without any testing of either the user experience or the
feasibility of its implementation. Have you implemented a prototype to
show that you can actually fix those problems?

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Alexis Ballier 
On Mon, 29 May 2017 17:33:13 +0200
Michał Górny  wrote:

> Hello,
> 
> For a long time we seem to be missing appropriate tools to handle USE
> flag constraints efficiently. EAPI 4 brought REQUIRED_USE but all
> things considered, it has proven to be far from an optimal solution.
> I would therefore like to discuss adding a better tool to amend or
> replace it, to allow for automated handling of USE flag constraints.


This has been discussed in the past and I'm basically all for it. Some
more detailed comments below.

[...]
> 2. Specification
> 
> 
> 2.1. Forced USE flag constraints
> 
> 
> This proposal introduces USE flag constraints that are meant to be
> solved automatically by the package manager. This is somewhat similar
> to REQUIRED_USE, except that it does not require the user to take any
> explicit action. In that regard, it is closer to conditional
> package.use.force/mask.
> 
> In the basic form, it can be used to conditionally force a specific
> flag to be enabled or disabled. For example:
> 
>   foo? ( bar )
> 
> would mean that the bar flag is implicitly enabled (forced) if foo is
> enabled as well. Appropriately:
> 
>   foo? ( !bar )
> 
> would mean that the bar flag is implicitly disabled (masked) in that
> case.

All good here.


> It can also be used with multi-flag ??, ^^ and || constraints, i.e.:
> 
> - ?? means that at most one of the flags can be enabled. If user
> configuration causes more than one of the flags to be enabled,
> additional flags are implicitly disabled (masked) to satisfy
> the constraint.
> 
> - || means that at least one of the flags must be enabled. If user
> configuration causes none of the flags to be enabled, one of them is
> enabled implicitly (forced).
> 
> - ^^ means that exactly one of the flags must be enabled. The behavior
> is a combination of both above constraints.
> 
> The automated solving of USE constraints would require the developers
> to consider the implicit effect of the constraints they are writing.


Can you provide an efficient algorithm for the above syntax?
That is, given a set of +/- useflags forced by user, output the set of
effective useflags (or a rant if it is inconsistent).
Maybe I'm mistaken, but I doubt it is possible with n-ary constraints.

Now the extra question: Do those n-ary operators have any advantage ?
The point is to express some preference, below you suggest to leave
that to the user, but what about leaving that to the ebuild developer?
That way, e.g., || can be rewritten as implications: '|| ( a b c )'
becomes '!b? !c? a' meaning if none is enabled then a is automatically
enabled.

Note that with only unary constraints, computing the set of effective
useflags becomes trivial (linear in the # of useflags + constraints):
take the constraints as a list, solve the first one, add its
consequences (if any) to the set of forced useflags, continue with next
constraint or rant if the set of forced flags is inconsistent.


> 2.2. UI implications
> 
[...]

I really like that part. It becomes even simpler with only unary
constraints :)

[...]
> 2.4. Backwards compatibility
> 
> 
> Before choosing the exact way of implementing this, we need to answer
> how far we want to provide backwards compatibility. In particular:
> 
> a. Do we need the REQUIRED_USE requiring explicit user selection? Or
> can we rely completely on other solutions (automatic solving,
> pkg_pretend())?
> 
> b. Would changing REQUIRED_USE behavior in place cause unintended side
> effects? Are we going to accept those effects until the packages are
> fixed? (e.g. selecting less preferred solution of constraint)


I would prefer changing REQUIRED_USE in a new EAPI. We definitely do
not need a new variable, REQUIRED_USE is good enough, but PMS has been
vague enough not to define that so we can't assume the selection of
auto-enabled useflags will be what was meant rather than something
completely stupid.

I'm even more inclined towards changing that in a new EAPI since using
the current REQUIRED_USE syntax seems to introduce yet another
exponential algorithm in the critical path of 'emerge -uDN world'...

[...]
> 2.5. Ebuild interface
> =
> 
> This section is most flexible as I don't really care how it's done,
> as long as it's done. Depending on our preferences, and the answers to
> questions in the preceding section, the options include:
> 
> 1. changing behavior of REQUIRED_USE retroactively -- i.e. making
> Portage start solving USE constraints automatically, and being able to
> rely on that a few months from now,
> 
> 2. changing behavior of REQUIRED_USE in a future EAPI,
> 
> 3. adding ENFORCED_USE with the new behavior in a future EAPI
> (and either keeping or removing REQUIRED_USE),
> 
> 4. adding special syntax to REQUIRED_USE to indicate which constraints
> can be solved automatically,
> 
> 5. adding special syntax to IUSE to

Re: [gentoo-dev] toolchain meeting agenda for today 19:00 UTC #gentoo-toolchain

2017-05-29 Thread Walter Dnes 
On Fri, May 26, 2017 at 08:29:59PM +0200, Kristian Fiskerstrand wrote
> On 05/26/2017 08:07 PM, Alexis Ballier wrote:
> > A bit late to the party, but what was the outcome of the meeting, esp.
> > this part ?
> 
> Unofficial log from meeting:
> https://download.sumptuouscapital.com/gentoo/tmp/gentoo-toolchain.log.txt

  The irc log mentions problems with some ebuilds under some versions of
GCC.  In a similar vein, are there any anticipated issues with binaries
built under older GCC versions running on a system that is otherwise
all-GCC-6.3.0?  I'm thinking of pre-built binaries like Pale Moon (from
their website), firefox-bin, seamonkey-bin, openoffice-bin,
libreoffice-bin, libreproject-bin, etc.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Michał Górny 
On wto, 2017-05-30 at 04:30 +1200, Kent Fredric wrote:
> On Mon, 29 May 2017 17:33:13 +0200
> Michał Górny  wrote:
> 
> > Automatically solving USE constraints solve all three fore-mentioned
> > issues with REQUIRED_USE. By default, no user intervention is required
> > to solve USE constraints and package.use needs to be modified only to
> > enforce a non-standard solutons
> 
> Overall I like the proposal, but one question: How do you envisage
> automatic use-constraints interacting with --newuse?
> 
> I have this feeling that "automatically enabled" flags could somehow
> have an ephemeral nature, where a flag would be enabled at build time,
> and then later a subsequent change in the graph toggles the flag off,
> creating a potentially undesirable rebuild.
> 
> I feel I might be imagining a problem because I might have a wire
> crossed somewhere, so some sort of confirmation that I'm the insane one
> and this can't happen would be reassuring :) 

I might be missing something but I don't think there would be any
problems that we don't have right now. To the contrary, this proposal
specifically reduces the amount of USE flag changes possible as flags
can be more strongly bound to valid sets only.

That said, the code running --newuse/--changed-use would probably need
to account for the constraints, i.e. include them in calculating
the effective set of USE flags. However, it's not much different from
handling use.force/use.mask, and all the metadata is in place, so it
shouldn't impact performance noticeably.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Kent Fredric 
On Mon, 29 May 2017 17:33:13 +0200
Michał Górny  wrote:

> Automatically solving USE constraints solve all three fore-mentioned
> issues with REQUIRED_USE. By default, no user intervention is required
> to solve USE constraints and package.use needs to be modified only to
> enforce a non-standard solutons

Overall I like the proposal, but one question: How do you envisage
automatic use-constraints interacting with --newuse?

I have this feeling that "automatically enabled" flags could somehow
have an ephemeral nature, where a flag would be enabled at build time,
and then later a subsequent change in the graph toggles the flag off,
creating a potentially undesirable rebuild.

I feel I might be imagining a problem because I might have a wire
crossed somewhere, so some sort of confirmation that I'm the insane one
and this can't happen would be reassuring :) 


pgpRHizN5iNmb.pgp
Description: OpenPGP digital signature

[gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Michał Górny 
Hello,

For a long time we seem to be missing appropriate tools to handle USE
flag constraints efficiently. EAPI 4 brought REQUIRED_USE but all things
considered, it has proven to be far from an optimal solution. I would
therefore like to discuss adding a better tool to amend or replace it,
to allow for automated handling of USE flag constraints.


1. Motivation
=

[[This section is purely informational. It is not up for discussion. If
you really can't help yourself and need to discuss superiority of
example A over example B, then please have mercy and wait for a few days
to give developers a chance to stay focused on the proposal at hand.]]

EAPI 4 provides REQUIRED_USE as a simple tool to enforce USE flag
constraints for packages. It can be used to express dependencies between
flags (e.g. A requires B). However, it poses a few problems which
results in developers being reluctant to use them and which limit their
use cases. Most notably:

1. They require an explicit action from the user. A large number of USE
flag constraints can be frustrating, especially when most of them are
trivial to solve.

2. They can cause a significant clutter in package.use. As a result,
changing past decisions becomes hard as the user may need to find
past USE flag changes and revert them.

3. The constraint output is sometimes considered hard to comprehend.

Those issues have resulted in developers sometimes avoiding REQUIRED_USE
in favor of other solutions such as implicit behavior (ignoring USE
flags), additional control flags (think PYTHON_SINGLE_TARGET) or
pkg_pretend() (which is horribly slow).

I think that the problems are most visible when dealing with 'provider
flags', that is USE flags that are used to choose between different
libraries providing the same feature. There are three basic approaches
to the problem:

A. Binary provider flags (+ feature flags), e.g.:

  USE='[ssl] libressl'  -> use LibreSSL
  USE='[ssl] -libressl' -> use OpenSSL
  USE='-ssl'-> disable SSL/TLS (USE=libressl ignored)

B. Unary provider flags with REQUIRED_USE:

  USE='libressl -openssl'  -> use LibreSSL
  USE='-libressl openssl'  -> use OpenSSL
  USE='libressl openssl'   -> invalid
  USE='-libressl -openssl' -> disable SSL/TLS or invalid

C. Unary provider flags without REQUIRED_USE:

  USE='libressl -openssl'  -> use LibreSSL
  USE='-libressl openssl'  -> use OpenSSL
  USE='libressl openssl'   -> use LibreSSL or OpenSSL, depending on pkg
  USE='-libressl -openssl' -> disable SSL/TLS or as above

Sometimes solutions B and C are amended with additional feature flags to
reduce the confusion.

Each of these solutions has its disadvantages. What's worse, they are
sometimes not even used consistently within a single ecosystem -- going
as far as using the same USE flag with slightly different meaning.
The Gentoo developer attitude 'my package, my way' does not help here.

Solving all of the listed problems is not possible with the existing
tools as each of the possible solutions has its own issues, and it is
impossible to get developers to agree on one of them.


2. Specification


2.1. Forced USE flag constraints


This proposal introduces USE flag constraints that are meant to be
solved automatically by the package manager. This is somewhat similar to
REQUIRED_USE, except that it does not require the user to take any
explicit action. In that regard, it is closer to conditional
package.use.force/mask.

In the basic form, it can be used to conditionally force a specific flag
to be enabled or disabled. For example:

  foo? ( bar )

would mean that the bar flag is implicitly enabled (forced) if foo is
enabled as well. Appropriately:

  foo? ( !bar )

would mean that the bar flag is implicitly disabled (masked) in that
case.

It can also be used with multi-flag ??, ^^ and || constraints, i.e.:

- ?? means that at most one of the flags can be enabled. If user
configuration causes more than one of the flags to be enabled,
additional flags are implicitly disabled (masked) to satisfy
the constraint.

- || means that at least one of the flags must be enabled. If user
configuration causes none of the flags to be enabled, one of them is
enabled implicitly (forced).

- ^^ means that exactly one of the flags must be enabled. The behavior
is a combination of both above constraints.

The automated solving of USE constraints would require the developers to
consider the implicit effect of the constraints they are writing.


2.2. UI implications


The automated flag handling would require an appropriate UI changes, to
clearly indicate whenever the flags are being altered automatically.
Otherwise, users might be confused of their requested USE flags not
being applied correctly.

In the most basic form, a solution similar to use.force/use.mask can be
used, e.g.:

  USE="[bar] [-baz] foo"

with square brackets indicating that the flags have been forced/masked
by other USE

Re: [gentoo-portage-dev] [PATCH] depgraph: make --autounmask-continue imply --autounmask

2017-05-29 Thread Zac Medico 
On Mon, May 29, 2017 at 4:03 AM, Alexander Berntsen 
wrote:

> Looks OK. Although I'm not a fan of the proposed change. Changes like
> these make scripts a tiny bit more tedious. If you have a bunch of
> --autounmask stuff in your script, you can now just do --autounmask=n
> and turn it all off. This means you'll have to turn off more stuff. And
> --autounmask-continue is supposed to be used "with great care" anyway,
> so I think it's fine to demand users to write --autounmask too.
>

Yeah, we can go the other way and make --autounmask=n trigger a warning
message when --autounmask-continue is also in the options. My main goal is
to prevent confusion in this case.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2017-05-28 23:59 UTC

2017-05-29 Thread Michał Górny 
On pon, 2017-05-29 at 12:10 +0300, nunojsi...@ist.utl.pt wrote:
> On 2017-05-29, Robin H. Johnson wrote:
> 
> > The attached list notes all of the packages that were added or removed
> > from the tree, for the week ending 2017-05-28 23:59 UTC.
> > 
> > Removals:
> > app-editors/vim-qt  20170525-10:36 mgorny   1aff8d7da4e
> 
> This was announced here in April[1]. As soon as it was announced, Gordon
> Pettey commented here[2] that upstream was fine.
> 
> A quick inspection to the $HOMEPAGE seems to point out that, at some
> point, the bitbucket repository was the main one, and github was a
> "mirror". But, by looking at the github mirror[3], it looks like
> upstream has been quite active, just not in bitbucket.
> 
> The README at github also hints that this is for Vim 8, which seems to
> be the in-tree version of Vim.
> 
> The move to github was also mentioned in gentoo bug 607136[4],
> comment 2.
> 
> Why was this last-rited with the reasoning of "Doesn't work with any
> in-tree versions of vim. Inactive upstream.", when upstream seems to be
> active *and* this was mentioned both on the mailing list and on
> bugzilla?

Because apparently nobody cared enough to fix the core issue (bump it).
If you want it back, you are free to re-add it.

> [1] http://marc.info/?l=gentoo-dev=149294484724875
> [2] http://marc.info/?l=gentoo-dev=149295586026533=2
> [3] https://github.com/equalsraf/vim-qt/commits/master
> [4] https://bugs.gentoo.org/show_bug.cgi?id=607136
> 

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list

2017-05-29 Thread Roy Bamford 
On 2017.05.29 11:59, Alexander Berntsen wrote:
> On 27/05/17 18:17, Patrick Lauer wrote:
> > But you do gentoo wrong, so as a user I'd like you to reconsider
> what 
> > you wrote there and maybe take a long vacation.
> I too do not hate our users (in which I include myself).
> 
> Treating users as a worthless nuisance, unless they're writing ebuilds
> or managing your precious GitHub crap, is a good way to lose users.
> 
> And even if I did hate our users, I agree with William & Ulrich.
> -- 
> Alexander
> berna...@gentoo.org
> https://secure.plaimi.net/~alexander
> 
> 

... and some of those lost users might have gone on to become devs.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpLoBjumJszq.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list

2017-05-29 Thread Alexander Berntsen 
On 27/05/17 18:17, Patrick Lauer wrote:
> But you do gentoo wrong, so as a user I'd like you to reconsider what 
> you wrote there and maybe take a long vacation.
I too do not hate our users (in which I include myself).

Treating users as a worthless nuisance, unless they're writing ebuilds
or managing your precious GitHub crap, is a good way to lose users.

And even if I did hate our users, I agree with William & Ulrich.
-- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2017-05-28 23:59 UTC

2017-05-29 Thread nunojsilva 
On 2017-05-29, Robin H. Johnson wrote:

> The attached list notes all of the packages that were added or removed
> from the tree, for the week ending 2017-05-28 23:59 UTC.
>
> Removals:
> app-editors/vim-qt  20170525-10:36 mgorny   1aff8d7da4e

This was announced here in April[1]. As soon as it was announced, Gordon
Pettey commented here[2] that upstream was fine.

A quick inspection to the $HOMEPAGE seems to point out that, at some
point, the bitbucket repository was the main one, and github was a
"mirror". But, by looking at the github mirror[3], it looks like
upstream has been quite active, just not in bitbucket.

The README at github also hints that this is for Vim 8, which seems to
be the in-tree version of Vim.

The move to github was also mentioned in gentoo bug 607136[4],
comment 2.

Why was this last-rited with the reasoning of "Doesn't work with any
in-tree versions of vim. Inactive upstream.", when upstream seems to be
active *and* this was mentioned both on the mailing list and on
bugzilla?

[1] http://marc.info/?l=gentoo-dev=149294484724875
[2] http://marc.info/?l=gentoo-dev=149295586026533=2
[3] https://github.com/equalsraf/vim-qt/commits/master
[4] https://bugs.gentoo.org/show_bug.cgi?id=607136

-- 
Nuno Silva