[gentoo-dev] Last Rites: sci-libs/keras-{applications,preprocessing}

[Jason Zaman]

# Jason Zaman  (2024-04-28)
# TensorFlow was removed from the tree in feb, Keras applications and
# preprocessing no longer have any revdeps in the tree. For ML, the
# recommendation is to install from pip in a venv.
# Removal in 30 days. Bug #930830
sci-libs/keras-applications
sci-libs/keras-preprocessing

[gentoo-dev] Last Rites: sys-fs/sandboxfs

[Jason Zaman]

# Jason Zaman  (2024-04-27)
# Sandboxfs was only experimental in Bazel. It was fully removed in Bazel-7
# Bazel was removed from gentoo in Feb.
# Removal in 30 days. Bug #930790
sys-fs/sandboxfs

Re: [gentoo-dev] Looking for co-maintainers for number of packages

[Jason Zaman]

On Sun, Jul 03, 2022 at 09:03:04PM -0700, Georgy Yakovlev wrote:
> I've been rather busy lately and can't keep up with all of my packages.
> There are pending bumps, some bugs, but nothing too crazy or hard. 
> So I'm looking for someone to co-maintain (or even take over if you
> insist) the following packages:
> 
> * dev-cpp/abseil-cpp
> Googleware, it's usually bundled into source, like gnulib, but some
> projects use system copy.
> Hardcoded flags, broken abi every other bump, may require slotting in
> the future, some revdeps rely on older versions. Not hard to maintain,
> but has more that usual blast radius.

I'll take this, I already end up having to apply random patches to make
it play well with CUDA.
> 
> * net-libs/grpc
> * dev-python/grpcio
> * dev-python/grpcio-tools
> * dev-python/grpcio-testing
> grpc stack, googleware again. rather frequent releases, lack of
> portage-able tests, as tests insist on downloading gtest stack git
> master in src_test phase.
> Technically it's already co-maintained, but I't be beneficial if we
> have more hands and eyes on this one.
> python project has been helping with python packages, but lack of tests
> makes the package somewhat risky.
> bonus points if you can test it with tensorflow.

I'm the co-maintainer on this already but as Georgy said, happy to have
other maintainers as well, I dont really interact with it other than via
TensorFlow. If people use it as deps from other things that would be
great too :)

-- Jason

Re: [gentoo-dev] cmake-utils.eclass consumers will be broken by >=dev-util/cmake-3.23.0

[Jason Zaman]

On Sat, Feb 26, 2022 at 08:11:52PM +0100, Andreas Sturmlechner wrote:
> Dear packagers,
> 
> - More than 4500 ebuilds were switched to cmake.eclass since 2019-12-21 [1]
> - Less than 110 ebuilds still inherit cmake-utils.eclass [2]
> - A change in cmake-3.23 will break all revdeps doing so
> - I am not fixing it
> - If *you* fix it, you will become the sole maintainer of cmake-utils.eclass
> - Any bugs filed as a result of this will block a future cmake-utils.eclass 
> last-rites tracker. Failure to respond will make your package a last-rites 
> candidate too.
> 
> hth.
> 
> [1] https://qa-reports.gentoo.org/output/eapi-per-eclass/cmake.eclass/
> [2] https://qa-reports.gentoo.org/output/eapi-per-eclass/cmake-utils.eclass/

Whoops, thanks for the heads up!
google-cloud-cpp is mine (a dep of tensorflow).
It took me a while to realize in the above it has both cmake{,-utils}.

Is there a migration guide or some docs about for what I need to do to
move it to the new eclass?

-- Jason

Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

[Jason Zaman]

On Tue, Nov 03, 2020 at 09:10:01AM +0100, Michał Górny wrote:
> On Tue, 2020-11-03 at 07:13 +0200, Joonas Niilola wrote:
> > I'm suggesting a new QA policy to disallow any "live-ebuild-only
> > packages" being hosted in ::gentoo.
> 
> I'm with you on this though I think it should be relaxed to disallow
> only long term presence of pure live packages.  It's fine to add a live
> ebuild first for a month or two if you're still working on something
> (just like it's fine to add a masked package).  However, it's not fine
> to leave things like this for years.
> 
> That said, maybe the policy should cover 'long-term masked packages'
> in general.  See below.

I agree with this. long term is definitely not good, but I typically add
the live ebuild to test first before I do the real ones.

SELinux packages specifically I have a script which handles bumping
all of them properly by copying the - to the current as I cut a release.
So to add a new policy, I'll add the - ebuild a while before.
The aim is obviously on the order of days but sometimes ENOTIME so it
might be a while longer.

Thanks,
Jason

Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[Jason Zaman]

On Tue, Nov 26, 2019 at 04:29:28PM +0100, Michał Górny wrote:
> On Tue, 2019-11-26 at 21:30 +0800, Jason Zaman wrote:
> > On Mon, Nov 25, 2019 at 06:38:47PM +0100, Michał Górny wrote:
> > > Hi,
> > > 
> > > TL;DR: should we depend on setuptools by default?  Alternatively, should
> > > we add distutils_enable_setuptools API to provide at least partial
> > > validity checks.
> > > 
> > > 
> > > Variant 1: automatic dependency on setuptools
> > > =
> > > Basically, we add a new trinary pre-inherit variable:
> > > 
> > > DISTUTILS_USE_SETUPTOOLS=no
> > >   -> no deps
> > > DISTUTILS_USE_SETUPTOOLS=bdepend
> > >   -> add to BDEPEND (the default)
> > > DISTUTILS_USE_SETUPTOOLS=rdepend
> > >   -> add to BDEPEND+RDEPEND
> > > 
> > > This is roughly 'erring on the safe side'.  The default will work for
> > > the majority of packages.  We will have to disable it for setuptools
> > > bootstrap deps, and devs will be able to adjust it to correct values
> > > as they update ebuilds.  For the time being, existing *DEPEND
> > > on setuptools will avoid breaking stuff.
> > > 
> > > This will also enable me to add extra QA checks to esetup.py.  It should
> > > be able to reasonably detect incorrect value and report it.  This will
> > > imply some 'false positives' for packages that use the old method of
> > > specifying setuptools in RDEPEND but that's a minor hassle.
> > > 
> > > Pros:
> > > - works out of the box for the majority of packages
> > > - enables full-range QA checking
> > > 
> > > Cons:
> > > - pre-inherit variable
> > > - some (harmless) false positives on existing packages
> > > 
> > 
> > I like variant 1 most since in almost all cases it'll be less work in
> > the ebuilds. What about distutils_optional tho? In tensorflow I have all
> > the python support behind USE="python" and guard all the deps. In the
> > optional case is there any way for this to work other than just setting
> > it to no and doing it manually?
> > I assume if i set it to no and make it optional then the esetup.py
> > checks wouldnt happen which isnt as nice.
> 
> That's a very good question, and I'm afraid I don't have a good answer. 
> To be honest, I don't see how we could solve this.
> 
> Since you need to add the appropriate variables to BDEPEND and RDEPEND
> yourself, there's little purpose in trying to introduce some kind of
> indirection for this -- it may detect that you've declared the wrong
> kind of dep but it won't detect if you used the helper variables
> correctly, so we're back to square one.
> 
> I guess the only reasonable thing to do is to ignore it entirely for
> this use case, and rely on the developer doing things right.  Hopefully,
> FWICS it's just 43 packages at the moment, so this wouldn't be that bad.

I suspected this would be the case. I think its fine to not do it in the
optional case and just update the docs to be really clear exactly what
and how the ebuild must do is good enough. 43 packages out of the many
thousand that use distutils-r1 seems like worrying about it isnt worth
it yeah.

-- Jason
> 
> -- 
> Best regards,
> Michał Górny
> 

Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[Jason Zaman]

On Mon, Nov 25, 2019 at 06:38:47PM +0100, Michał Górny wrote:
> Hi,
> 
> TL;DR: should we depend on setuptools by default?  Alternatively, should
> we add distutils_enable_setuptools API to provide at least partial
> validity checks.
> 
> 
> Variant 1: automatic dependency on setuptools
> =
> Basically, we add a new trinary pre-inherit variable:
> 
> DISTUTILS_USE_SETUPTOOLS=no
>   -> no deps
> DISTUTILS_USE_SETUPTOOLS=bdepend
>   -> add to BDEPEND (the default)
> DISTUTILS_USE_SETUPTOOLS=rdepend
>   -> add to BDEPEND+RDEPEND
> 
> This is roughly 'erring on the safe side'.  The default will work for
> the majority of packages.  We will have to disable it for setuptools
> bootstrap deps, and devs will be able to adjust it to correct values
> as they update ebuilds.  For the time being, existing *DEPEND
> on setuptools will avoid breaking stuff.
> 
> This will also enable me to add extra QA checks to esetup.py.  It should
> be able to reasonably detect incorrect value and report it.  This will
> imply some 'false positives' for packages that use the old method of
> specifying setuptools in RDEPEND but that's a minor hassle.
> 
> Pros:
> - works out of the box for the majority of packages
> - enables full-range QA checking
> 
> Cons:
> - pre-inherit variable
> - some (harmless) false positives on existing packages
> 

I like variant 1 most since in almost all cases it'll be less work in
the ebuilds. What about distutils_optional tho? In tensorflow I have all
the python support behind USE="python" and guard all the deps. In the
optional case is there any way for this to work other than just setting
it to no and doing it manually?
I assume if i set it to no and make it optional then the esetup.py
checks wouldnt happen which isnt as nice.

-- Jason

Re: [gentoo-dev] Re: [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing

[Jason Zaman]

On Sat, Sep 21, 2019 at 09:17:53PM +0200, Ulrich Mueller wrote:
> > On Sat, 21 Sep 2019, Michał Górny wrote:
> 
> > TL;DR: I'd like to replace 'GPL-2' with 'GPL-2-only' etc., having
> > the former trigger QA warning asking the dev to double-check if it's
> > 'GPL-2-only' or 'GPL-2+'.
> 
> This has been discussed before. There is no such license as GPL-2-only.

Yes there is:
https://spdx.org/licenses/GPL-2.0-only.html
https://spdx.org/licenses/GPL-2.0-or-later.html

The "GPL-2.0" one is deprecated:
https://spdx.org/licenses/GPL-2.0.html

If SPDX moved to having two names "-only" and "-or-later" then we should
too.

-- Jason

[gentoo-dev] Last rites: sec-policy/selinux-perdition

[Jason Zaman]

# Jason Zaman  (25 Apr 2019)
# net-mail/perdition was last-rited in 2016. The
# SELinux policy packge is no longer needed.
# Removal in 30 days.
sec-policy/selinux-perdition

Re: [gentoo-dev] Bazel Build eclass

[Jason Zaman]

On Sun, Nov 18, 2018 at 09:01:00AM +0100, Michał Górny wrote:
> On Sun, 2018-11-18 at 15:37 +0800, Jason Zaman wrote:
> > On Sat, Nov 17, 2018 at 11:54:24PM +0100, Michał Górny wrote:
> > > On Sun, 2018-11-18 at 03:37 +0800, Jason Zaman wrote:
> > > > Hey all,
> > > > 
> > > > I've been using Bazel (https://bazel.build/) to build TensorFlow for a
> > > > while now. Here is a bazel.eclass I'd like to commit to make it easier
> > > > for packages that use it to build. It's basically bits that I've
> > > > refactored out of the TensorFlow ebuild that would be useful to other
> > > > packages as well. I have a bump to sci-libs/tensorflow-1.12.0 prepared
> > > > that uses this eclass and have tested a full install.
> > > > 
> > > > -- Jason

Here is a v2 of the eclass for review:

Major changes:
- removed MULTIBUILD_VARIANT in favour of BUILD_DIR
- changed bazel_load_distfiles() to tokenize and skip items instead of a
  giant sed command.


# Copyright 1999-2018 Jason Zaman
# Distributed under the terms of the GNU General Public License v2

# @ECLASS: bazel.eclass
# @MAINTAINER:
# Jason Zaman 
# @AUTHOR:
# Jason Zaman 
# @BLURB: Utility functions for packages using Bazel Build
# @DESCRIPTION:
# A utility eclass providing functions to run the Bazel Build system.
#
# This eclass does not export any phase functions.

case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
7)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac

if [[ ! ${_BAZEL_ECLASS} ]]; then

inherit multiprocessing toolchain-funcs

BDEPEND=">=dev-util/bazel-0.19"

# @FUNCTION: bazel_get_flags
# @DESCRIPTION:
# Obtain and print the bazel flags for target and host *FLAGS.
#
# To add more flags to this, append the flags to the
# appropriate variable before calling this function
bazel_get_flags() {
local i fs=()
for i in ${CFLAGS}; do
fs+=( "--conlyopt=${i}" )
done
for i in ${BUILD_CFLAGS}; do
fs+=( "--host_conlyopt=${i}" )
done
for i in ${CXXFLAGS}; do
fs+=( "--cxxopt=${i}" )
done
for i in ${BUILD_CXXFLAGS}; do
fs+=( "--host_cxxopt=${i}" )
done
for i in ${CPPFLAGS}; do
fs+=( "--conlyopt=${i}" "--cxxopt=${i}" )
done
for i in ${BUILD_CPPFLAGS}; do
fs+=( "--host_conlyopt=${i}" "--host_cxxopt=${i}" )
done
for i in ${LDFLAGS}; do
fs+=( "--linkopt=${i}" )
done
for i in ${BUILD_LDFLAGS}; do
fs+=( "--host_linkopt=${i}" )
done
echo "${fs[*]}"
}

# @FUNCTION: bazel_setup_bazelrc
# @DESCRIPTION:
# Creates the bazelrc with common options that will be passed
# to bazel. This will be called by ebazel automatically so
# does not need to be called from the ebuild.
bazel_setup_bazelrc() {
if [[ -f "${T}/bazelrc" ]]; then
return
fi

# F: fopen_wr
# P: /proc/self/setgroups
# Even with standalone enabled, the Bazel sandbox binary is run for 
feature test:
# 
https://github.com/bazelbuild/bazel/blob/7b091c1397a82258e26ab5336df6c8dae1d97384/src/main/java/com/google/devtools/build/lib/sandbox/LinuxSandboxedSpawnRunner.java#L61
# 
https://github.com/bazelbuild/bazel/blob/76555482873ffcf1d32fb40106f89231b37f850a/src/main/tools/linux-sandbox-pid1.cc#L113
addpredict /proc

mkdir -p "${T}/bazel-cache" || die
mkdir -p "${T}/bazel-distdir" || die

cat > "${T}/bazelrc" <<-EOF || die
startup --batch

# dont strip HOME, portage sets a temp per-package dir
build --action_env HOME

# make bazel respect MAKEOPTS
build --jobs=$(makeopts_jobs)
build --compilation_mode=opt --host_compilation_mode=opt

# FLAGS
build $(bazel_get_flags)

# Use standalone strategy to deactivate the bazel sandbox, 
since it
# conflicts with FEATURES=sandbox.
build --spawn_strategy=standalone --genrule_strategy=standalone
test --spawn_strategy=standalone --genrule_strategy=standalone

build --strip=never
build --verbose_failures --noshow_loading_progress
test --verbose_test_summary --verbose_failures 
--noshow_loading_progress

# make bazel only fetch distfiles from the cache
fet

Re: [gentoo-dev] Bazel Build eclass

[Jason Zaman]

On Sat, Nov 17, 2018 at 11:54:24PM +0100, Michał Górny wrote:
> On Sun, 2018-11-18 at 03:37 +0800, Jason Zaman wrote:
> > Hey all,
> > 
> > I've been using Bazel (https://bazel.build/) to build TensorFlow for a
> > while now. Here is a bazel.eclass I'd like to commit to make it easier
> > for packages that use it to build. It's basically bits that I've
> > refactored out of the TensorFlow ebuild that would be useful to other
> > packages as well. I have a bump to sci-libs/tensorflow-1.12.0 prepared
> > that uses this eclass and have tested a full install.
> > 
> > -- Jason
> > 
> > # Copyright 1999-2018 Jason Zaman
> > # Distributed under the terms of the GNU General Public License v2
> > 
> > # @ECLASS: bazel.eclass
> > # @MAINTAINER:
> > # Jason Zaman 
> > # @AUTHOR:
> > # Jason Zaman 
> > # @BLURB: Utility functions for packages using Bazel Build
> > # @DESCRIPTION:
> > # A utility eclass providing functions to run the Bazel Build system.
> > #
> > # This eclass does not export any phase functions.
> > 
> > case "${EAPI:-0}" in
> > 0|1|2|3|4|5|6)
> > die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> > ;;
> > 7)
> > ;;
> > *)
> > die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> > ;;
> > esac
> > 
> > if [[ ! ${_BAZEL_ECLASS} ]]; then
> > 
> > inherit multiprocessing toolchain-funcs
> > 
> > BDEPEND=">=dev-util/bazel-0.19"
> > 
> > # @FUNCTION: bazel_get_flags
> > # @DESCRIPTION:
> > # Obtain and print the bazel flags for target and host *FLAGS.
> > #
> > # To add more flags to this, append the flags to the
> > # appropriate variable before calling this function
> > bazel_get_flags() {
> > local i fs=()
> > for i in ${CFLAGS}; do
> > fs+=( "--conlyopt=${i}" )
> > done
> > for i in ${BUILD_CFLAGS}; do
> > fs+=( "--host_conlyopt=${i}" )
> > done
> > for i in ${CXXFLAGS}; do
> > fs+=( "--cxxopt=${i}" )
> > done
> > for i in ${BUILD_CXXFLAGS}; do
> > fs+=( "--host_cxxopt=${i}" )
> > done
> > for i in ${CPPFLAGS}; do
> > fs+=( "--conlyopt=${i}" "--cxxopt=${i}" )
> > done
> > for i in ${BUILD_CPPFLAGS}; do
> > fs+=( "--host_conlyopt=${i}" "--host_cxxopt=${i}" )
> > done
> > for i in ${LDFLAGS}; do
> > fs+=( "--linkopt=${i}" )
> > done
> > for i in ${BUILD_LDFLAGS}; do
> > fs+=( "--host_linkopt=${i}" )
> > done
> > echo "${fs[*]}"
> > }
> > 
> > # @FUNCTION: bazel_setup_bazelrc
> > # @DESCRIPTION:
> > # Creates the bazelrc with common options that will be passed
> > # to bazel. This will be called by ebazel automatically so
> > # does not need to be called from the ebuild.
> > bazel_setup_bazelrc() {
> > if [[ -f "${T}/bazelrc" ]]; then
> > return
> > fi
> > 
> > # F: fopen_wr
> > # P: /proc/self/setgroups
> > # Even with standalone enabled, the Bazel sandbox binary is run for 
> > feature test:
> > # 
> > https://github.com/bazelbuild/bazel/blob/7b091c1397a82258e26ab5336df6c8dae1d97384/src/main/java/com/google/devtools/build/lib/sandbox/LinuxSandboxedSpawnRunner.java#L61
> > # 
> > https://github.com/bazelbuild/bazel/blob/76555482873ffcf1d32fb40106f89231b37f850a/src/main/tools/linux-sandbox-pid1.cc#L113
> > addpredict /proc
> > 
> > mkdir -p "${T}/bazel-cache" || die
> > mkdir -p "${T}/bazel-distdir" || die
> > 
> > cat > "${T}/bazelrc" <<-EOF || die
> > startup --batch
> 
> Maybe indent this stuff to make it stand out from ebuild code.
> 
> > 
> > # dont strip HOME, portage sets a temp per-package dir
> > build --action_env HOME
> > 
> > # make bazel respect MAKEOPTS
> > build --jobs=$(makeopts_jobs)
> > build --compilation_mode=opt --host_compilation_mode=opt
> > 
> > # FLAGS
> > build $(bazel_get_flags)
> > 
> > # Use standalone strategy to deactivate the bazel sandbox, since it
> > # conflicts with FEATURES=sandbox.
> > build --spawn_strategy=standalone 

[gentoo-dev] Bazel Build eclass

[Jason Zaman]

Hey all,

I've been using Bazel (https://bazel.build/) to build TensorFlow for a
while now. Here is a bazel.eclass I'd like to commit to make it easier
for packages that use it to build. It's basically bits that I've
refactored out of the TensorFlow ebuild that would be useful to other
packages as well. I have a bump to sci-libs/tensorflow-1.12.0 prepared
that uses this eclass and have tested a full install.

-- Jason

# Copyright 1999-2018 Jason Zaman
# Distributed under the terms of the GNU General Public License v2

# @ECLASS: bazel.eclass
# @MAINTAINER:
# Jason Zaman 
# @AUTHOR:
# Jason Zaman 
# @BLURB: Utility functions for packages using Bazel Build
# @DESCRIPTION:
# A utility eclass providing functions to run the Bazel Build system.
#
# This eclass does not export any phase functions.

case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
7)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac

if [[ ! ${_BAZEL_ECLASS} ]]; then

inherit multiprocessing toolchain-funcs

BDEPEND=">=dev-util/bazel-0.19"

# @FUNCTION: bazel_get_flags
# @DESCRIPTION:
# Obtain and print the bazel flags for target and host *FLAGS.
#
# To add more flags to this, append the flags to the
# appropriate variable before calling this function
bazel_get_flags() {
local i fs=()
for i in ${CFLAGS}; do
fs+=( "--conlyopt=${i}" )
done
for i in ${BUILD_CFLAGS}; do
fs+=( "--host_conlyopt=${i}" )
done
for i in ${CXXFLAGS}; do
fs+=( "--cxxopt=${i}" )
done
for i in ${BUILD_CXXFLAGS}; do
fs+=( "--host_cxxopt=${i}" )
done
for i in ${CPPFLAGS}; do
fs+=( "--conlyopt=${i}" "--cxxopt=${i}" )
done
for i in ${BUILD_CPPFLAGS}; do
fs+=( "--host_conlyopt=${i}" "--host_cxxopt=${i}" )
done
for i in ${LDFLAGS}; do
fs+=( "--linkopt=${i}" )
done
for i in ${BUILD_LDFLAGS}; do
fs+=( "--host_linkopt=${i}" )
done
echo "${fs[*]}"
}

# @FUNCTION: bazel_setup_bazelrc
# @DESCRIPTION:
# Creates the bazelrc with common options that will be passed
# to bazel. This will be called by ebazel automatically so
# does not need to be called from the ebuild.
bazel_setup_bazelrc() {
if [[ -f "${T}/bazelrc" ]]; then
return
fi

# F: fopen_wr
# P: /proc/self/setgroups
# Even with standalone enabled, the Bazel sandbox binary is run for 
feature test:
# 
https://github.com/bazelbuild/bazel/blob/7b091c1397a82258e26ab5336df6c8dae1d97384/src/main/java/com/google/devtools/build/lib/sandbox/LinuxSandboxedSpawnRunner.java#L61
# 
https://github.com/bazelbuild/bazel/blob/76555482873ffcf1d32fb40106f89231b37f850a/src/main/tools/linux-sandbox-pid1.cc#L113
addpredict /proc

mkdir -p "${T}/bazel-cache" || die
mkdir -p "${T}/bazel-distdir" || die

cat > "${T}/bazelrc" <<-EOF || die
startup --batch

# dont strip HOME, portage sets a temp per-package dir
build --action_env HOME

# make bazel respect MAKEOPTS
build --jobs=$(makeopts_jobs)
build --compilation_mode=opt --host_compilation_mode=opt

# FLAGS
build $(bazel_get_flags)

# Use standalone strategy to deactivate the bazel sandbox, since it
# conflicts with FEATURES=sandbox.
build --spawn_strategy=standalone --genrule_strategy=standalone
test --spawn_strategy=standalone --genrule_strategy=standalone

build --strip=never
build --verbose_failures --noshow_loading_progress
test --verbose_test_summary --verbose_failures --noshow_loading_progress

# make bazel only fetch distfiles from the cache
fetch --repository_cache="${T}/bazel-cache/" 
--distdir="${T}/bazel-distdir/"
build --repository_cache="${T}/bazel-cache/" 
--distdir="${T}/bazel-distdir/"

build --define=PREFIX=${EPREFIX%/}/usr
build --define=LIBDIR=\$(PREFIX)/$(get_libdir)

EOF

tc-is-cross-compiler || \
echo "build --nodistinct_host_configuration" >> "${T}/bazelrc" 
|| die
}

# @FUNCTION: ebazel
# @USAGE: [...]
# @DESCRIPTION:
# Run bazel with the bazelrc and output_base.
#
# If $MULTIBUILD_VARIANT is set, this will make an output_base
# specific to that variant.
# bazel_setup_bazelrc will be called and the created bazelrc
# will be passed to bazel.
#
# Will automatically die if bazel does not exit c

Re: [gentoo-dev] [PATCH 1/3] check-reqs.eclass: update to EAPI7

[Jason Zaman]

All three of these patches are now in the tree :)
-- Jason
On Tue, Sep 18, 2018 at 02:38:15PM +0800, Jason Zaman wrote:
> Signed-off-by: Jason Zaman 
> ---
>  eclass/check-reqs.eclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
> index d1ed395c8b1..689944c8770 100644
> --- a/eclass/check-reqs.eclass
> +++ b/eclass/check-reqs.eclass
> @@ -7,7 +7,7 @@
>  # @AUTHOR:
>  # Bo Ørsted Andresen 
>  # Original Author: Ciaran McCreesh 
> -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
> +# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
>  # @BLURB: Provides a uniform way of handling ebuild which have very high 
> build requirements
>  # @DESCRIPTION:
>  # This eclass provides a uniform way of handling ebuilds which have very high
> @@ -63,7 +63,7 @@ if [[ ! ${_CHECK_REQS_ECLASS_} ]]; then
>  EXPORT_FUNCTIONS pkg_setup
>  case "${EAPI:-0}" in
>   0|1|2|3) ;;
> - 4|5|6) EXPORT_FUNCTIONS pkg_pretend ;;
> + 4|5|6|7) EXPORT_FUNCTIONS pkg_pretend ;;
>   *) die "EAPI=${EAPI} is not supported" ;;
>  esac
>  
> -- 
> 2.16.4
> 
> 

[gentoo-dev] [PATCH 3/3] cuda.eclass: Add version and sandbox helper methods

[Jason Zaman]

cuda_toolkit_version returns the version of dev-util/nvidia-cuda-toolkit
cuda_cudnn_version returns the version of dev-libs/cudnn
cuda_add_sandbox adds the nvidia dev nodes to the sandbox

Signed-off-by: Jason Zaman 
---
 eclass/cuda.eclass | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index 3a6fc3a31d1..f1c09ca2e45 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -144,6 +144,48 @@ cuda_sanitize() {
export NVCCFLAGS
 }
 
+# @FUNCTION: cuda_add_sandbox
+# @USAGE: [-w]
+# @DESCRIPTION:
+# Add nvidia dev nodes to the sandbox predict list.
+# with -w, add to the sandbox write list.
+cuda_add_sandbox() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   local i
+   for i in /dev/nvidia*; do
+   if [[ $1 == '-w' ]]; then
+   addwrite $i
+   else
+   addpredict $i
+   fi
+   done
+}
+
+# @FUNCTION: cuda_toolkit_version
+# @DESCRIPTION:
+# echo the installed version of dev-util/nvidia-cuda-toolkit
+cuda_toolkit_version() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   local v
+   v="$(best_version dev-util/nvidia-cuda-toolkit)"
+   v="${v##*cuda-toolkit-}"
+   ver_cut 1-2 "${v}"
+}
+
+# @FUNCTION: cuda_cudnn_version
+# @DESCRIPTION:
+# echo the installed version of dev-libs/cudnn
+cuda_cudnn_version() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   local v
+   v="$(best_version dev-libs/cudnn)"
+   v="${v##*cudnn-}"
+   ver_cut 1-2 "${v}"
+}
+
 # @FUNCTION: cuda_src_prepare
 # @DESCRIPTION:
 # Sanitise and export NVCCFLAGS by default
-- 
2.16.4

[gentoo-dev] [PATCH 2/3] cuda.eclass: update to EAPI7, remove 0-4

[Jason Zaman]

cuda.eclass is only used from EAPI5,6 currently so remove support for
older EAPIs.

Updating to EAPI7 means removing versionator. It was only used to sort
the cuda versions. Instead first try the current GCC version, if that
fails try best_version, if that still fails just pick the last in
the list that works. They are already sorted and hopefully stay that
way so version_sort is not required.

Signed-off-by: Jason Zaman 
---
 eclass/cuda.eclass | 81 +++---
 1 file changed, 47 insertions(+), 34 deletions(-)

diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index 688251f3a30..3a6fc3a31d1 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -1,12 +1,21 @@
 # Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
-inherit flag-o-matic toolchain-funcs versionator
+case "${EAPI:-0}" in
+   0|1|2|3|4)
+   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
+   ;;
+   5|6|7)
+   ;;
+   *)
+   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   ;;
+esac
 
 # @ECLASS: cuda.eclass
 # @MAINTAINER:
 # Justin Lecher 
-# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
+# @SUPPORTED_EAPIS: 5 6 7
 # @BLURB: Common functions for cuda packages
 # @DESCRIPTION:
 # This eclass contains functions to be used with cuda package. Currently it is
@@ -18,6 +27,9 @@ inherit flag-o-matic toolchain-funcs versionator
 
 if [[ -z ${_CUDA_ECLASS} ]]; then
 
+inherit flag-o-matic toolchain-funcs
+[[ ${EAPI} == [56] ]] && inherit eapi7-ver
+
 # @ECLASS-VARIABLE: NVCCFLAGS
 # @DESCRIPTION:
 # nvcc compiler flags (see nvcc --help), which should be used like
@@ -44,15 +56,15 @@ if [[ -z ${_CUDA_ECLASS} ]]; then
 cuda_gccdir() {
debug-print-function ${FUNCNAME} "$@"
 
-   local gcc_bindir ver args="" flag ret
+   local dirs gcc_bindir ver vers="" flag
 
# Currently we only support the gnu compiler suite
-   if  ! tc-is-gcc ; then
+   if ! tc-is-gcc ; then
ewarn "Currently we only support the gnu compiler suite"
return 2
fi
 
-   while [ "$1" ]; do
+   while [[ "$1" ]]; do
case $1 in
-f)
flag="--compiler-bindir "
@@ -63,34 +75,50 @@ cuda_gccdir() {
shift
done
 
-   if ! args=$(cuda-config -s); then
+   if ! vers="$(cuda-config -s)"; then
eerror "Could not execute cuda-config"
eerror "Make sure >=dev-util/nvidia-cuda-toolkit-4.2.9-r1 is 
installed"
die "cuda-config not found"
-   else
-   args=$(version_sort ${args})
-   if [[ -z ${args} ]]; then
-   die "Could not determine supported gcc versions from 
cuda-config"
+   fi
+   if [[ -z ${vers} ]]; then
+   die "Could not determine supported gcc versions from 
cuda-config"
+   fi
+
+   # Try the current gcc version first
+   ver=$(gcc-version)
+   if [[ -n "${ver}" ]] && [[ ${vers} =~ ${ver} ]]; then
+   dirs=( ${EPREFIX}/usr/*pc-linux-gnu/gcc-bin/${ver}*/ )
+   gcc_bindir="${dirs[${#dirs[@]}-1]}"
+   fi
+
+   if [[ -z ${gcc_bindir} ]]; then
+   ver=$(best_version "sys-devel/gcc")
+   ver=$(ver_cut 1-2 "${ver##*sys-devel/gcc-}")
+
+   if [[ -n "${ver}" ]] && [[ ${vers} =~ ${ver} ]]; then
+   dirs=( ${EPREFIX}/usr/*pc-linux-gnu/gcc-bin/${ver}*/ )
+   gcc_bindir="${dirs[${#dirs[@]}-1]}"
fi
fi
 
-   for ver in ${args}; do
-   has_version "=sys-devel/gcc-${ver}*" && \
-gcc_bindir="$(ls -d 
${EPREFIX}/usr/*pc-linux-gnu/gcc-bin/${ver}* | tail -n 1)"
+   for ver in ${vers}; do
+   if has_version "=sys-devel/gcc-${ver}*"; then
+   dirs=( ${EPREFIX}/usr/*pc-linux-gnu/gcc-bin/${ver}*/ )
+   gcc_bindir="${dirs[${#dirs[@]}-1]}"
+   fi
done
 
if [[ -n ${gcc_bindir} ]]; then
if [[ -n ${flag} ]]; then
-   ret="${flag}\"${gcc_bindir}\""
+   echo "${flag}\"${gcc_bindir%/}\""
else
-   ret="${gcc_bindir}"
+   echo "${gcc_bindir%/}"
fi
-   echo ${ret}
return 0
else
-   eerror "Only gcc version(s) ${args} are supported,"
+   eerror "Only g

[gentoo-dev] [PATCH 1/3] check-reqs.eclass: update to EAPI7

[Jason Zaman]

Signed-off-by: Jason Zaman 
---
 eclass/check-reqs.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
index d1ed395c8b1..689944c8770 100644
--- a/eclass/check-reqs.eclass
+++ b/eclass/check-reqs.eclass
@@ -7,7 +7,7 @@
 # @AUTHOR:
 # Bo Ørsted Andresen 
 # Original Author: Ciaran McCreesh 
-# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
+# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
 # @BLURB: Provides a uniform way of handling ebuild which have very high build 
requirements
 # @DESCRIPTION:
 # This eclass provides a uniform way of handling ebuilds which have very high
@@ -63,7 +63,7 @@ if [[ ! ${_CHECK_REQS_ECLASS_} ]]; then
 EXPORT_FUNCTIONS pkg_setup
 case "${EAPI:-0}" in
0|1|2|3) ;;
-   4|5|6) EXPORT_FUNCTIONS pkg_pretend ;;
+   4|5|6|7) EXPORT_FUNCTIONS pkg_pretend ;;
*) die "EAPI=${EAPI} is not supported" ;;
 esac
 
-- 
2.16.4

Re: [gentoo-dev] [RFC] Make 'cuda' a global USE flag

[Jason Zaman]

On Mon, Sep 17, 2018 at 04:00:26PM +0200, Guilherme Amadio wrote:
> Hi everyone,
> 
> We have several packages (~35) with local USE=cuda. Should we make that
> a global USE flag? It's a quite generic flag for GPU support, so I was
> surprised to learn it was still local when I added support for it to a
> package recently.

Sounds good to me, I was also surprised when I added the cuda
useflag to TensorFlow.

> Another thing we might want to discuss is a global setting for the CUDA
> architecture to be used¹. We compile from source, so it would be a shame
> not to compile with the right features for newer GPUs². Maybe just
> advertising the NVCCFLAGS one should put in make.conf is enough?

Is this the CUDA Capability (ie https://developer.nvidia.com/cuda-gpus)?
TensorFlow's configure currently autodetects it based on what the card
supports and builds for that version (or versions). Or you can set
TF_CUDA_COMPUTE_CAPABILITIES="6.1" in make.conf. If you would like to
standardize this I'll gladly change to use that.

I'm also updating cuda.eclass for EAPI7, I will send patches to the list
soon. I'm also adding a couple other functions for things I use in TF,
If there are more things you want to add, they should all go in at once.

-- Jason

> Cheers,
> —Guilherme
> 
> 1. 
> https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#options-for-steering-gpu-code-generation
> 2. 
> https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#gpu-feature-list
> 

Re: [gentoo-dev] Changing policy about -Werror

[Jason Zaman]

On Mon, Sep 10, 2018 at 01:51:15PM -0700, Matt Turner wrote:
> On Mon, Sep 10, 2018 at 1:34 PM Chí-Thanh Christopher Nguyễn
>  wrote:
> >
> > Jason Zaman schrieb:
> > >> No. With -Werror, upstream indicates that if a warning occurs, the build
> > >> should fail and the resulting code not be installed on user systems.
> > >>
> > >> Instead, someone knowledgeable should look at the situation *first* and
> > >> determine whether it is a bogus warning, a trivial issue, or something 
> > >> which
> > >> warrants further attention.
> > >>
> > >> I have long disagreed with QA policy on this, and think that ebuilds 
> > >> should
> > >> respect upstream here. Of course giving users the ability to override.
> > >
> > > I disagree. -Werror means that upstream wants it to build without
> > > warnings on their distro with their version of the compiler with their
> > > versions of all the libraries.
> >
> > It means, upstream wants it to build without warnings everywhere. And if a
> > warning occurs (due to change in compiler, libraries, architecture, etc.),
> > have a developer look at it first before installing the code on user 
> > systems.
> 
> This sounds good in theory, but I think it's pretty well established
> that in practice this isn't effective and instead is a large waste of
> time. In fact, the foundational premise that it's possible to build
> without warnings everywhere is simply wrong.
> 
> Consider again the bug that started this. The maintainer had not built
> this configuration. None of the arch teams had built this
> configuration until I did for the last architecture Cc'd. The patch
> committed doesn't change anything installed on the system, if not for
> Werror preventing the code from building.

Replying to a somewhat random post. There are two separate things here
that people are discussing here but are not the same thing.

1) We want to know when a package has terrible warnings when installing
it so we can report upstream and know that something might have gone
wrong.

2) There are a lot of spurious warnings that are worthless and would
just annoy *everyone*. They are still legit warnings so its not like
they should go away but they should not break the build.

-Werror trips up on both of these which is why everyone dislikes it.
We want to inform people about only 1) not 2). The solution to this is
https://gitweb.gentoo.org/proj/portage.git/tree/bin/install-qa-check.d/90gcc-warnings
(There is also an equivalent clang-warnings check too). These spit out 
"QA Notice: Package triggers severe warnings which indicate that it may
exhibit random runtime failures." and a huge list of them.

These are a focused list of the worst warnings that should be fixed
first before all the others. If your goal is to improve the quality of
code in general this qa-check is much better than using Werror on
everything.

Stick this in your make.conf:
PORTAGE_ELOG_SYSTEM="echo save"
PORTAGE_ELOG_CLASSES="warn error log qa"
I'm pretty sure toralf's tinderbox already has these enabled but all
devs should too.

-- Jason

Re: [gentoo-dev] Changing policy about -Werror

[Jason Zaman]

On Mon, Sep 10, 2018 at 01:46:51AM +0200, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
> > Are you suggesting that
> > upstream is going to detect all those situations and prevent them from
> > occurring, or are you going to WONTFIX the resulting bugs?
> 
> No. With -Werror, upstream indicates that if a warning occurs, the build 
> should fail and the resulting code not be installed on user systems.
> 
> Instead, someone knowledgeable should look at the situation *first* and 
> determine whether it is a bogus warning, a trivial issue, or something which 
> warrants further attention.
> 
> I have long disagreed with QA policy on this, and think that ebuilds should 
> respect upstream here. Of course giving users the ability to override.

I disagree. -Werror means that upstream wants it to build without
warnings on their distro with their version of the compiler with their
versions of all the libraries. Even if upstream was using gentoo
(they're not) they'd need to be testing both stable and unstable
toolchains since there are frequently warnings that show up in one and
not the other and also between gcc/clang.

I agree with jer on this, if you want specific warnings to be errors use
-Werror=foo or something not a blanket -Werror.

There are things that upstream absolutely should be setting which make a
big difference for security like FORTIFY_SOURCE but hardened already has
that set so I get this and thus basically everything would fail to
compile.

$ gcc -O1 -D_FORTIFY_SOURCE=2 foo.c
:0:0: warning: "_FORTIFY_SOURCE" redefined
: note: this is the location of the previous definition

This all on amd64 too. If we start with other arches or cross compilers
or other things then -Werror is just not possible.

-- Jason

Re: [gentoo-dev] [PATCH 1/4] xdg-utils.eclass: make EAPI 7 ready

[Jason Zaman]

On Wed, Jun 20, 2018 at 06:01:10PM -0500, Marty E. Plummer wrote:
> On Wed, Jun 20, 2018 at 11:33:53PM +0100, James Le Cuirot wrote:
> > On Wed, 20 Jun 2018 17:21:09 -0500
> > "Marty E. Plummer"  wrote:
> > 
> > > On Wed, Jun 20, 2018 at 09:03:44PM +0800, Jason Zaman wrote:
> > > > On Wed, Jun 20, 2018 at 02:10:50AM -0500, Marty E. Plummer wrote:  
> > > > > Use ${EROOT%/} whereever possible, as the tools and directories which
> > > > > are used with it are already prefixed with a /
> > > > > 
> > > > > Package-Manager: Portage-2.3.40, Repoman-2.3.9
> > > > > ---
> > > > >  eclass/xdg-utils.eclass | 10 +-
> > > > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/eclass/xdg-utils.eclass b/eclass/xdg-utils.eclass
> > > > > index ac075185d8e..8dba5ed6861 100644
> > > > > --- a/eclass/xdg-utils.eclass
> > > > > +++ b/eclass/xdg-utils.eclass
> > > > > @@ -66,7 +66,7 @@ xdg_environment_reset() {
> > > > >  # Updates the .desktop files database.
> > > > >  # Generates a list of mimetypes linked to applications that can 
> > > > > handle them
> > > > >  xdg_desktop_database_update() {
> > > > > - local updater="${EROOT}${DESKTOP_DATABASE_UPDATE_BIN}"
> > > > > + local updater="${EROOT%/}${DESKTOP_DATABASE_UPDATE_BIN}"  
> > > > 
> > > > Shouldn't things like this be $BROOT since they're being run? $EROOT
> > > > might be a different architecture that may or may not run at all on the
> > > > build machine.
> > > >   
> > > Good point, but here's a question; if EROOT=${ROOT%/}${EPREFIX}, how do
> > > we use BROOT here? EBROOT? Or longhand ${BROOT%/}${EPREFIX} ? I think
> > > that may be a use case that got missed in the EAPI 7 discussions.
> > 
> > BROOT is already prefixed as BROOT without a prefix would just be /.
> > 
> I don't follow. Its my understanding that BROOT ~= ROOT for most
> situations. But consider this setup:
> Ubuntu amd64 with Gentoo Prefix, emerging a native arm @system to
> /mnt/arm EPREFIX = /home/user/gentoo.
> 
> In this situation, ROOT=/mnt/arm, EROOT=/mnt/arm, but what is BROOT? /,
> or /home/usr/gentoo?

https://dev.gentoo.org/~mgorny/articles/the-ultimate-guide-to-eapi-7.html#broot-variable-for-bdepend

Basically BROOT already contains EPREFIX or BPREFIX or whatever it would
be called. There is like no need for an un-prefixed BROOT so its just
merged in. so you should just need "${BROOT}/usr/bin/update-mime-database"

-- Jason

> > -- 
> > James Le Cuirot (chewi)
> > Gentoo Linux Developer
> 
> 
> 

Re: [gentoo-dev] [PATCH 1/4] xdg-utils.eclass: make EAPI 7 ready

[Jason Zaman]

On Wed, Jun 20, 2018 at 02:10:50AM -0500, Marty E. Plummer wrote:
> Use ${EROOT%/} whereever possible, as the tools and directories which
> are used with it are already prefixed with a /
> 
> Package-Manager: Portage-2.3.40, Repoman-2.3.9
> ---
>  eclass/xdg-utils.eclass | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/eclass/xdg-utils.eclass b/eclass/xdg-utils.eclass
> index ac075185d8e..8dba5ed6861 100644
> --- a/eclass/xdg-utils.eclass
> +++ b/eclass/xdg-utils.eclass
> @@ -15,7 +15,7 @@
>  #  * XDG mime information database management
>  
>  case "${EAPI:-0}" in
> - 0|1|2|3|4|5|6) ;;
> + 0|1|2|3|4|5|6|7) ;;
>   *) die "EAPI=${EAPI} is not supported" ;;
>  esac
>  
> @@ -66,7 +66,7 @@ xdg_environment_reset() {
>  # Updates the .desktop files database.
>  # Generates a list of mimetypes linked to applications that can handle them
>  xdg_desktop_database_update() {
> - local updater="${EROOT}${DESKTOP_DATABASE_UPDATE_BIN}"
> + local updater="${EROOT%/}${DESKTOP_DATABASE_UPDATE_BIN}"

Shouldn't things like this be $BROOT since they're being run? $EROOT
might be a different architecture that may or may not run at all on the
build machine.

-- Jason

>   if [[ ${EBUILD_PHASE} != post* ]] ; then
>   die "xdg_desktop_database_update must be used in pkg_post* 
> phases."
> @@ -78,7 +78,7 @@ xdg_desktop_database_update() {
>   fi
>  
>   ebegin "Updating .desktop files database"
> - "${updater}" -q "${EROOT}${DESKTOP_DATABASE_DIR}"
> + "${updater}" -q "${EROOT%/}${DESKTOP_DATABASE_DIR}"
>   eend $?
>  }
>  
> @@ -87,7 +87,7 @@ xdg_desktop_database_update() {
>  # Update the mime database.
>  # Creates a general list of mime types from several sources
>  xdg_mimeinfo_database_update() {
> - local updater="${EROOT}${MIMEINFO_DATABASE_UPDATE_BIN}"
> + local updater="${EROOT%/}${MIMEINFO_DATABASE_UPDATE_BIN}"
>  
>   if [[ ${EBUILD_PHASE} != post* ]] ; then
>   die "xdg_mimeinfo_database_update must be used in pkg_post* 
> phases."
> @@ -99,6 +99,6 @@ xdg_mimeinfo_database_update() {
>   fi
>  
>   ebegin "Updating shared mime info database"
> - "${updater}" "${EROOT}${MIMEINFO_DATABASE_DIR}"
> + "${updater}" "${EROOT%/}${MIMEINFO_DATABASE_DIR}"
>   eend $?
>  }
> -- 
> 2.17.1
> 
> 

Re: [gentoo-dev] [RFC PATCH] profiles/base: Set initial ENV_UNSET (EAPI 7)

[Jason Zaman]

On Wed, May 02, 2018 at 05:42:19PM +0200, Michał Górny wrote:
> Now that EAPI 7 is accepted and implemented in Portage, provide
> the initial environment blacklist for coming EAPI 7 ebuilds.  The list
> is based on existing eclasses, xdg-utils mostly.  Rationale is provided
> in the comment above ENV_UNSET.

What about XAUTHORITY since you're doing DISPLAY?
and maybe SSH_AUTH_SOCK would make sense too?

-- Jason

> ---
>  profiles/base/make.defaults | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
> index bd038bebf167..c9a964360694 100644
> --- a/profiles/base/make.defaults
> +++ b/profiles/base/make.defaults
> @@ -22,6 +22,16 @@ USE_EXPAND_HIDDEN="USERLAND KERNEL ELIBC ABI_MIPS ABI_PPC 
> ABI_S390 ABI_X86 CPU_F
>  CONFIG_PROTECT="/etc"
>  CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf"
>  
> +# EAPI 7 environment variable blacklist.
> +#
> +# XDG_* since the values coming from user environment can collide with
> +# ebuild-set ${HOME} (e.g. by referring to user's home directory).
> +# We exclude XDG_DATA_DIRS & XDG_CONFIG_DIRS as those are set in env.d.
> +#
> +# DBUS_SESSION_BUS_ADDRESS to disconnect from user's session bus.
> +# DISPLAY to disconnect from the user's running X server.
> +ENV_UNSET="XDG_DATA_HOME XDG_CONFIG_HOME XDG_CACHE_HOME XDG_RUNTIME_DIR 
> DBUS_SESSION_BUS_ADDRESS DISPLAY"
> +
>  # Variables that are set exclusively by the profile
>  # and not by user configuration files.
>  PROFILE_ONLY_VARIABLES="${PROFILE_ONLY_VARIABLES} ELIBC IUSE_IMPLICIT KERNEL 
> USERLAND USE_EXPAND_IMPLICIT USE_EXPAND_UNPREFIXED USE_EXPAND_VALUES_ELIBC 
> USE_EXPAND_VALUES_KERNEL USE_EXPAND_VALUES_USERLAND"
> -- 
> 2.17.0
> 
> 

Re: [gentoo-dev] rfc: virtual/init for init process

[Jason Zaman]

On Wed, Apr 25, 2018 at 02:20:29PM -0500, William Hubbs wrote:
> Hi all,
> 
> In the past, openrc has had a dependency on sysvvinit because it called
> killall5. Since it doesn't do that any more, I have been asked to remove
> the dependency [1]. Another advantage of doing this is that people will
> be able to build profiles without an init package, for containers for
> example.
> 
> To do this, I need to add virtual/init for packages that have an init
> process.  then add virtual/init to profiles/base/packages.
> 
> Please proofread virtual/init as attached before I add it to the tree.
> 
> Thanks,
> 
> William
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=599468
> 
> 

> # Copyright 1999-2018 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> 
> EAPI=6
> 
> DESCRIPTION="virtual for process 1"
> 
> SLOT="0"
> KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc 
> x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux 
> ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris 
> ~x64-solaris ~x86-solaris ~x86-winnt"
> IUSE=""

Dont you need:
IUSE="prefix selinux kernel_linux kernel_FreeBSD"

> RDEPEND="
>   !prefix? (
>   kernel_linux? (
>   || (
>   >=sys-apps/sysvinit-2.86-r6[selinux?]
>   sys-apps/systemd

For consistency with the one above, this should probably be
sys-apps/systemd[selinux?]

-- Jason

>   )
>   selinux? (
>   >=sec-policy/selinux-base-policy-2.20170204-r4
>   )
>   )
>   kernel_FreeBSD? (
>   sys-freebsd/freebsd-sbin
>   )
>   )"

Re: [gentoo-dev] Regarding the State of PaX in the tree

[Jason Zaman]

On Mon, Apr 16, 2018 at 07:53:07PM +0200, Toralf Förster wrote:
> On 04/16/2018 11:14 AM, Hanno Böck wrote:
> > There's also another question related to this: What's the future for
> > Gentoo hardened?
> > From what I can tell hardened consists of:
> > * the things that try to make it compatible with grsec/pax
> >   (more or less obsolete).
> > * things that are now in default profiles anyway (aslr, stack
> >   protector).
> > * things that probably should be in default profiles (relro, now linker
> >   flags)
> > * -fstack-check, which should eventually be replaced with
> >   -fstack-clash-protection (only available in future gcc's) and that
> >   should probably also go into default profiles.
> > * Furthermore hardened disables some useful features due to their
> >   incompatibility with pax (e.g. sanitizers).
> 
> Which let me wonder, what I would lose today by a switch from
> 17.0-hardened + USE-flags to 17.0/desktop/plasma at my KDE desktop?

Right now, the main things you'd lose are bindnow and
fstack-protector-all vs fstack-protector-strong i think. But in the
future as new hardening stuff is added to the toolchains they will
likely be enabled in hardened before default too.

-- Jason
> 
> -- 
> Toralf
> PGP 23217DA7 9B888F45
> 
> 

[gentoo-dev] Last-rites: xfce-extra/xfce-theme-manager

[Jason Zaman]

# Jason Zaman <perfin...@gentoo.org> (08 Apr 2018)
# Dead upstream, for an old version of Xfce
# Masked for removal in 30 days.
xfce-extra/xfce-theme-manager

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

[Jason Zaman]

On Sat, Jan 27, 2018 at 12:24:39AM +0100, Michał Górny wrote:
> Migrating mirrors to the hashed structure
> -

> The hard link solution allows us to save space on the master mirror.
> Additionally, if ``-H`` option is used by the mirrors it avoids
> transferring existing files again.  However, this option is known
> to be expensive and could cause significant server load.  Without it,
> all mirrors need to transfer a second copy of all the existing files.
> 
> The symbolic link solution could be more reliable if we could rely
> on mirrors using the ``--links`` rsync option.  Without that, symbolic
> links are not transferred at all.

These rsync options might help for mirrors too:
 --compare-dest=DIR  also compare destination files relative to DIR
 --copy-dest=DIR ... and include copies of unchanged files
 --link-dest=DIR hardlink to files in DIR when unchanged

> Using hashed structure for local distfiles
> --
> The hashed structure defined above could also be used for local distfile
> storage as used by the package manager.  For this to work, the package
> manager authors need to ensure that:
> 
> a. The ``${DISTDIR}`` variable in the ebuild scope points to a temporary
>directory where distfiles specific to the package are linked
>in a flat structure.
> 
> b. All tools are updated to support the nested structure.
> 
> c. The package manager provides a tool for users to easily manipulate
>distfiles, in particular to add distfiles for fetch-restricted
>packages into an appropriate subdirectory.
> 
> For extended compatibility, the package manager may support finding
> distfiles in flat and nested structure simultaneously.

trying nested first then falling back to flat would make it easy for
users if they have to download distfiles for fetch-restricted packages
because then the instructions stay as "move it to
/usr/portage/distfiles".
or alternatively the tool could have a mode which will go through all
files in the base dir and move it to where it should be in the nested
tree. then you save everything to the same dir and run edist --fix

> Rationale
> =
> Algorithm for splitting distfiles
> -
> In the original debate that occurred in bug #534528 [#BUG534528]_,
> three possible solutions for splitting distfiles were listed:
> 
> a. using initial portion of filename,
> 
> b. using initial portion of file hash,
> 
> c. using initial portion of filename hash.
> 
> The significant advantage of the filename option was simplicity.  With
> that solution, the users could easily determine the correct subdirectory
> themselves.  However, it's significant disadvantage was very uneven
> shuffling of data.  In particular, the TeΧ Live packages alone count
> almost 23500 distfiles and all use a common prefix, making it impossible
> to split them further.

the filename is the original upstream or the renamed one? eg
SRC_URI="http://foo/foo.tar -> bar.tar" it will be bar.tar?

I think im in favour of using the initial part of the filename anyway.
sure its not balanced but its still a hell of a lot more balanced than
today and its really easy.

Another thing im wondering is if we can just use the same dir layout as
the packages themselves. that would fix texlive since it has a whole lot
of separate packages. eg /usr/portage/distfiles/app-cat/pkg/pkg-1.0.tgz

there is a problem if many packages use the same distfiles (quite
extensive for SELinux, every single of the sec-policy/selinux-* packages
has identical distfiles) so im not sure how to deal with it.

this would also make it easy in future to make the sandbox restrict
access to files outside of that package if we wanted to do that.

> The alternate option of using file hash has the advantage of having
> a more balanced split.  Furthermore, since hashes are stored
> in Manifests using them is zero-cost.  However, this solution has two
> significant disadvantages:
> 
> 1. The hash values are unknown for newly-downloaded distfiles, so
>``repoman`` (or an equivalent tool) would have to use a temporary
>directory before locating the file in appropriate subdirectory.
> 
> 2. User-provided distfiles (e.g. for fetch-restricted packages) with
>hash mismatches would be placed in the wrong subdirectory,
>potentially causing confusing errors.

Not just this, but on principle, I also think you should be able to read
an ebuild and compute the url to download the file from the mirrors
without any extra knowledge (especially downloading the distfile).

> Using filename hashes has proven to provide a similar balance
> to using file hashes.  Furthermore, since filenames are known up front
> this solution does not suffer from the both listed problems.  While
> hashes need to be computed manually, hashing short string should not
> cause any performance problems.
> 
> .. figure:: 

Re: [gentoo-dev] Projects up for grabs: cron, m68k

[Jason Zaman]

On Wed, Dec 20, 2017 at 06:29:57PM +0100, Hans de Graaff wrote:
> On Wed, 2017-12-20 at 18:02 +0100, Michał Górny wrote:
> > 
> >   sys-process/vixie-cron
> 
> My understanding is that vixie-cron is no longer maintained and sys-
> process/cronie is the drop-in replacement that is now also suggested as
> the default cron in the handbook.
> 
> https://archives.gentoo.org/gentoo-dev/message/d898f86f805909eb72aba61d
> 2dca8523
> 
> I seem to recall a more recent discussion about this as well, but can't
> find it at the moment.
> 
> Perhaps it is time to mask vixie-cron for removal?

I just updated the SELinux patch on vixie-cron and stabilized it a while
ago, it works fine and doesnt need all that much maintenance. I vote
keep it, i'll look after it. If it has some big architectural issues
later then we can last-rite it but its been reliable so far.

I added myself to the Cron project with blueness.

-- Jason

Re: [gentoo-dev] Re: Revisions for USE flag changes

[Jason Zaman]

On Tue, Aug 15, 2017 at 11:22:54PM -0400, Michael Orlitzky wrote:
> On 08/14/2017 08:01 AM, Jason Zaman wrote:
> > 
> > I'll give an example where revbumps are significantly inferior to 
> > --changed-use.
> > 
> > ...  With --changed-use, only the people who need it (ie selinux
> > users) will rebuild and everyone is happy (selinux users because the
> > program now works and non-selinux users because they did not rebuild
> > for no reason).
> 
> But this benefit exists only for Portage users, and can only be obtained
> by throwing the others under the bus.
> 
> (If you change RDEPEND, you need to create a new revision anyway:
> https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt)

SELinux policy packages are not strictly RDEPENDs, portage will label
packages as they are installed properly. if the policy package wasnt
installed by the time the package is installed, you can manually label a
package with rlpkg . but obviously having things jsut work is
better. and they arnt DEPEND because you dont need them to build the
package.

Any i know of no selinux users using other package managers. There are
no policies for them so they wouldnt work anyway. so no really throwing
them under the bus. I dont think the other package managers label
packages properly during install anyway even if there was a policy
written.

So there still isnt a reason to revbump a package when 99% of the world
will not want it.

-- Jason

Re: [gentoo-dev] Re: Revisions for USE flag changes

[Jason Zaman]

On Sat, Aug 12, 2017 at 09:05:58PM +1000, Michael Palimaka wrote:
> On 08/12/2017 08:29 PM, Rich Freeman wrote:
> > On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky  wrote:
> >> On 08/12/2017 03:03 AM, Michał Górny wrote:
> >>>
> >>> Please provide some examples of recent in-place USE changes that benefit
> >>> from revbumps.
> >>>
> >>
> >> There is no single example. Things only get simpler if *all* USE changes
> >> come with a new revision.
> >>
> > This policy change would make my life easier, because for big packages
> > it would encourage maintainers to not make IUSE changes until they do
> > revbumps, which would save me a build.  I'm running on relatively old
> > hardware at this point so these rebuilds actually do cost me quite a
> > bit of time.  I'm not sure that not using --changed-use is a great
> > option though as it will make it that much harder to keep things
> > consistent when I do modify my package.use/make.conf.
> > 
> 
> At least now you have the option to run without --changed-use if you
> want. If inline IUSE changes are completely banned, you will definitely
> see more pointless rebuilds on your old hardware. In my experience most
> developers make a change when there's a change to be made, and don't
> "save up" changes until some arbitrary delta is reached. We've already
> an increase in revbumps like this in other areas where inline changes
> are being discouraged.

I'll give an example where revbumps are significantly inferior to
--changed-use.

The selinux useflag is hardmasked in all profiles except the selinux
ones and 99% of users do not run selinux. I regularly add "selinux ? (
sec-policy/selinux-foo )" to RDEPEND of packages.  With --changed-use,
only the people who need it (ie selinux users) will rebuild and everyone
is happy (selinux users because the program now works and non-selinux
users because they did not rebuild for no reason).  If i were to
randomly revbump packages whenever i needed to add selinux policy deps
to packages then i would make 99% of users upset for like no reason.

-- Jason

Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"

[Jason Zaman]

On Wed, May 10, 2017 at 01:44:06AM +0200, Andreas K. Huettel wrote:
> Am Dienstag, 9. Mai 2017, 22:10:21 CEST schrieb Alexis Ballier:
> > 
> > Do you realize that this breaks linking against about any static lib
> > ever built before upgrading ? And I'm not even considering people
> > toggling the flag.
> 
> Toggling the flag is definitely bad. So it should be either on or off.
> 
> > 
> > While I believe it might be a bit too early to default-enable pie, why
> > not, but the news item *must* contain instructions that people should
> > 'emerge -e world' in order for it to work.
> > 
> > Also, I don't believe default-pie should even be a useflag. It's always
> > been forced-on for hardened and forced-off for non-hardened I think.
> > Switching between the two types of profiles has always been difficult
> > because of that kind of differences. I strongly believe this should stay
> > that way (that is: this cant be toggled by a simple useflag).
> > 
> 
> Well... Hanno and Matthias said Gentoo is about the only place where it isn't 
> on by default. So why are we "early", and why not just force it on for 
> everybody?

I just want to make sure im understanding this right, only .a files that
were compiled without -pie will cause issues if you compile the later
thing that uses the .a with -pie?
So:
1) people on hardened profiles are going to be fine no matter what?
2) only packages that have .a files need to be rebuild? (not -e @world)?
3) .a are static libs for compiling static binaries right, so nothing
will break at runtime from the change? only build failures?

I definitley think everyone on gentoo should have PIE and SSP by default
nowadays. Whats the status of -zrelro -znow on non-hardened?

This might be the kind of thing where a new set of profiles is a good
idea
1) hardened would force the flags on,
2) 13.0 non-hardened would force them off
3) 17.0 non-hardened would force them on and people have to rebuild when
  they change profiles

Im not sure how the timing of the new profile would work? only make them
once gcc-6 is stable so everyone does it at once?

-- Jason

Re: [gentoo-dev] News item for uclibc-ng

[Jason Zaman]

On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote:
> 0. Because of changes in the library structure in previous versions,
> make sure you are working with 1.0.19 and rebuild world using
> 
> emerge -evq @world
--verbose --quiet? just emerge -e @world is probably better.
> 
> 7. For good measure, rebuild the entire system
> 
> emerge —evq @world
Another non-ascii

I havent tested, but this appears what you want:
grep --color='auto' -P -n "[\x80-\xFF]" filename

from here: http://stackoverflow.com/a/9395552

-- Jason

Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles

[Jason Zaman]

On Mon, Jan 23, 2017 at 10:23:35AM +0100, Michał Górny wrote:
> Hi, everyone.
> 
> I've written a short proposal that aims to provide basic infrastructure
> for defining mix-in profiles in Gentoo. I've tried to keep it simple,
> and backwards compatible. The main goal is to be able to start defining
> some mix-ins without having to reinvent the whole profile tree.
> 
> Most important points:
> 
> 1. Mix-ins are applied on top of base profile (which works the same as
> before),
> 
> 2. Mix-ins are supported via 'eselect profile'
> replacing /etc/portage/make.profile symlink with a directory, without
> need for Portage patching (this is how Funtoo does it),
> 
> 3. Most important mix-ins are used to construct base profiles which
> provides both backwards compatibility and proper targets for repoman
> (to avoid having to check all possible mix-in combinations).

This is awesome! thanks for working on it, ive wanted it for a while
now.

The main issue I see with it is ordering. For the hardened and selinux
profiles, the order matters a lot. eg hardened defaults the jit useflag
off and the desktop profile defaults on which causes problems with PaX.
If these two mixins would end up in a kind of random order then we'll
have issues. See https://bugs.gentoo.org/492312 for a specific issue.

It could be as simple as when putting in the make.profile list, do it in
the order they are defined in the profiles.mixin file, then we can just
have hardened and selinux last and problem solved. Or could go with a
priority field but then again there is the problem of what happens when
two have the same priority?

Also how will profiles.mixin interact between different overlays? you
can manually set a parents file with features/desktop::gentoo and
feature/foo::overlay already. if foo::myoverlay is in the desktop group,
does that merge together with the desktop group ones in ::gentoo?

-- Jason

Re: [gentoo-dev] Re: Improving the stabilisation process - part 1

[Jason Zaman]

On Fri, Nov 25, 2016 at 08:27:12PM +1100, Michael Palimaka wrote:
> On 25/11/16 17:51, Jason Zaman wrote:
> >> Automation
> >> ==
> >>
> >> It's easy to forget to check that all the required dependencies are in
> >> stable before filing a stabilisation test, but this wastes the actioning
> >> developer's time. I have prepared a bot that repoman checks the list of
> >> atoms and flags the bug appropriately. This allows easy filtering out of
> >> broken requests.
> > 
> > This part would need to take into account DEPENDS ON in the bug too.
> > When I file my xfce lists I dep on the gnome stable bug since I need
> > the gtk stuff and if that isnt taken into account, repoman would just
> > die.
> 
> The bot will either try its best to take into account bug dependencies,
> or otherwise just give up and skip such a bug.
> 
> > I just realized there is another rare issue that we may have to take
> > into account. Some sets of packages *must* be stablized in lockstep. For
> > regular sets of packages like eg xfce if you leave off a bunch of the
> > extras its no big deal.
> > Eg for SELinux, the policy packages must all be stabilized all at
> > once because they depend on each other (I think perl is like this too?).
> > 
> > We would need a way for maintainers to ask for testing without actually
> > committing. The maintainer can wait till everything is done and commit
> > everything at once himself. Some flag to make the tatt script skip the
> > step would be enough I think.
> 
> Do you have a bug number handy so I can double check how the process
> normally looks?

SwifT and I both run stable machines so we always just stabilize SELinux
stuff ourselves so dont have a bug number, no.

its pretty much just:
cd sec-policy/
ekeyword amd64 x86 */*-2.20151208-r6.ebuild
git add .
repoman full
repoman commit -m 'sec-policy: Stabilize selinux policy 2.20151208-r6'

every single selinux policy package {,R}DEPENDs on
=sec-policy/selinux-base-policy-${PVR}
which in turn deps on 
=sec-policy/selinux-base-${PVR}
and we always do everything with the same revision at the same time
otherwise you get lots of weirdness. For us, each arch could be done
separately (no point tho), the main part is that committing the packages
in a random order or even alphabetical doesnt really work.

How aware of deps do we want to make such a tool? Having it figure out
the right order seems like a lot of work. Or we could force the script
to follow the order defined in the package list and then its up to the
maintainer. Then also if there is a failure either abort completely or
continue with the rest that it can (a. la --keep-going).

-- Jason

Re: [gentoo-dev] Improving the stabilisation process - part 1

[Jason Zaman]

On Fri, Nov 25, 2016 at 06:41:20AM +1100, Michael Palimaka wrote:
> As I am sure everyone is aware by now, stabilisation requests on many
> architectures take a long time to be actioned. There are many factors
> contributing to this, but today I'd like to address three specific
> problems that unnecessarily delay developers actioning those requests.:
> 
> 1. There's no easy way to pick atoms out of a stabilisation bug.
> Currently, atoms can appear, in a varying formations, in multiple
> locations: in the bug title, spread across multiple comments, in an
> attachment, [...].
> 
> 2. There's no way to determine if a stabilisation request is valid (will
> pass repoman) until someone actually tries it.
> 
> 3. There's no easy way to identify the level of testing required for any
> given request.
> 
> To address this, I am proposing some changes to Bugzilla, some
> automation, and some improved tools.
> 
> 
> Bugzilla changes
> 
> 
> I'd like to introduce two new fields:
> 
> 1. "Runtime testing required" - a drop-down list with three values:
> * (unset) - the default. The stabilising developer will use
> their best judgement as to what testing is required
> * Yes - the maintainer is specifically requesting runtime testing
> * No - the maintainer is happy to stabilise with only a build
> test (for example, trivial revision bumps, libraries with good test
> coverage, or otherwise at the maintainer's discretion)
> 
> 2. "Atoms to stabilise" - a textarea containing a list of fully
> qualified atoms. Each atom may optionally be followed by a
> whitespace-delimited list of architectures for which that atom should be
> stabilised. If an atom is not followed by any list of architectures, it
> is assumed it should be stabilised for all architectures CC'd on the bug.
> 
> Example atom list from a bug with amd64, arm, and x86 in CC:
> 
> =app-foo/bar-1.2.3   # will be stabilised on amd64, arm, and x86
> =app-foo/baz-2.3.4 amd64 x86 # will be stabilised on only amd64 and x86
> 
> I'd also like to introduce a flag called "repoman-tested". This will be
> used identify stabilisation requests that have been automatically
> repoman checked by a bot (described below).
> 
> To prevent cluttering the Bugzilla interface, I suggest resurrecting the
> "Stabilisation" component and having these new fields appear only for
> bugs filed there and in "Security: Vulnerabilities" (so not to disrupt
> the security team's workflow).
> 
> 
> Automation
> ==
> 
> It's easy to forget to check that all the required dependencies are in
> stable before filing a stabilisation test, but this wastes the actioning
> developer's time. I have prepared a bot that repoman checks the list of
> atoms and flags the bug appropriately. This allows easy filtering out of
> broken requests.

This part would need to take into account DEPENDS ON in the bug too.
When I file my xfce lists I dep on the gnome stable bug since I need
the gtk stuff and if that isnt taken into account, repoman would just
die.
> 
> Improved tools
> ==
> 
> To support the above, I am also preparing some tools to streamline the
> process further:
> 
> * A script to, given a bug, produce an architecture-specific list of
> atoms ready to feed into package.accept_keywords / emerge
> 
> * An updated version of app-portage/tatt (allowing easy testing of USE
> flag combinations, reverse dependencies, committing keyword changes etc.)
> 
> * Your idea here
> 
> 
> Too long; didn't read
> =
> 
> We add a new box to Bugzilla to hold atoms on stabilisation request bugs
> so it's easy to extract programmatically.
> 
> We add a new box to Bugzilla to indicate if a stabilisation request
> requires runtime testing or not to better focus effort.
> 
> If your stabilisation request is invalid a bot will let you know and it
> will be easy to skip your request until you fix it.
> 
> 
> This will also help pave the way for future enhancements such as
> triggering automated build and QA tests so that the human only has to do
> runtime testing.
> 
> Thoughts?

Everything here sounds pretty good to me!

I just realized there is another rare issue that we may have to take
into account. Some sets of packages *must* be stablized in lockstep. For
regular sets of packages like eg xfce if you leave off a bunch of the
extras its no big deal.
Eg for SELinux, the policy packages must all be stabilized all at
once because they depend on each other (I think perl is like this too?).

We would need a way for maintainers to ask for testing without actually
committing. The maintainer can wait till everything is done and commit
everything at once himself. Some flag to make the tatt script skip the
step would be enough I think.

-- Jason

Re: [gentoo-dev] Improving the stabilisation process - part 1

[Jason Zaman]

On Fri, Nov 25, 2016 at 05:54:41PM +1300, Kent Fredric wrote:
> On Fri, 25 Nov 2016 06:41:20 +1100
> Michael Palimaka  wrote:
> 
> > Example atom list from a bug with amd64, arm, and x86 in CC:
> > 
> > =app-foo/bar-1.2.3   # will be stabilised on amd64, arm, and x86
> > =app-foo/baz-2.3.4 amd64 x86 # will be stabilised on only amd64 and x86
> 
> I was doing this in the past, but there's a reason I stopped:
> 
> Bugzilla-enforced wordwrap ( at least, this is very strict on the 
> bugzilla-email relay )
> 
> > =app-foo/bar-1.2.3   # will be stabilised on amd64, arm, and x86
> 
> Could become more like 
> 
> > =app-foo/bar-1.2.3   # will be stabilised on amd64, 
> > arm, and x86

One way would be to use a plain text attachment with a standardized
filename. If there are updates to the list then the new should obsolete
the old and the script can pull non-obsoleted ones.
The problem then is how do you search for them properly? put them all
in the title anyway? then its duplicated.

When i do big lists of packages the title is eg "XFCE Stabilization for
Nov 2016" which is not duplicated and okay.
For single packages the title is just "cat/pkg-1.2.3 stablereq" so then
we duplicate anyway?

-- Jason

> A literal example of an email I received for a bug I filed ( via an alias ) 
> is attached.
> 
> The example I give did not render poorly on bugzilla
> ( https://bugs.gentoo.org/show_bug.cgi?id=599550 ), but I suspect people
> who do AT probably prefer their notification emails about needed AT not
> to be useless.
> 

Re: [gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in

[Jason Zaman]

On Wed, Oct 05, 2016 at 03:58:44PM +, Joakim Tjernlund wrote:
> On Wed, 2016-10-05 at 23:10 +0800, Jason Zaman wrote:
> > On Wed, Oct 05, 2016 at 02:58:20PM +, Joakim Tjernlund wrote:
> > > 
> > > I know this might be a bit off topic but I just want some clues
> > > 
> > > Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to 
> > > "(null)". This
> > > creates a /(null) dir. with various stuff in it.
> > > 
> > > I am trying to find out what sets XDG_RUNTIME_DIR?
> > its https://bugs.gentoo.org/585688
> > fixed in sys-auth/consolekit-1.1.0-r1
> > 
> > I'd forgotten to update the stablereq to that, will do it now.
> 
> Ah, I see that now.
> Thou after installing sys-auth/consolekit-1.1.0-r1 I get XDG_RUNTIME_DIR
> but no the directory is not created for root, seems to be fixed by:
> https://github.com/ConsoleKit2/ConsoleKit2/commit/664d2fdbd966764836b1f4da2dbc5750c7f01f0f

Yep, that patch is what the -r1 bump was for. Did you remember to
restart consolekit after updating?

Re: [gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in

[Jason Zaman]

On Wed, Oct 05, 2016 at 02:58:20PM +, Joakim Tjernlund wrote:
> I know this might be a bit off topic but I just want some clues
> 
> Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to 
> "(null)". This
> creates a /(null) dir. with various stuff in it.
> 
> I am trying to find out what sets XDG_RUNTIME_DIR?
its https://bugs.gentoo.org/585688
fixed in sys-auth/consolekit-1.1.0-r1

I'd forgotten to update the stablereq to that, will do it now.

-- Jason

> 
> We auth. against Windows AD using sssd, but root is a local UNIX user 
> only(not in AD)
> 
> Any clues?
> 
>   Jocke 

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Jason Zaman]

On Sun, Aug 28, 2016 at 11:15:40PM -0400, Mike Gilbert wrote:
> On Sun, Aug 28, 2016 at 3:57 PM, Kristian Fiskerstrand  
> wrote:
> > On 08/28/2016 07:28 PM, Paweł Hajdan, Jr. wrote:
> >> B. Backport just the changes needed for chromium to older ffmpeg
> >
> > Any chance of it being included upstream or would it be a downstream
> > carry for a long time?
> 
> I haven't looked at any code, but given that it's a major version bump
> of a library, the changes probably involve API-breaks. Backporting
> them upstream or downstream is probably not a simple matter, and
> probably a bad idea.

Please don't backport or patch. That sounds like a potential disaster
waiting to happen. The tracker bug for ffmpeg 3.0 has been open for
quite a while and is taking time. Backporting just parts of it has the
potential to break both stable and unstable and the time would be better
used working on stabilizing 3.0.

> >> C. Mask chromium's system-ffmpeg flag when the dependency on
> >> ffmpeg-3.0.1 can't be satisfied
> >
> > Would this result in using bundled libraries instead?
> 
> Yes, masking the system-ffmpeg USE flag would cause the bundled ffmpeg
> code to be used.
> 
> The Chromium project applies security fixes quite regularly, so don't
> get too worried over it.

Masking it is fine. Its suboptimal but it has much less breakage-
potential. If 3.0 is not stable in time then just mask it.

Also, is this ffmpeg or libav? or are they the same for 3.x?

-- Jason

Re: [gentoo-dev] newsitem: openrc runscript transition (draft 3)

[Jason Zaman]

On Wed, Aug 24, 2016 at 07:32:05PM +1200, Kent Fredric wrote:
> On Mon, 22 Aug 2016 17:57:43 -0500
> William Hubbs  wrote:
> 
> > I thought about dropping the version number from the
> > display-if-installed line, but that doesn't make sense because it means
> > that everyone, including all new installs of OpenRC after this version,
> > would have to read the newsitem.
> > 
> > William
> > 
> 
> That concern is in the wrong priority.
> 
> "Your system might break" is more important than "ugh, annoying news items"
> 
> Viewing the news item once per clean install is still less of a "Problem" 
> than 
I remember some time back there was talk about marking some news items
as read in new stage3's. That basically removes this annoyance
completely. I don't know how that ended up tho, maybe we should re-visit
it?

-- Jason

Re: [gentoo-dev] base-system needs developers who care

[Jason Zaman]

On Tue, Aug 23, 2016 at 11:17:58PM +, Robin H. Johnson wrote:
> Over the years, the base-system package herd has grown in size. Today
> it comprises 320 packages, of which 61 of those have more than one
> maintainer. The packages with more than one maintainer I'm only
> concerned about if the other maintainer is also very busy or not
> available.
> 
> Some of these packages are very niche, and while they continue to work,
> they could use a bit more attention than they get presently (you might
> only hear about them when they break and never when they work). 
> 
> They are generally NOT broken and in need of tree-cleaning, but are just
> lacking forward momentum (not a few bugs are reasonable upstream bugs or
> feature improvements). Many were once shiny and had lots of people that
> cared, but that dwindled as they become mundane and just expected to
> work.
> 
> General increase in the number of developers in base-system would not be
> a bad outcome from this email either ;-).
> 
> Some of this is from stuff I know needs eyeballs, and others are where
> the package seems to have more than a few old bugs open.

I'll join too. I use a fair few of them and there is SELinux integration
in most of the core packages so at the very least i'll help there.

-- Jason
> 
> Packages in need of review & tweaks or just more eyeballs
> --
> app-admin/sudo (upstream?)
> app-admin/sysklogd- (upstream?)
> app-shells/bash (upstream?)
> dev-util/strace (upstream?)
> net-dialup/ppp
> net-firewall/iptables
> net-fs/nfs-utils (upstream?)
> net-misc/dhcpcd (upstream?)
> net-misc/dhcp (upstream?)
> net-misc/ntp (upstream?)
> net-misc/openssh 
> net-nds/rpcbind
> sys-apps/baselayout
> sys-apps/coreutils (upstream?)
> sys-apps/kbd (upstream?)
> sys-block/aoetools
> sys-block/iscsitarget
> sys-block/open-iscsi
> sys-block/thin-provisioning-tools
> sys-block/vblade
> sys-fs/lvm2 (mostly in regards to genkernel interaction)
> sys-fs/multipath-tools
> sys-fs/quota
> 
> -- 
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
> E-Mail   : robb...@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Re: [gentoo-dev] Sparc Arch status

[Jason Zaman]

On Mon, Aug 15, 2016 at 07:54:21PM -0700, Jack Morgan wrote:
> > (b) gnome/kde desktop support
> > I'd like to propose dropping support for gnome/kde desktop if systemd
> > isn't supported on sparc. I'm note sure it makes sense long term nor
> > have developer resources to continue to keyword it. I have a couple of
> > desktop systems so can test easily but running xfce4 atm. I'm open to
> > others opinions.
> 
> I'm going to drop support for all desktops except xfce4. If someone else
> wants to help out and support another desktop, they are free to join the
> team and do so.

I'm the one in the Xfce team that usually handles the stabilization so
let me know if there are any issues or you want help with something.
The next release (4.13 or 4.14) of Xfce stuff is going to be fully
migrated to gtk3. The current stuff needs both gtk2 and 3. If you want
you can hold off a while and then do only gtk3 so you dont have to do
gtk2.

sparc also needs ConsoleKit2 keyworded and stabilized together with xfce
when you get around to it.

-- Jason

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Jason Zaman]

On Mon, Aug 15, 2016 at 03:53:26PM +1200, Kent Fredric wrote:
> On Mon, 15 Aug 2016 11:45:22 +0800
> Jason Zaman <perfin...@gentoo.org> wrote:
> 
> > IN_PROGRESS == we've put the fix in the git repo
> > RESO/TESTREQ == new release and in ~arch
> 
> TESTREQ was incidentally my first thought. Only needs me to study how much 
> that's already used
> and whether or not existing bugs with that flag meet that description or not.
> 
> 
> However, a distinction between IN_PROGRESS and RESO/TESTREQ is not possible 
> here,
> because "in git" means "You'll get it if you sync >1h from now"

Oh, I meant this is for our policy stuff. which is in
hardened-refpolicy.git and then every few weeks we make a release and
bump all the packages in sec-policy/selinux-*. For things that do not
need an actual release we just skip INPROG and go straight to TESTREQ
when we fix the ebuild in the tree.

The important part to me is that RESO/FIXED should only mean fixed when
the problem is fixed in the stable tree too. There has to be another
state before FIXED that is for ~arch. If the package is not stable on
any arch then of course it is FIXED as soon as ~arch is fixed.

> IN_PROGRESS can thus only mean something about it being worked on but not yet 
> pushed
> to the main git repo. (ie: overlays, private repos)
> 
> But I would rather it part of the primary resolution path, not a mere 
> property of the resolution type.
> 
> Because its easier to say:
> 
> UNCONFIRMED -> CONFIRMED -> INPROGRESS -> INVCS -> STABLE
> 
> Than
> 
> UNCONFIRMED -> CONFIRMED -> INPROGRESS -> (RESOLVED/TESTREQ) -> 
> (RESOLVED/FIXED)

They are roughly equivalent, yeah. But I prefer TESTREQ because its
easier to see in the bug list page. You can of course choose which items
are shown in the list in bugzilla but resolution is already there so no
need to add an extra column.

-- Jason

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Jason Zaman]

On Sun, Aug 14, 2016 at 11:35:58PM +0200, Kristian Fiskerstrand wrote:
> During the latest Council meeting it was determined to set up a new
> Working Group to come up with recommendations for improving the state of
> the stable tree at a later Council meeting.

Sign me up!
> 
> Some initial items it was suggested the WG look into is
>  * The b.g.o workflow, bugs should not be considered fixed until the
>fix has reached the stable tree. Today the InVCS keyword exists for
>this purpose, but it is used to varying degree amongst developers.
>Will a workflow change to introduce a new status, e.g RESOLVED
>NeedsStable (name for illustration purpose only) incentivize
>developers to not close bugs before it is fixed?

In selinux we do:
UNCONFIRMED/CONFIRMED == not fixed yet
IN_PROGRESS == we've put the fix in the git repo
RESO/TESTREQ == new release and in ~arch
RESO/FIXED == the fix is stable now

Both Swift and I use stable so having things stabilized is important and
we dont close bugs till they are actually stable lest we forget later.
Our saved search for selinux bugs lists all bugs that are not RESO/FIXED
or VERIFIED, so RESO/TESTREQ still shows up.

-- Jason

>  * Are there ways to reduce the stabilization lag of packages
>  - looking into the effectiveness of ALLARCHES and its use
>  - possibility for maintainer to stabilize packages themselves for
>architectures they have access to (including whether there might
>be a need for changes to gentoo infrastructure to facilitate
>this)
>  - Tinderboxing / Automatic tools build test packages and reverse
>dependencies in order to assist in stabilization
Toralf runs one. Zorry is working on an auto tinderbox too.

-- Jason

> Other suggestions are up to the WG to come up with and write up a final
> report to the council with the summary of these discussions.
> 
> I've volunteered to chair such as working group. If you want to
> participate in it please respond to this thread. Additionally I've set
> up #gentoo-wg-stable as a place of coordination.
> 
> -- 
> Kristian Fiskerstrand
> OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 

Re: [gentoo-dev] Empty project: Desktop

[Jason Zaman]

On Sun, Aug 07, 2016 at 04:37:23PM +0200, Pacho Ramos wrote:
> El dom, 07-08-2016 a las 09:07 -0400, NP-Hardass escribió:
> > [...]
> > Well, that's easily remedied with an alias for the project that
> > contains
> > all the subprojects, no?
> > 
> 
> But I don't know if the projects will like to behave in that way...
> because freedesktop-bugs was behaving exactly in that way and, during
> the transition, it was agreed to stop using that and simply CC the
> right projects when needed :/
> 
> From my point of view we should simply kill that "Desktop" project as
> it serves no purpose and CC the relevant projects when needed, as I
> don't recall many cases of the old freedesktop-bugs behaving in the way
> you are suggesting (involving *all* desktop related projects in the bug
> reports). On the other hand it was ending up with most people under the
> subprojects simply ignoring the bug reports assigned to freedesktop-
> bugs

Removing it is fine. I'm in the freedesktop and Xfce projects and I had
no idea this Desktop project even existed.
Pretty sure everyone would just ignore anything from/to it anyway.
Problems with eg KDE and Xfce are mostly not really related. And the few
things that are related are more core components that are under
freedesktop (polkit/consolekit etc). In which case, that component is
fixed without needing to bother every single other project or we just CC
them all if need be.

-- Jason

Re: [gentoo-dev] Call for help: python3.5 testing

[Jason Zaman]

On Sun, Aug 07, 2016 at 03:46:40PM -0500, R0b0t1 wrote:
> On Sun, Aug 7, 2016 at 12:27 PM, Mike Gilbert  wrote:
> > Hi all,
> >
> > I would like to make a push to get python3.5 stable in the next few
> > months. There are a couple things that need to happen first.
> >
> > 1. Add python3_5 to PYTHON_COMPAT for current ~arch packages. A list
> > of packages that need to be tested and marked compatible with
> > python3.5 is producted daily.
> >
> > https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
> >
> > 2. Stabilize any packages necessary to support python3.5. A list is
> > also produced daily. For this step, I imagine we will create one giant
> > stablereq bug for the sake of arch testing efficiency, but feel free
> > to stabilize them ahead of that.
> >
> > https://qa-reports.gentoo.org/output/gpyutils/34-to-35-stablereq.txt
> >
> > If you have some time, please do some testing on packages from the
> > first list. For packages that have a working test phase, don't
> > necessarily expect all tests to pass; just look for regressions from
> > python3.4. For packages that have no test phase, a compile and basic
> > import test (python3.5 -c "import foo") is generally the best we can
> > do.
> >
> 
> I have been using in VMs since near it came out. Main incompatibility
> is with SELinux markings.

I just sent a whole bunch of patches upstream to fix all the outstanding
issues for selinux on python3. If you want to help test, that'd be
awesome. ping me on IRC and i'll give you the stuff.

-- Jason

Re: [gentoo-dev] Packages up for grabs

[Jason Zaman]

On Sun, Aug 07, 2016 at 10:24:08AM +0200, Pacho Ramos wrote:
> This packages are now up for grabs:
> sys-block/zram-init
I'll take this, i use it on my laptops

-- Jason

Re: Easy Installs / Stage 4 ( Was: Re: [gentoo-dev] Re: Packages up for grabs )

[Jason Zaman]

On Sun, Aug 07, 2016 at 02:57:14PM -0500, james wrote:

You should take a look at Blueness' Gentoo Reference stuff
https://wiki.gentoo.org/wiki/Project:RelEng_GRS
https://blogs.gentoo.org/blueness/2015/07/31/the-gentoo-reference-system-suite-a-new-release-engineering-tool/

Re: [gentoo-dev] Package up for grab

[Jason Zaman]

On Tue, Aug 02, 2016 at 04:08:34PM -0700, Jigme Datse Rasku wrote:
> I'd have to say, there is likely a reason we are looking for a new
> maintainer.  I don't know what is involved, but I might be interested.
> Might be wanting to start that direction...

There is a new alpha skype for linux too now that should be looked into.
I have no idea how stable it is but it's probably not much worse than
what we currently have :P.

https://community.skype.com/t5/Linux/Skype-for-Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/td-p/4434299

-- Jason

> On Aug 2, 2016 16:03, "M. J. Everitt"  wrote:
> 
> > On 02/08/16 23:43, Matthew Thode wrote:
> > > On 08/02/2016 04:15 PM, Amy Winston wrote:
> > >> net-im/skype
> > >>
> > >> Anyone interested?
> > >>
> > >>
> > > I feel like this is a trick question :P
> > >
> > +2
> >
> >

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Jason Zaman]

On Sun, Jul 24, 2016 at 10:17:24AM +0200, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
> > So, to summarize we shouldn't fix existing code because people did
> > assume accepting invalid parameters was fine.
> 
> You are changing the API of versionator.eclass, even if it was unintentional 
> API.

# @FUNCTION: version_is_at_least
# @USAGE:  [have]
# @DESCRIPTION:
# Is $2 (defaults to $PVR) at least version $1? Intended for use in eclasses
# only. May not be reliable, be sure to do very careful testing before actually
# using this.

The API seems pretty clear to me ...

-- Jason

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Jason Zaman]

On Thu, Jun 16, 2016 at 03:32:03PM +0200, Michał Górny wrote:
> On Thu, 16 Jun 2016 16:18:20 +0300
> Andrew Savchenko  wrote:
> 
> > On Thu, 16 Jun 2016 14:04:19 +0200 Michał Górny wrote:
> > > On Wed, 15 Jun 2016 21:11:30 +0200
> > > Michał Górny  wrote:
> > >   
> > > > Right now we have the following components:
> > > > 
> > > > - Applications,
> > > > - baselayout,
> > > > - Core system,
> > > > - Development,
> > > > - Eclasses and Profiles,
> > > > - Games,
> > > > - GCC Porting,
> > > > - GNOME,
> > > > - Hardened,
> > > > - Java,
> > > > - KDE,
> > > > - Keywording & Stabilization,
> > > > - Library,
> > > > - New packages ('New ebuilds' previously),
> > > > - Printing,
> > > > - SELinux,
> > > > - Server,
> > > > - Unspecified.  
> > > 
> > > Revision two:
> > > 
> > > - Current packages [bug-wranglers@],
> > > - Eclasses [bug-wranglers@],
> > > - Hardened [hardened@],
> > > - New packages [bug-wranglers@],
> > > - Overlays [overlays@],
> > > - Profiles [bug-wranglers@],
> > > - SELinux [selinux@].  
> > 
> > Why hardened and selinux are separate?
> 
> It's in the rationale, below. It may make sense to stage bugs through
> Hardened/SELinux teams since not all developers have access to
> Hardened/SELinux systems. If that's not needed, I'm happy to drop them.

Yes, on behalf of both Hardened and SELinux, please keep those
components.

The bugs can be a problem with the hardening or SELinux policy in which
case we just fix it without bothering the maintainer who probably doesnt
even have an selinux system to test the changes. Sometimes there is an
actual bug in the package in which case we can easily involve the
maintainer or assign to them completely.

-- Jason

Re: [gentoo-dev] [RFC] New eclass: mate

[Jason Zaman]

On Fri, Jun 10, 2016 at 12:52:34PM -0400, NP-Hardass wrote:
> On 06/09/2016 11:54 PM, Jason Zaman wrote:
> > On Thu, Jun 09, 2016 at 08:19:43AM -0400, NP-Hardass wrote:
> >> # @FUNCTION: python_cond_func_wrap
> >> # @DESCRIPTION: Wraps a function for conditional python use, to run for 
> >> each
> >> # python implementation in the build directory.
> >> python_cond_func_wrap() {
> >>if use python; then
> >>python_foreach_impl run_in_build_dir "$@"
> >>else
> >>$@
> >>fi
> >> }
> > 
> > I dont see where you inherited the python eclasses? You also probably
> > need to use use_if_iuse (from eutils.eclass) instead since it seems like
> > python might not be in all the ebuilds. Afaik, you're not allowed to
> > call use foo if foo is not in IUSE already
> I forgot to include a comment in the ebuild, but the intention was that
> the eclass would not inherit python, by design, those wanting to use
> that should inherit python themselves.  Although, if I should check that
> explicitly, I am unaware of how to do so, and would appreciate advice
> from someone, if it is possible. I am aware of INHERITED, but the PMS
> says it shouldn't be exported to ebuilds, so I'm unsure if/how it could
> be used.
> 
> My hope was that since this is used several times (though, not too
> many), that I could move this logic into the eclass, but if it would be
> more appropriate to just keep that in each of those ebuilds, I can do
> that too.

Yeah sounds like keeping this in the eclass is right. Moving duplicated
code into the ebuilds would be a waste. You are defining the API so
requiring the ebuild to inherit itself is completely okay. I would add a
little more to the doc above to make it super obvious tho.

I don't know how to check if the python eclasses specifically are
inherited. I think "python" being in IUSE would be sufficient to check
tho. so all you'd need to do is inherit eutils and replace the "if use
python" with "if use_if_iuse python".

If you *really* wanted to check you could perhaps do
if [[ $(type python_foreach_impl) == function ]]. Seems overkill and I
wouldn't bother. Having python in iuse is probably enough of a sanity
check.

-- Jason

Re: [gentoo-dev] [RFC] New eclass: mate

[Jason Zaman]

On Thu, Jun 09, 2016 at 08:19:43AM -0400, NP-Hardass wrote:
> # Old EAPIs are banned.
> case "${EAPI:-0}" in
>   5|6) ;;
>   *) die "EAPI=${EAPI} is not supported" ;;
> esac

How reasonable would it be to ban EAPI5 as well? This is a new eclass so
it may be better to just take the time to go to EAPI6 directly and not
have to migrate 5->6 later on.


> # @FUNCTION: python_cond_func_wrap
> # @DESCRIPTION: Wraps a function for conditional python use, to run for each
> # python implementation in the build directory.
> python_cond_func_wrap() {
>   if use python; then
>   python_foreach_impl run_in_build_dir "$@"
>   else
>   $@
>   fi
> }

I dont see where you inherited the python eclasses? You also probably
need to use use_if_iuse (from eutils.eclass) instead since it seems like
python might not be in all the ebuilds. Afaik, you're not allowed to
call use foo if foo is not in IUSE already.

Also I'm not sure if having functions start with python_ could lead to
conflicts later on with the python eclasses?

Other than these minor things, look good!
-- Jason

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/

[Jason Zaman]

On Wed, Feb 10, 2016 at 05:11:20AM +, Robin H. Johnson wrote:
> On Wed, Feb 10, 2016 at 01:24:16AM +, Robin H. Johnson wrote:
> > I will happily take a pre-receive hook, regardless of it using
> > pkgcore/portage. Note that it should operate WITHOUT having a checkout,
> > needs to be able to take new ebuilds & Manifest on stdin.
> > 
> > Trying to checkout the tree for each update I don't think is a good
> > idea, as it's 5+ seconds of overhead; and somebody else could try to
> > push a change in the meantime.
> Slight clarification here:
> I am willing to keep a stateful checkout as a post-receive hook, and the
> pre-receive hook CAN use that checkout to read other contents. It just
> might be more than one commit behind sometimes.
> 
> Eg:
> T=1 push P1 comes in, triggers pre-receive, passes, triggers post-receive 
> hook (async)
> T=1..5 working tree in the process of post-receive, state is dirty [1]
> T=2 push P2 comes in, triggers pre-receive. What should happen?
> 
> What should the pre-receive do in this case?
> A) fail outright? (terrible choice, included for completeness)
> B) block on the active post-receive completing? (while !done; sleep)
> C) validate against a changing tree? (might fail, not in a way that's
> easy to reproduce)
> D) validate against a previous CLEAN tree? (if this push depends on a
> change in push P1, it will fail when it should have passed)
> 
> [1] actually a really good question here, does git prepare changes
> somewhere in .git and atomically rename into place, even so, multiple
> moves cannot be atomic together.
> 
> -- 
> Robin Hugh Johnson
> Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
> E-Mail : robb...@gentoo.org
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> 

We do not need the whole manifest checking, we just need to have a list
of SRC_URI that is being added in any ebuilds and then grep Manifest if
those filenames exist. The receive hook checking the hashes of the files
is probably asking too much. This would miss any files added by eclasses
but that is rare and changes less often so we should probably be okay.

Is there any sane way to spit out condensed SRC_URI for all use-flags?

-- Jason

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Jason Zaman]

On Thu, Feb 04, 2016 at 11:03:27AM +0100, Dirkjan Ochtman wrote:
> On Wed, Feb 3, 2016 at 11:48 PM, Michał Górny  wrote:
> > Could we please finally stop introducing global USE flags that are
> > going to only be used by a single package? make.conf already looks like
> > random mix of randoms these days, with some extra random cruft being
> > added every second Tuesday.
> 
> This is an interesting point, which I hadn't thought much about.
> 
> It seems USE_EXPAND is really popular. What does it bring that has all
> these advantages over normal USE flags? It seems like APACHE2_MPMS,
> APACHE2_MODULES and CURL_SSL could just be normal USE flags with some
> REQUIRED_USE stuff.
> 
> Actually, I'm not really sure I understand why we can't use normal USE
> flags for CPU_FLAGS_X86 or PYTHON_TARGETS, either.

Which looks easier and nicer to you?

NGINX_MODULES_HTTP="access auth_basic autoindex browser charset
fancyindex fastcgi geo gzip limit_req limit_zone map memcached proxy
realip referer rewrite scgi spdy split_clients ssi upstream_check
upstream_ip_hash userid uwsgi"

or:

www-servers/nginx nginx_modules_http_access nginx_modules_http_auth_basic 
nginx_modules_http_autoindex nginx_modules_http_browser 
nginx_modules_http_charset nginx_modules_http_fancyindex 
nginx_modules_http_fastcgi nginx_modules_http_geo nginx_modules_http_gzip 
nginx_modules_http_limit_req nginx_modules_http_limit_zone 
nginx_modules_http_map nginx_modules_http_memcached nginx_modules_http_proxy 
nginx_modules_http_realip nginx_modules_http_referer nginx_modules_http_rewrite 
nginx_modules_http_scgi nginx_modules_http_spdy 
nginx_modules_http_split_clients nginx_modules_http_ssi 
nginx_modules_http_upstream_check nginx_modules_http_upstream_ip_hash 
nginx_modules_http_userid nginx_modules_http_uwsgi

What is the problem with global flags? Its namespaced and never going to
interfere with other packages. The only difference is the descriptions
are in use.desc instead of use.local.desc, why does that matter?

-- Jason

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Jason Zaman]

On Thu, Feb 04, 2016 at 04:35:44PM -0600, Gordon Pettey wrote:
> On Thu, Feb 4, 2016 at 6:17 AM, Kent Fredric <[1]kentfred...@gmail.com>
> wrote:
[ ... ]
>> Its really sad we can't just have what Paludis does, package.use
>> side
>> support for USE_EXPAND.
>> www-servers/nginx  normal_use_flags NGINX_MODULES: http_access
>> http_auth_basic http_autoindex
>> Or similar.
>
> But we can do exactly that, as of at least portage-2.2.24, possibly
> earlier.

Whoa that I was unaware of. This is amazing and makes USE_EXPAND much
less important to me :D

-- Jason

Re: [gentoo-dev] New packages up for grabs

[Jason Zaman]

On Mon, Jan 25, 2016 at 12:32:06AM +0100, Michał Górny wrote:
> net-libs/libtorrent
> net-p2p/rtorrent

I'll take these

-- Jason

Re: [gentoo-dev] packages to grab

[Jason Zaman]

On Sun, Jan 10, 2016 at 08:28:16AM +0100, Justin Lecher (jlec) wrote:
> On 09/01/16 22:07, Julian Simioni wrote:
> > I'd love to proxy-maintain app-admin/pwgegn: it's used by
> > app-admin/pass which I use quite a bit.
> 
> Hi Julian,
> 
> do you need a proxy or do you have someone to work with?

I can proxy, I was thinking about taking it but I only use it a little,
so a proxy would be better.

Julian,
I'll add you as proxy to the metadata and myself as second then.

-- Jason

Re: [gentoo-dev] packages to grab

[Jason Zaman]

On Thu, Jan 07, 2016 at 02:50:14PM +0100, Justin Lecher (jlec) wrote:
> Dear everyone,
> 
> due to changes in real life I need to cut back vastly my day to day
> maintainer work starting in February. So far I have no clue how much
> time I can devote to Gentoo in nearer future.

Sad to hear, you were my recruiter and helped me become a dev :D. Good
luck with real life.

I took sys-fs/cachefilesd since I use it on my laptop.

-- Jason

Re: [gentoo-dev] RFD: Replacement for versionator.eclass in PMS (for EAPI 7?)

[Jason Zaman]

On Sat, Nov 28, 2015 at 10:14:39PM +0100, Ulrich Mueller wrote:
> Questions:
> 1. Will these three functions be sufficient, or have we overlooked
>anything important?

Can we also have get_version_component_count() in there?

I have a package that likes to change the number of parts so I need to
know how many parts before I can split it up.

Basically this:
if [[ $(get_version_component_count) -eq 6 ]]; then
STUDIO_V=$(get_version_component_range 1-4)
BUILD_V=$(get_version_component_range 5-6)
else
STUDIO_V=$(get_version_component_range 1-3)
BUILD_V=$(get_version_component_range 4-5)
fi

-- Jason

Re: [gentoo-dev] RFC: ban cmake-utils_use_* in EAPI 6

[Jason Zaman]

On Wed, Nov 18, 2015 at 09:53:17PM +1100, Michael Palimaka wrote:
>   $(cmake-utils_use_with foo LibFoo)
>   -DWITH_LibFoo=$(usex foo)
> 
> What do you think?

Do it! I have no idea what the cmake one is supposed to do without
reading docs. The usex one is really obvious.

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

[Jason Zaman]

On Thu, Nov 12, 2015 at 11:46:19AM +0100, Alexis Ballier wrote:
> On Wed, 11 Nov 2015 23:11:48 +
> "Robin H. Johnson"  wrote:
> 
> > On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote:
> > > It's not perfectly clean but I don't see any problem here:
> > > ChangeLog-2015 : all ChangeLog from CVS
> > > ChangeLog: autogenerated from git  
> > FYI, this was implemented.
> 
> 
> Thanks!
> 
> How should one report bugs ? to infra or portage ?
> From my just rsynced tree, I see changelogs in reverse order: oldest
> come first, latest come last

NOTABUG, it was changed because rsync can deal really well with
appending to the end of files. rsyncing a file where things were things
were added to the beginning of the file means rsync will copy the whole
file from scratch which is pretty sub-optimal.

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Jason Zaman]

On Thu, Oct 15, 2015 at 10:57:45AM +0200, Tobias Klausmann wrote:
> Hi! 
> 
> On Wed, 14 Oct 2015, Mike Frysinger wrote:
> > anyone opposed to flipping this flag on by default ?
> > 
> > reference:
> > https://bugs.gentoo.org/506198
> > https://bugs.gentoo.org/556408
> 
> No objection, but a bit of a datapoint. I use btrfs on one of my
> machines, and that filesystem (apparently) does not support
> XATTR_PAX markings. So on every update I get some packages with
> message like these:

I used to run hardened on btrfs and it worked fine. pax xattrs are in
the user namespace (user.pax.flags) which isnt protected (unlike eg.
security.*). I dont remember doing anything special to enable xattrs on
btrfs, most of the newer FSs have them enabled by default.

Can you try this:

# getfattr -d -m- /bin/ping
security.capability=0sAQAAAgAgAAA=
# setfattr -n user.test -v "foo" ./ping
# setfattr -n user.pax.flags -v "me" ./ping
# getfattr -d -m- /bin/ping
security.capability=0sAQAAAgAgAAA=
user.pax.flags="me"
user.test="foo"

If this works then something else is causing those messages and we
should look into it further.

> 
> >>> Messages generated for package app-emulation/qemu-2.4.0.1 by process 2675 
> >>> on 20151013-150646 CEST:
> 
> LOG: install
> Failed to set XATTR_PAX markings -me qemu-system-aarch64.
> Failed to set XATTR_PAX markings -me qemu-system-alpha.
> Failed to set XATTR_PAX markings -me qemu-system-i386.
> Failed to set XATTR_PAX markings -me qemu-system-x86_64.
> Failed to set XATTR_PAX markings -me qemu-aarch64.
> Failed to set XATTR_PAX markings -me qemu-alpha.
> Failed to set XATTR_PAX markings -me qemu-i386.
> Failed to set XATTR_PAX markings -me qemu-x86_64.
> 
> Two things about this: the message is not really useful, unless I
> know what -me does. Also, I never requested anything PaX-ish, I
> just don't want to to have SUID binaries when I can avoid it.

Not that it matters since you dont run hardened, but "m" means "disable
mprotext" and "e" means "disable trampoline emulation".

-- Jason
> 
> By now the messages are just an annoyance/spam to me, but I
> suspect this may be more of a problem for people who have lower
> pain thresholds.
> 
> Regards,
> Tobias
> 
> -- 
> "Sendmail is the sort of tool that gave UNIX its bad reputation."
>-- _System Performance Tuning_
> 

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Jason Zaman]

On Thu, Oct 15, 2015 at 07:38:43AM -0400, Anthony G. Basile wrote:
> On 10/15/15 7:24 AM, Rich Freeman wrote:
> > On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman <perfin...@gentoo.org> wrote:
> >> Can you try this:
> >>
> >> # getfattr -d -m- /bin/ping
> >> security.capability=0sAQAAAgAgAAA=
> >> # setfattr -n user.test -v "foo" ./ping
> >> # setfattr -n user.pax.flags -v "me" ./ping
> >> # getfattr -d -m- /bin/ping
> >> security.capability=0sAQAAAgAgAAA=
> >> user.pax.flags="me"
> >> user.test="foo"
> >>
> >> If this works then something else is causing those messages and we
> >> should look into it further.
> > This behaves exactly as described above for me on btrfs, but I still
> > do get all the error messages whenever I install stuff.
> >
> > I assume the extra attributes are harmless and will get removed the
> > next time I update ping?
> >
> okay its good to know that that this does work.  something might be 
> misconfigured on tobias's box.
> 
> let me know any problems with XATTR_PAX markings because that's going to 
> become the default soon and in the near future the only option once we 
> drop the PT_PAX patch from binutils.

I seem to recall something about PaX enabling user.* xattrs on tmpfs and
mainline kernel supports only security.* on tmpfs. Could that be the
cause? If that is the case then what do we do about everyone that is
using gentoo-sources? It probably doesnt matter so just silencing the
errors is probably enough.

-- Jason
> 
> -- 
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail: bluen...@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
> 
> 

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Jason Zaman]

On Wed, Oct 14, 2015 at 11:48:07PM -0400, Mike Frysinger wrote:
> USE=xattr is needed nowadays to support:
> - filesystem caps (those things that let you drop set*id and generally
>   improves system security w/little to no runtime overhead)
> - PaX file markings (replaces binutils ELF markings)
> - selinux
> 
> we actually have USE=filecaps on by default already, and catalyst
> hard requires tar[xattr] in order to work.  the hardened profile
> also package.use.force's this flag on for some core packages.
> 
> not too many packages actually utilize this flag, and when they do,
> it's to pull in the attr package which clocks in at <200 KiB.  the
> runtime overhead tends to be low to non-existent as xattrs tend to
> be used only when requested.
> 
> when support is not available in the FS or kernel, packages should
> generally fall back gracefully.
> 
> anyone opposed to flipping this flag on by default ?
> 
> reference:
> https://bugs.gentoo.org/506198
> https://bugs.gentoo.org/556408
> -mike

As part of the hardened and SELinux teams, definitely +1 from me.

-- Jason

Re: [gentoo-dev] xf86-input-evdev patch problem

[Jason Zaman]

On Mon, Oct 12, 2015 at 06:56:27AM +0200, Cor Legemaat wrote:
> Hi:
>  
> I created a ebuild with a patch for xf86-input-evdev to try and 
> debounce my mouse button. The ebuild is at 
> https://github.com/cor-mt/portage-overlay/blob/master/x11-drivers/xf86-input-evdev/xf86-input-evdev-2.9.2-r1.ebuild
>  it compile and install fine but with it installed neither the 
> keyboard nor mouse is working. If I am correct it should install 100% 
> the same as from gentoo without the "debounce" use flag but it gives 
> the same symptoms.
>  
> What am I doing wrong?

So the problem here is the "inherit linux-info xorg-2" line.
The xorg-2 eclass defines few default phase functions which you have
overridden.

If you want to patch the source you should be doing something like this:
src_prepare() {
use debounce && epatch ${FILESDIR}/your-patch

xorg-2_src_prepare # this will call the xorg-2 eclass
#defined phase function to do the rest of the work
}

Alternatively, if you just want to apply that patch, you are probably
better off using epatch_user.
Drop your patch in
/etc/portage/patches/x11-drivers/xf86-input-evdev/your-name.patch
and the eclasses will automatically apply the patch. you do not have to
make your own ebuild just to apply the patch.

This has more info: https://wiki.gentoo.org/wiki//etc/portage/patches

-- Jason

Re: [gentoo-dev] rfc: multilib and fhs 3

[Jason Zaman]

On Sat, Oct 10, 2015 at 05:48:15PM -0500, William Hubbs wrote:
> All,
> 
> fhs 3.0 was approved in June this year [1] [2].
> 
> The piece of it that I want to bring up is the lib and libxx
> directories, both in / and /usr. The way I read the fhs, /lib and
> /usr/lib should hold the files for the default abi and /libxx and
> /usr/libxx should hold the files for the alternate abis. In earlier fhs,
> there was an exception for amd64 which stated that the default libraries
> should be in /lib64 and /usr/lib64. However, that exception is now gone.
> 
> I know there was discussion/work in the past on removing the lib->lib64
> symlinks on amd64, but I don't remember what happened to that
> discussion. So, I would like to bring it up again and get the info.
> 
> What would it take for us to remove the lib->lib64 links?
> 
> What would it take for us to do this migration on live systems?
> 
> William
> 
> [1] https://wiki.linuxfoundation.org/en/FHS
> [2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

Not sure we have to move it.

"3.10. /lib : Alternate format essential shared libraries (optional)
3.10.1. Purpose
There may be one or more variants of the /lib directory on systems which
support more than one binary format requiring separate libraries. [13]"

Note 13 is:
"[13] This is commonly used for 64-bit or 32-bit support on systems which
support multiple binary formats, but require libraries of the same name.
In this case, /lib32 and /lib64 might be the library directories, and
/lib a symlink to one of them."

Unless im misunderstanding, we are fine as is with lib32, lib64 and
lib->lib64

-- Jason

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-fs/zfs-kmod/

[Jason Zaman]

On Fri, Oct 09, 2015 at 06:20:58PM +0200, Michał Górny wrote:
> Dnia 2015-10-09, o godz. 15:40:32
> "Richard Yao"  napisał(a):
> 
> > commit: 050bf38afc93a98c5176c95b3c4ffc01212bf46b
> > Author: Richard Yao  gentoo  org>
> > AuthorDate: Fri Oct  9 15:38:56 2015 +
> > Commit: Richard Yao  gentoo  org>
> > CommitDate: Fri Oct  9 15:38:56 2015 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=050bf38a
> > 
> > sys-fs/zfs-kmod: Remove outdated ebuilds
> > 
> > Package-Manager: portage-2.2.20.1
> > Signed-off-by: Richard Yao  gentoo.org>
> > 
> >  sys-fs/zfs-kmod/zfs-kmod-0.6.2-r4.ebuild | 129 ---
> >  sys-fs/zfs-kmod/zfs-kmod-0.6.2-r5.ebuild | 129 ---
> >  sys-fs/zfs-kmod/zfs-kmod-0.6.3.ebuild| 138 
> > -
> >  sys-fs/zfs-kmod/zfs-kmod-0.6.4.ebuild| 142 
> > --
> >  sys-fs/zfs-kmod/zfs-kmod-0.6.5.2.ebuild  | 146 
> > ---
> 
> You removed 0.6.5.2 but kept the respective sys-fs/zfs version,
> therefore breaking the dependency graph:
> 
> https://qa-reports.gentoo.org/output/gentoo-ci/96dc8cd/12.html#l657
> 
I re-added this. Also forgot to remove the distfiles from the Manifest.

Re: [gentoo-dev] Make 'audit' a global useflag?

[Jason Zaman]

On Tue, Oct 06, 2015 at 08:58:48PM +0300, Andrew Savchenko wrote:
> Hi,
> 
> On Tue, 6 Oct 2015 17:32:07 +0100 Markos Chandras wrote:
> > Hi,
> > 
> > The following packages currently use the 'audit' local useflag
> > 
> > ~$ qgrep -N -s -l -e "^IUSE.*audit" | sed "s@-[0-9].*@@" | sort -n | uniq
> > 
> > app-emulation/libvirt
> > app-forensics/aide
> > dev-util/perf
> > gnome-base/gdm
> > net-dns/opendnssec
> > sys-apps/openrc
> > sys-apps/policycoreutils
> > sys-apps/shadow
> > sys-apps/systemd
> > sys-freebsd/freebsd-ubin
> > sys-freebsd/freebsd-usbin
> > sys-libs/pam
> > 
> > (+ lightdm which I just committed)
> > 
> > How about making it global with the following description?
> 
> Audit support != sys-process/audit support.
> 
> 1) sys-freebsd/us?bin packages does not depend on the audit
> package. This flag controls their own auditing tools.
> 
> 2) net-dns/opendnssec uses this flag to build auditing tools (and
> doesn't depend on the audit package).
> 
> 3) sys-apps/policycoreutils implies more than dependency on the
> audit package:
> Enable support for sys-process/audit and use the audit_*
> functions (like audit_getuid instead of getuid()) 

+1 for making it global. policycoreutils support is very much linked to
sys-process/audit. SELinux heavily relies on audit stuff. The
description is actually wrong, it uses audit_getloginuid() instead of
getuid(). I will fix it. OpenRC also uses that call (only effective when
selinux is enabled tho) so I will fix that description too.

But again, these are just local additions which do not in any way
conflict with the global one you are proposing.
> 
> > "Enable support for sys-process/audit"
> > 
> > which is similar to what most packages use?
> 
> Best regards,
> Andrew Savchenko

Re: [gentoo-dev] repoman and useless dependency.badmasked warnings

[Jason Zaman]

On Fri, Oct 02, 2015 at 10:49:48AM -0400, Mike Gilbert wrote:
> Hello,
> 
> I am getting the output below when I run repoman full for sys-apps/systemd.
> 
> It is basically telling me that systemd (which is masked in the
> selinux profiles) cannot depend on sys-apps/dbus[systemd], because the
> systemd use flag is also masked.
> 
> That's perfectly fine and I suppose it is valid, but there is nothing
> I can do to resolve it and I don't need to be reminded of it every
> time I run repoman.
> 
> Does anyone find dependency.badmasked useful? Can we remove it, or at
> least disable it by default?

I get exactly the same thing for dev-util/android-studio. It needs 32bit
stuff so it is masked in all the no-multilib profiles which obviously
makes sense. I dont get why repoman keeps annoying me about it, its
bad and its masked so whats the problem?

I have like a million lines of this:
  dependency.badmasked  12
   dev-util/android-studio/android-studio-1.2.0.12.141.1890965.ebuild: RDEPEND: 
amd64(hardened/linux/amd64/no-multilib)
[ '>=app-arch/bzip2-1.0.6-r4[abi_x86_32(-)]',
  '>=dev-libs/expat-2.1.0-r3[abi_x86_32(-)]',
  '>=dev-libs/libffi-3.0.13-r1[abi_x86_32(-)]',
  '>=media-libs/fontconfig-2.10.92[abi_x86_32(-)]',
  '>=media-libs/freetype-2.5.5[abi_x86_32(-)]',
  '>=media-libs/libpng-1.2.51[abi_x86_32(-)]',
  '>=media-libs/mesa-10.2.8[abi_x86_32(-)]',
  '>=sys-libs/ncurses-5.9-r3[abi_x86_32(-)]',

What I do not understand, I see these for hardened/../no-multilib, but I
do not see anything for default/.../no-multilib. Why? as far as I can
tell, they are masked in the same way so why isnt it complaining about
default?

jason@meriadoc ~/code/gentoo/gentoo/profiles $ grep -Rn dev-util/android-studio
arch/amd64/no-multilib/package.mask:32:dev-util/android-studio
hardened/linux/amd64/no-multilib/package.mask:49:dev-util/android-studio

-- Jason

Re: [gentoo-dev] repoman and useless dependency.badmasked warnings

[Jason Zaman]

On Fri, Oct 02, 2015 at 01:03:49PM -0700, Zac Medico wrote:
> On 10/02/2015 09:50 AM, Jason Zaman wrote:
> > What I do not understand, I see these for hardened/../no-multilib, but I
> > do not see anything for default/.../no-multilib. Why? as far as I can
> > tell, they are masked in the same way so why isnt it complaining about
> > default?
> 
> If you don't use 'repoman full', then the list is truncated to 12
> results, so that explains why you only got 12 results. The relevant code
> is here:
> 
> https://gitweb.gentoo.org/proj/portage.git/tree/pym/repoman/qa_data.py?h=v2.2.22#n434
> -- 
> Thanks,
> Zac

I always run repoman full. I think there just happen to be exactly the right 
number of ebuilds to make 12 errors.

jason@meriadoc ~/code/gentoo/gentoo/dev-util/android-studio $ repoman full

RepoMan scours the neighborhood...
  dependency.badmasked  12
   dev-util/android-studio/android-studio-1.2.0.12.141.1890965.ebuild: RDEPEND: 
amd64(hardened/linux/amd64/no-multilib)
[...snip...]
   dev-util/android-studio/android-studio-1.2.0.12.141.1890965.ebuild: RDEPEND: 
amd64(hardened/linux/amd64/no-multilib/selinux)
[...snip...]
   dev-util/android-studio/android-studio-1.2.2.0.141.1980579.ebuild: RDEPEND: 
amd64(hardened/linux/amd64/no-multilib)
[...snip...]
   dev-util/android-studio/android-studio-1.2.2.0.141.1980579.ebuild: RDEPEND: 
amd64(hardened/linux/amd64/no-multilib/selinux)
[...snip...]
   dev-util/android-studio/android-studio-1.3.0.10.141.2117773.ebuild: RDEPEND: 
~amd64(hardened/linux/amd64/no-multilib)
[...snip...]
   dev-util/android-studio/android-studio-1.3.0.10.141.2117773.ebuild: RDEPEND: 
~amd64(hardened/linux/amd64/no-multilib/selinux)
[...snip...]
   dev-util/android-studio/android-studio-1.3.1.0.141.2135290.ebuild: RDEPEND: 
~amd64(hardened/linux/amd64/no-multilib)
[...snip...]
   dev-util/android-studio/android-studio-1.3.1.0.141.2135290.ebuild: RDEPEND: 
~amd64(hardened/linux/amd64/no-multilib/selinux)
[...snip...]
   dev-util/android-studio/android-studio-1.3.2.0.141.2178183.ebuild: RDEPEND: 
~amd64(hardened/linux/amd64/no-multilib)
[...snip...]
   dev-util/android-studio/android-studio-1.3.2.0.141.2178183.ebuild: RDEPEND: 
~amd64(hardened/linux/amd64/no-multilib/selinux)
[...snip...]
   dev-util/android-studio/android-studio-1.4.0.10.141.2288178.ebuild: RDEPEND: 
~amd64(hardened/linux/amd64/no-multilib)
[...snip...]
   dev-util/android-studio/android-studio-1.4.0.10.141.2288178.ebuild: RDEPEND: 
~amd64(hardened/linux/amd64/no-multilib/selinux)
[...snip...]

Note: use --without-mask to check KEYWORDS on dependencies of masked packages
Note: use --include-dev (-d) to check dependencies for 'dev' profiles

RepoMan sez: "You're only giving me a partial QA payment?
  I'll take it this time, but I'm not happy."


It is not just android-studio tho, a ton of other 32bit programs are the same
way. android-sdk-update-manager does too and has 26 errors but they are all
only hardened for some reason even tho it also is masked in both default/ and
hardened/

jason@meriadoc ~/code/gentoo/gentoo/dev-util/android-sdk-update-manager $ 
repoman full
RepoMan scours the neighborhood...
  dependency.badmasked  26
   dev-util/android-sdk-update-manager/android-sdk-update-manager-21.ebuild: 
RDEPEND: ~amd64(hardened/linux/amd64/no-multilib)

-- Jason

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

[Jason Zaman]

On Fri, Oct 02, 2015 at 10:13:09PM -0400, Mike Frysinger wrote:
> Title: GCC 5 Defaults to the New C++11 ABI 
> Author: Mike Frysinger 
> Content-Type: text/plain
> Posted: 2015-10-02
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >=sys-devel/gcc-5
> 
> GCC 5 uses the new C++ ABI by default.  When building new code, you might run
> into link time errors like:
> ...: undefined reference to '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'

Exactly what part of this line is the important part? I take it its the
@GLIBCXX_3.4.17? or is it the lack of the __cxx11::? I have a feeling
that posted like this and users will think anytime it says undefined
reference then its a C++ issue which is likely not the case.

> Or you might see linkage failures with "std::__cxx11::string" in the output.
> 
> These are signs that you need to rebuild packages using the new C++ ABI.
> You can quickly do so by using revdep-rebuild like so:
> # revdep-rebuild --library 'libstdc\+\+\.so\.6'
> 
> For more details, feel free to peruse:
> https://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
> https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/


-- Jason

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Jason Zaman]

On Sat, Sep 12, 2015 at 09:12:25PM +0200, Michał Górny wrote:
> Potential solution: bi-dir github <=> bugzilla integration
> ==
> 
> My current idea would be pretty much that:
> 
> 1. a new dedicated Gentoo bug would be automatically created for every
> pull request on github,

Will this be only github PR's? will github issues be mirrored too? or
are the issues not supposed to be used on github at all?

Also, I think the new bugzie version allows multiple aliases on a bug,
so can we automomatically assign them github-pr-123 and github-issue-234
etc?

> What are your thoughts? Any other proposals?

Overall I like the idea. I think the quoting and other issues can be
fixed in an acceptable way.

-- Jason

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Jason Zaman]

On Sat, Sep 12, 2015 at 09:12:25PM +0200, Michał Górny wrote:
> Potential solution: bi-dir github <=> bugzilla integration
> ==

I just noticed this:

https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1308105
it appears to mirror the xfce bugtracker too.

Comment 31 in the launchpad link is the same as comment 1 in the xfce
bug. Is this kind of mirroring common other places? I have never noticed
it till now but was wondering if there is something pre-existing that we
can use.

-- Jason

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Jason Zaman]

On Wed, Sep 02, 2015 at 09:17:16PM +0200, Paweł Hajdan, Jr. wrote:
> On 8/30/15 12:02 PM, Kent Fredric wrote:
> > Or upstream might be a monolithic giant like Google where their
> > upstream bug tracking is some pointless forum where you get ignored by
> > the people actually working on things.
> 
> Ouch.
> 
> Do you have specific examples?
> 
> I'm not denying they exist. I just had mostly positive experience with
>  . Because I'm also Chromium
> developer, I know that's what people "actually working on things" use.
> 
> I admit with 85000+ open issues not all of them are getting enough
> attention. But if you know an upstream developer, it's easier to get the
> right people to look at the bug.
> 
> Of course above is not the only Google project, and I don't have much
> experience with the other ones.
> 
> Paweł

I dont know what ones he's talking about, but I have this one:

https://code.google.com/p/android/issues/detail?id=175284
https://bugs.gentoo.org/show_bug.cgi?id=533178

Android Studio is released as a compiled binary for windows/mac/linux
but there is no source code for it. And to make matters even worse they
don't have proper tags in the git repos for it so I can't even just make
the tarballs myself because I dont know which commits correspond to the
releases. They just closed the bug as declined with no reason given :(.

-- Jason

Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

[Jason Zaman]

On 15 Aug 2015 20:45, Peter Stuge pe...@stuge.se wrote:

 Hi and happy Git days! :)


 Robin H. Johnson wrote:
  It expands to the hash of the blob of that file; and from that, you can
  identify which commits the blob exists in.

 $ git ls-tree HEAD README
 100644 blob 08ae16956b8944da2fef75fee892dcba457cf4f0README
 $

 $ (stat --printf='blob %s\0' README; cat README) | sha1sum
 08ae16956b8944da2fef75fee892dcba457cf4f0  -
 $

 This is so simple to generate that it doesn't really need a
 placeholder in every ebuild in the repository.


  The primary use case of it is to allow users to easily see what
  version of a given ebuild they are using.

 I guess the merits of this use case are up for discussion also
 outside of infra?

 I think a single tree-wide identifier (let's it a snapshot identifier?)
 would be far more useful.

I already filed a bug for this:

https://bugs.gentoo.org/557366

-- Jason

Re: [gentoo-dev] Bisecting Was: Referencing bug reports in git

[Jason Zaman]

On Wed, Aug 12, 2015 at 07:20:54AM +, Duncan wrote:
 hasufell posted on Tue, 11 Aug 2015 13:58:20 +0200 as excerpted:
 
  In addition, we just took the freedom to add the clause all commits
  must be repoman-valid:
  https://wiki.gentoo.org/index.php?
 title=Gentoo_git_workflowdiff=352978oldid=352858
  
  That will be necessary too for the CI work mgorny is doing and will also
  make bisecting and cherry-picking easier.
 
 The mention of bisect got me thinking... I'm not exactly sure I'm wording 
 this right, but hopefully the question is clear enough...
 
 What are the practical implications of and reasons for doing a bisect, on 
 a package-tree repo, where it's typically the out-of-tree package sources 
 where most functionality-bisection would happen, and in-tree commits tend 
 to result in atomic package updates, or at least atomic USE flag, etc, 
 changes on a package?
 
 The typical reason for a bisect is to find the commit where a bug 
 originated, but that's upstream package/project bisects.  I don't quite 
 see how that maps to distro package tree repo bisects, as it seems to me 
 there's nothing really to bisect -- problems should be with specific 
 package versions or with USE flag or similar changes within an ebuild/
 eclass, and it seems to me that's known along with awareness of the 
 problem in the first place, leaving no reason to bisect to find the 
 problem.
 
 Tho arguably eclass change issues are an exception, and bisectable in the 
 usual sense for the usual purpose.  Actually, that could make 
 troubleshooting eclass updates MUCH simpler than it was before.  Luckily, 
 at least I as a user didn't end up with too many direct eclass issues to 
 troubleshoot.

I agree that bisecting would typically not happen that often because
usually you'd just emerge =cat/pkg-1.2.3 but there are times when
updates are done without a revbump that might have broken something so
it could be useful. Also eclasses would definitely be useful. There are
a few useful cases when it might make things easier but probably rare,
tho its good to have the tool available in case.

 Tho I can definitely think of a non-traditional use for bisect.  While I 
 update my workstation more or less weekly, I updated my 32-bit 
 netbook[1]  far less frequently, every year or two.  It occurs to me that 
 using git bisect to automate working out the resulting update issues 
 might be far easier than some of the manual tricks and workaround I used 
 to end up doing, to finally get an updated to current, working system 
 once again.  Bisect start, immediately declare bisect bad, inner looping 
 until I got to about a three-month update, update to it, bisect reset, 
 outer-looping on the bisect to another 3-4 month update... until I was 
 caught up.  Of course one can't go back past our current switch to git, 
 but in five years, one could in theory pull the old laptop out that was 
 last updated yesterday, and roll back gentoo's now five-years-future tree 
 four years and nine months, and start the update process, ultimately 
 bringing it upto date without starting with a new stage tarball install, 
 as would have been the only really feasible pre-git alternative for a 
 five-year-outdated system.  Not that a new stage tarball wouldn't be 
 faster after five years in any case, but at least the incremental update-
 in-place should now be possible.

I like the idea, but its probably easier to just
git checkout $(git rev-list -n 1 --before=2015-12-01 12:00 master)
and then you just change the date a month at a time or something

-- Jason

 ---
 [1] 32-bit netbook: Now gone and not yet replaced, but I intend to get 
 another, tho amd64 this time so I can mostly build once for both, one for 
 three if I setup an amd64-based router as I intend to as well, and 
 hopefully avoid the year-plus update period issue as I can just binpkg-
 update after the first one.
 
 -- 
 Duncan - List replies preferred.   No HTML msgs.
 Every nonfree program has a lord, a master --
 and if you use the program, he is your master.  Richard Stallman
 
 

Re: [gentoo-dev] [PATCH python-utils-r1 2/4] Wrap pythonN-config as well

[Jason Zaman]

On Sat, Jul 25, 2015 at 12:37:42PM +0200, Michał Górny wrote:
 Fixes: https://bugs.gentoo.org/show_bug.cgi?id=94
 ---
  eclass/python-utils-r1.eclass | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
 index c1c5ea6..69d3262 100644
 --- a/eclass/python-utils-r1.eclass
 +++ b/eclass/python-utils-r1.eclass
 @@ -873,7 +873,10 @@ python_wrapper_setup() {
   #!/bin/sh
   exec ${PYTHON}-config \${@}
   _EOF_
 - chmod +x ${workdir}/bin/python-config || die
 + cp ${workdir}/bin/python-config \
 + ${workdir}/bin/python${pyver}-config || die
 + chmod +x ${workdir}/bin/python-config \
 + ${workdir}/bin/python${pyver}-config || die

This could alternatively be python as a symlink - python3 which is the
wrapper, but I dont think having two wrappers vs symlink to a wrapper
makes any real difference.
  
   # Python 2.6+.
   ln -s ${PYTHON/python/2to3-} ${workdir}/bin/2to3 || 
 die
 @@ -883,7 +886,7 @@ python_wrapper_setup() {
   ${workdir}/pkgconfig/python.pc || die
   ln -s python.pc 
 ${workdir}/pkgconfig/python${pyver}.pc || die
   else
 - nonsupp+=( 2to3 python-config )
 + nonsupp+=( 2to3 python-config python${pyver}-config )

This should be both 2 and 3, if its not CPython, neither should be
allowed, this bans only $pyver.

Re: [gentoo-dev] [PATCH python-utils-r1 3/4] Ban calling pythonY and pythonY-config when pythonX is used

[Jason Zaman]

On Sat, Jul 25, 2015 at 12:37:43PM +0200, Michał Górny wrote:
 Ban calling python3{,-config} when python2 is used, and the other way
 around. While this will not prevent configure scripts from finding the
 other Python version, it will cause them to fail eventually trying to
 use it. Currently those attempt were able to pass through thanks to
 python-config providing python{2,3} symlinks.

you mean eselect providing.

 ---
  eclass/python-utils-r1.eclass | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
 index 69d3262..2584f3e 100644
 --- a/eclass/python-utils-r1.eclass
 +++ b/eclass/python-utils-r1.eclass
 @@ -847,11 +847,13 @@ python_wrapper_setup() {
   local EPYTHON PYTHON
   python_export ${impl} EPYTHON PYTHON
  
 - local pyver
 + local pyver pyother
   if python_is_python3; then
   pyver=3
 + pyother=2
   else
   pyver=2
 + pyother=3
   fi
  
   # Python interpreter
 @@ -865,7 +867,7 @@ python_wrapper_setup() {
   cp ${workdir}/bin/python ${workdir}/bin/python${pyver} || 
 die
   chmod +x ${workdir}/bin/python 
 ${workdir}/bin/python${pyver} || die
  
 - local nonsupp=()
 + local nonsupp=( python${pyother} python${pyother}-config )

I have had basically this exact patch locally for a few days since we
talked about it and it hasnt been a problem yet but is not very much
testing. I was wondering if perhaps this should be a qawarn for a while
first instead of banning immediately?

   # CPython-specific
   if [[ ${EPYTHON} == python* ]]; then
 -- 
 2.4.6

Re: [gentoo-dev] [PATCH python-utils-r1 2/4] Wrap pythonN-config as well

[Jason Zaman]

On Sat, Jul 25, 2015 at 10:12:48PM +0800, Jason Zaman wrote:
 On Sat, Jul 25, 2015 at 12:37:42PM +0200, Michał Górny wrote:
  Fixes: https://bugs.gentoo.org/show_bug.cgi?id=94
  ---
   eclass/python-utils-r1.eclass | 7 +--
   1 file changed, 5 insertions(+), 2 deletions(-)
  
  diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
  index c1c5ea6..69d3262 100644
  --- a/eclass/python-utils-r1.eclass
  +++ b/eclass/python-utils-r1.eclass
  @@ -873,7 +873,10 @@ python_wrapper_setup() {
  #!/bin/sh
  exec ${PYTHON}-config \${@}
  _EOF_
  -   chmod +x ${workdir}/bin/python-config || die
  +   cp ${workdir}/bin/python-config \
  +   ${workdir}/bin/python${pyver}-config || die
  +   chmod +x ${workdir}/bin/python-config \
  +   ${workdir}/bin/python${pyver}-config || die
 
 This could alternatively be python as a symlink - python3 which is the
 wrapper, but I dont think having two wrappers vs symlink to a wrapper
 makes any real difference.
   
  # Python 2.6+.
  ln -s ${PYTHON/python/2to3-} ${workdir}/bin/2to3 || 
  die
  @@ -883,7 +886,7 @@ python_wrapper_setup() {
  ${workdir}/pkgconfig/python.pc || die
  ln -s python.pc 
  ${workdir}/pkgconfig/python${pyver}.pc || die
  else
  -   nonsupp+=( 2to3 python-config )
  +   nonsupp+=( 2to3 python-config python${pyver}-config )
 
 This should be both 2 and 3, if its not CPython, neither should be
 allowed, this bans only $pyver.

The other patch adds $pyother earlier on, so this is correct. My
mistake.

Re: [gentoo-dev] Managing etc/* in an embbeded system

[Jason Zaman]

On Wed, Jul 22, 2015 at 01:20:10PM +, Joakim Tjernlund wrote:
 On Wed, 2015-07-22 at 14:30 +0200, Michał Górny wrote:
  
  Joakim Tjernlund joakim.tjernl...@transmode.se napisał:
  
   We got an embedded gentoo system where we need to manage many conf
   files under /etc that we have
   modified and should be under our control when an SW upgrade is
   performed.
   
   Cloning every ebuild where we have modified its conf file(s) under /etc
   feels awkward so
   I am looking for some other way to do this automatically during SW
   upgrade and I figured
   this can not be an unique problem for us, so I wonder how other people
   have solved this problem?
   Our customers will not use emerge directly and we will provide binary
   pkgs.
   
   Any ideas welcome :)
   
   Jocke
  
  Maybe post-phase hooks would help you. Not around a PC right now but I 
  think they're described in portage.5. 
  Long story short, you create per-package env files in /etc/portage/env (you 
  can pin them generically or to a 
  specific version, or package spec via package.env) and declare 
  post_src_install() where you add your custom 
  config files atop the package.  
  
 
 hmm, that sounds interesting but I don't quite get what to do, you think I 
 should copy over /etc/inittab after
 it has been installed by sys-apps/sysvinit with my own version(which is 
 stored where?)
 
 This gave me an idea though:
 In /etc/portage/env/install-mask.conf I add
   INSTALL_MASK=${INSTALL_MASK} /etc/inittab /etc/xxx
 then in /etc/portage/package.env/install-mask
   sys-apps/sysvinit install-mask.conf
   sys-apps/xxx install-mask.conf
   ...
 (Can I do this from my own custom profile instead? how?)
 
 This should prevent sys-apps/sysvinit to install conf files I want to manage, 
 right?
 
 Then I create my own new ebuild holding all config files I have changed 
 myself.

Or you can put a script in /etc/portage/hooks/install/, it will get run
after src_install() during generation of VDB and all that, you could
probably move everything from /etc/ to /etc-orig/ then all packages will
be have things set there, then put your own files in /etc and you can
always refer to /etc-orig/ or even use overlayfs or something to mount
your files on top so they cover the package ones.

-- Jason

Re: [gentoo-dev] [RFC] Rebooting the Installer Project

[Jason Zaman]

On Tue, Jul 21, 2015 at 03:05:04AM +0300, Andrew Savchenko wrote:
 On Mon, 20 Jul 2015 10:51:00 +0200 Michał Górny wrote:
  Dnia 2015-07-18, o godz. 12:01:48
  Matthew Marchese maffblas...@gentoo.org napisał(a):
  
   I have recently pressed the reboot button on the ol' Installer project. 
   I've been able to talk to quite a few developers one-on-one via IRC 
   concerning my plans. Most seem to be in support of Gentoo having a 
   official installer (the biggest concern is appears to be how things 
   will be implemented and the amount of features involved). This e-mail is 
   to fulfill GLEP 39's request for comments (RFC), concerns, requests, etc. 
   Since I'm a little new to the project I'm coming with a bit of ignorance; 
   I know the previous Installer project fostered mixed feelings.
   
   If you'd like to review before replying you can see the Wiki page and 
   find the source on GitHub: https://github.com/gentoo/stager
   
   To summarize I'm writing it in pure Python 3. It first will be able to 
   create full backups (stage 4s) and recoveries. After that is finished I 
   plan to move on to installations. There will potentially be a web 
   interface UI for it. Others are free to create other front-ends; to me a 
   web UI makes the most sense and would probably require the least deps.
   
   I'd like to hear it all so please speak your mind. Looking forward to 
   hearing from you.
  
  On a semi-related note, I was thinking about doing a semi-related
  project :).
  
  I personally don't think Gentoo needs installer as-is. However, I think
  we'd really benefit from having some kind of helper scripts / checklist
  of tasks to be done prior to/after install.
  
  For example, you'd run 'check-my-install' script and it'd tell you what
  you likely forgot to set up :).
  
 Maybe a bit off-topic, but occasionally I need a tool to fast
 install Gentoo and fine-tune it later. This happens quite often on
 a new job box, oh during visits where I'm given a workstation and
 3-4 hours to set it up before doing real work and so on.
 
 The idea is to have binary-based Gentoo ready to work on general
 common hardware with such software out of the box as fully-fledged
 modern gui browsers (chromium, firefox), libreoffice, xterm,
 screen, vim, compilers, ldap support and other dev tools. Set of
 packages may vary, but the idea is that they should work out of the
 box due to tight constrains on initial system configuration (boss
 should see that I'm doing my job at the end of the day).
 
 But afterwards I'd like to tune this setup in a usual Gentoo way:
 configure kernel, USE flags, {C,CXX,F,FC,LD}FLAGS, select proper
 alternatives and so on more or less accordant to the devmanual.
 
 Self prepared catalyst build for general ~amd64 looks appropriate
 to the task, but they require too much maintenance effort: each
 update is a pain and quite time consuming and I need such images
 only once or twice per year, but still I need them!
 
 In the ideal world it would be nice to have such stage4 ebuilds
 available to speed-up initial installation and configuration
 process.
 
 Best regards,
 Andrew Savchenko

Take a look at the new project Blueness is working on:
https://wiki.gentoo.org/wiki/Project:RelEng_GRS

It basically builds binpkgs for a few standard configurations so it
sounds exactly like what you want.

-- Jason

Re: [gentoo-dev] Re: Reverted python3.4 defaults

[Jason Zaman]

On Mon, Jul 20, 2015 at 10:39:25AM +0200, Dirkjan Ochtman wrote:
 On Mon, Jul 20, 2015 at 6:03 AM, Ben de Groot yng...@gentoo.org wrote:
  I don't see any strong technical reason to switch from python2 +
  python3 to python2-only enabled. Some people don't like having two
  versions of python installed -- that's about the gist of it.
 
  Indeed, there is no strong technical reason, except that some people
  like to keep their systems more lean. But I think having a smaller
  stage3 tarball is a more important reason. The python team has
  historically left that up to the RelEng team, which has been averse to
  handling that themselves.
 
  So, I'm personally not going to make that change without some kind of
  vote on it. I can arrange a vote within the python team if you like.
 
  I would like to hear from the other team members, yes.
 
 I have sympathy towards those who are asking for only one Python in
 stages (as in, I would be fine with that), but I very much think we
 should not leave Python 3 out of generally installed systems by
 default. We need to move through the transition, and increasing the
 barriers to Python 3 adoption will only make that process slower.
 
 I also feel like a voting process for this is probably not a solution.

I also very much dislike shipping only python2. Having only one python
is admirable and I'm all for it but if we only ship one by default it
should be python3.

Fedora's next release is going to ship only python3 in all their media
(livecd, default install etc). Of course they will allow python2 to be
installed too but that will have to be a concious choice by the user.

https://fedoraproject.org/wiki/Changes/Python_3_as_Default

I think the change next weekend should be as originally stated and have
2_7,3_4. Later on (perhaps we can see how fedora manages) we can see if
dropping 2_7 from the default stages would be doable.

-- Jason

Re: [gentoo-dev] Any deptree stabilization/keywording path finder?

[Jason Zaman]

On Fri, Jul 17, 2015 at 01:15:53PM +0300, Andrew Savchenko wrote:
 Hello,
 
 TL;DR Is there any tool to build dependency tree for all packages
 needed to be stabilized (or keyworded) in order stabilize (keyword)
 foo/bar?

gnome team has this, its pretty good and has a --check-dependencies too.
Gilles has done a bunch of cleanups on it but not merged back in yet.
https://gitweb.gentoo.org/proj/gnome.git/tree/scripts/gen_archlist.py?h=gen_archlist_cleanup
 
 Sometimes in order to stabilize a single version bump a whole lot
 of packages needs to be stabilized as dependencies. A good example
 is [1]. What I really need here is to stabilize
 dev-haskell/pandoc-siteproc (I don't even care about exact version,
 since any version looks ok for app-doc/root-docs), but this
 triggers a whole lot of haskell packages to be stabilized. There
 are several issues here:
 
 1. There are many solutions for this issue, since version
 requirements usually allow some range of versions. Looks like this
 is a classical graph path finding task. It would be great to have a
 tool for best effort solution: e.g. for a tree with minimal number
 of dependencies of with most recent packages possible (for those
 which are in the tree for at least 30 days).

it does not check this yet tho, but thats not too bad i suppose.
 
 2. It is very tedious to build such dependency tree manually (this
 is how it was done in [1]). To make it worse such work is
 error-prone, because it is near to impossible to check that each
 stabilization in the dependency tree will not trigger any blocker
 in the whole portage tree. Actually at least one such error was made
 [2]. The best that can be done by hand is to verify that the
 stabilization dependency tree is self-consistent, but even this
 check requires a lot of time and effort.
 
 All these problems should be solvable with an appropriate tool, but
 I can't find such tool. Apparently it should inherit some of emerge
 and repoman functionality for deptree building and checking
 respectively.
 
 Any ideas? I suppose arch teams should have something similar for
 their goals.
 
 P.S. Note for the record: I filed a lot of stabilization request
 for dev-haskell/* packaged I do not maintain, because haskell team
 had not responded in a reasonable amount of time for my stable
 request [3]. I'm not blaming anyone here, just explaining why such
 action was taken.
 
 [1] https://bugs.gentoo.org/showdependencytree.cgi?id=529538hide_resolved=0
 [2] https://bugs.gentoo.org/show_bug.cgi?id=552388
 [3] https://bugs.gentoo.org/show_bug.cgi?id=546260
 
 Best regards,
 Andrew Savchenko

Re: [gentoo-dev] Re: Git workflow

[Jason Zaman]

On Sun, Jul 05, 2015 at 12:03:29PM +0700, C Bergström wrote:
 On Sun, Jul 5, 2015 at 11:31 AM, Duncan 1i5t5.dun...@cox.net wrote:
  C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted:
 
  I super don't like merge workflows.
  1) merge commits are confusing at best and normal tools don't display
  and work with them as you'd always expect
 
  git log --graph, as others have mentioned.
 
 we are not talking about the same thing.
 
 I want to see the diff - not the graph.
 
 svn diff -r 1234
 git show hash
 
 show me the merge commit in diff format

So this isn't a good comparison. You are asking for a merge commit in
git and a normal commit in svn. Svn can branch but it is so complicated
that no one ever does it. If you were similarly to never ever make
branches in git its not a huge deal. (There are not *that* many pushes
to the tree, if you look at #gentoo-commits there is plenty of time
between commits.)

While I personally rebase almost all of my stuff, merges are important
when taking contributions. A good example would be the main linux kernel
tree, if Linus were to merge everything it would be incredibly difficult
to figure anything out.

-- Jason

Re: [gentoo-dev] Git Migration: launch plan schedule (2015/Aug/08-09)

[Jason Zaman]

On Fri, Jul 03, 2015 at 12:24:42PM -0400, NP-Hardass wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On Fri, 3 Jul 2015 11:19:13 -0500
 William Hubbs willi...@gentoo.org wrote:
 
  On Fri, Jul 03, 2015 at 06:34:41AM +, Robin H. Johnson wrote:
   On Thu, Jul 02, 2015 at 09:46:18PM -0400, Brian Evans wrote:
Does this mean that
https://wiki.gentoo.org/wiki/Gentoo_git_workflow is no longer
draft or needs work or another document is meant to display the
new flow?
   It does cover most of the things needed.
   
   It could use some revision regarding gkeys, and I'd like to also
   mandate signed pushes in addition to signed commits.
  
  A push doesn't create any data, it just uploads it to the repo, so how
  do you sign a push?
  
  William
  
 
 Repoman may need to be adjusted. Git commit has support for a -S
 flag which signs the commit.

No that is different. There are two signing things involved here.
1) git commit -S. ie sign the commit in the tree, and git log will show
that signature later.

2) git push -S, this is signing the push itself. The client will sign
everything that it pushes to the server. Then the server can verify that
it was pushed by a dev (which is different from the commit since a dev
might be pushing a commit that was made by a user). The server will save
this push certificate so that it can also be verified later on.

We'll want to have both of these on. It may require some repoman changes
but should not be that much.

-- Jason

Re: [gentoo-dev] net-misc/strongswan USE_EXPAND

[Jason Zaman]

On Tue, Jun 23, 2015 at 08:05:35AM +0200, Michał Górny wrote:
 Dnia 2015-06-23, o godz. 01:48:58
 Alexandre Rostovtsev tetrom...@gentoo.org napisał(a):
 
  On Tue, 2015-06-23 at 07:06 +0200, Michał Górny wrote:
   Dnia 2015-06-23, o godz. 01:23:13
   Jason Zaman ja...@perfinion.com napisał(a):
   
On Mon, Jun 22, 2015 at 10:55:45PM +0200, Michał Górny wrote:
 Dnia 2015-06-22, o godz. 16:38:30
 Jason Zaman perfin...@gentoo.org napisał(a):
 
  Hi all,
  
  I want to add STRONGSWAN_PLUGINS to USE_EXPAND. This is related 
  to bug
  https://bugs.gentoo.org/show_bug.cgi?id=504942
  net-misc/strongswan missing USE flags for plugins
  
  Patrick said to fix it myself, the ebuilds with the plugins 
  have
  been in the tree for a fair while now and only the USE_EXPAND 
  is
  missing.
  
  If there are no objections, I will commit the following patch 
  on friday:
 
 USE_EXPAND is global by its nature. USE flags used by a single 
 package
 are not appropriate for making global.

Since when? There are so many things in USE_EXPAND that are only 
for a
single package.
   
   Not sure when. But the policies about USE flags were in the devmanual
   long before I came here.
   
APACHE2_MODULES, NGINX_MODULES_HTTP, COLLECTD_PLUGINS, QEMU_*, etc.
Easily half of the things in USE_EXPAND are for only a single 
package.
   
   Past screwups don't justify future screwups.
  
  I don't see it as a screwup personally.
  
  It is often useful to have different namespaces for the few general
  flags that control a package's general features and the 9000 flags
  that enable/disable 9000 highly specific plugins.
  
  And if violation of the rules is useful, perhaps the rules are wrong?
 
 Then perhaps you go and fix the rules instead of ignoring them?
 
 But please also remember to provide the ability to describe those flags
 per-package rather than globally, like they are done now. Would be good
 to also avoid declaring them globally, like having 50 groups listed in
 USE_EXPAND.
 
 When you're done with that, and get all package managers to support it
 in a reasonably long stable version, then we can discuss about changing
 the rules.

I dont quite follow, the useflags are described in the packages
metadata.xml, are not conflicting and are supported by everything.

Is there a rule that everything that is USE_EXPAND'd is a global
useflag? I see no such rule and I dont understand why it would even make
sense. USE_EXPAND arnt useflags, it is just a variable to make useflags
look nicer, they shouldnt all have to be global. What if one and only
one package supports a specific video_card? Should that use-flag be made
global?

Adding use_expand's for foo_plugins makes things a lot easier to manage
and understand tho. The only possible downside I can see is that there
are a lot of entries in it, but we have a lot of useflags so thats hardly
an issue.

-- Jason

Re: [gentoo-dev] net-misc/strongswan USE_EXPAND

[Jason Zaman]

On Mon, Jun 22, 2015 at 10:55:45PM +0200, Michał Górny wrote:
 Dnia 2015-06-22, o godz. 16:38:30
 Jason Zaman perfin...@gentoo.org napisał(a):
 
  Hi all,
  
  I want to add STRONGSWAN_PLUGINS to USE_EXPAND. This is related to bug
  https://bugs.gentoo.org/show_bug.cgi?id=504942
  net-misc/strongswan missing USE flags for plugins
  
  Patrick said to fix it myself, the ebuilds with the plugins have
  been in the tree for a fair while now and only the USE_EXPAND is
  missing.
  
  If there are no objections, I will commit the following patch on friday:
 
 USE_EXPAND is global by its nature. USE flags used by a single package
 are not appropriate for making global.

Since when? There are so many things in USE_EXPAND that are only for a
single package.

APACHE2_MODULES, NGINX_MODULES_HTTP, COLLECTD_PLUGINS, QEMU_*, etc.
Easily half of the things in USE_EXPAND are for only a single package.

-- Jason

[gentoo-dev] net-misc/strongswan USE_EXPAND

[Jason Zaman]

Hi all,

I want to add STRONGSWAN_PLUGINS to USE_EXPAND. This is related to bug
https://bugs.gentoo.org/show_bug.cgi?id=504942
net-misc/strongswan missing USE flags for plugins

Patrick said to fix it myself, the ebuilds with the plugins have
been in the tree for a fair while now and only the USE_EXPAND is
missing.

If there are no objections, I will commit the following patch on friday:

-- Jason

Index: make.defaults
===
RCS file: /var/cvsroot/gentoo-x86/profiles/base/make.defaults,v
retrieving revision 1.127
diff -u -B -r1.127 make.defaults
--- make.defaults   5 Jun 2015 07:59:18 -   1.127
+++ make.defaults   22 Jun 2015 12:33:12 -
@@ -16,7 +16,7 @@
 
 # Env vars to expand into USE vars.  Modifying this requires prior
 # discussion on gentoo-dev@lists.gentoo.org.
-USE_EXPAND=ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES 
APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_X86 
CROSSCOMPILE_OPTS CURL_SSL DRACUT_MODULES DVB_CARDS ELIBC ENLIGHTENMENT_MODULES 
FCDSL_CARDS FFTOOLS FOO2ZJS_DEVICES FRITZCAPI_CARDS GPSD_PROTOCOLS 
GRUB_PLATFORMS INPUT_DEVICES KERNEL LCD_DEVICES LIBREOFFICE_EXTENSIONS LINGUAS 
LIRC_DEVICES MONKEYD_PLUGINS NETBEANS_MODULES NGINX_MODULES_HTTP 
NGINX_MODULES_MAIL OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS 
OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS PYTHON_SINGLE_TARGET 
PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS RUBY_TARGETS 
SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS VOICEMAIL_STORAGE XFCE_PLUGINS 
XTABLES_ADDONS
+USE_EXPAND=ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES 
APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_X86 
CROSSCOMPILE_OPTS CURL_SSL DRACUT_MODULES DVB_CARDS ELIBC ENLIGHTENMENT_MODULES 
FCDSL_CARDS FFTOOLS FOO2ZJS_DEVICES FRITZCAPI_CARDS GPSD_PROTOCOLS 
GRUB_PLATFORMS INPUT_DEVICES KERNEL LCD_DEVICES LIBREOFFICE_EXTENSIONS LINGUAS 
LIRC_DEVICES MONKEYD_PLUGINS NETBEANS_MODULES NGINX_MODULES_HTTP 
NGINX_MODULES_MAIL OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS 
OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS PYTHON_SINGLE_TARGET 
PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS RUBY_TARGETS 
SANE_BACKENDS STRONGSWAN_PLUGINS USERLAND UWSGI_PLUGINS VIDEO_CARDS 
VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS
 
 # USE_EXPAND variables whose contents are not shown in package manager
 # output. Changes need discussion on gentoo-dev.

Re: [gentoo-dev] RFC: ban EAPI 1

[Jason Zaman]

On Wed, Jun 10, 2015 at 10:43:10PM +0200, Ulrich Mueller wrote:
 Hi,
 The number of EAPI 1 ebuilds in the Portage tree has decreased to
 a total of 60, corresponding to 0.16 %.
 
 We briefly discussed in the QA team if we should demote EAPI 1 in
 layout.conf from eapis-deprecated to eapis-banned. This would
 have the consequence that repoman would refuse to commit packages
 containing such ebuilds. AFAICS there would be no impact on users.
 
 What do you think?
 
 Ulrich

This would be great! Do we have a list somewhere of ebuilds that are
still EAPI1? and which of those have a newer version that is a higher
EAPI for the same keywords? IE how many of the EAPI1 ebuilds cant just
be dropped?

-- Jason

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Jason Zaman]

On Sat, Jun 06, 2015 at 10:02:53AM +0200, Ulrich Mueller wrote:
  On Sat, 6 Jun 2015, Michał Górny wrote:
 
  Tabs are too wasteful on space. Therefore, two spaces, and no
  indentation of the top-level elements.
 
  That's nonsense. Tab = 1 byte. Two spaces = 2 bytes.
 
 Visual space.

:set ts=2
done :)
 
 Ulrich

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Jason Zaman]

On Sat, Jun 06, 2015 at 09:34:41AM +0200, Michał Górny wrote:
 Dnia 2015-06-06, o godz. 09:26:08
 Justin Lecher (jlec) j...@gentoo.org napisał(a):
 
  Can we get an agreement on how we are indenting metadata.xml?
  
  I like to properly format and indent metadata.xml, but without having
  an agreement or policy on the indention, I make unhappy by choosing
  the wrong.
  
  The two options which are already suggested are
  
  * 2 spaces
  * single tab
  
  So what should it be?
 
 A tab. With one-line element contents being inline, while multi-line in
 deeper indented block, i.e.:
 
 ...maintainer
 ..nameFoo Bar/name
 ..emailb...@example.com/email
 .../maintainer
 ...longdescription
 ..Some random text. Possibly spanning multiple lines.
 ..Like this.
 .../longdescription

This one definitely. Tabs let people set the tabstop themselves and its
all easy. Can we get repoman to autoformat the xml files during a commit
too?

-- Jason

Re: [gentoo-dev] Packages up for grabs

[Jason Zaman]

On Sat, Jun 06, 2015 at 06:02:48PM +0200, Jauhien Piatlicki wrote:
 Hi,
 
 the list of packages that I'm no longer interested in:
 
 media-sound/apulse -- needs version bump
 dev-util/android-ndk -- needs version bump

I'll take android-ndk since I already maintain android-studio.

-- Jason

Re: [gentoo-dev] [RFC] Make manifest signatures mandatory for repoman commit

[Jason Zaman]

On Wed, Apr 15, 2015 at 12:27:08PM +0300, Andrew Savchenko wrote:
 On Wed, 15 Apr 2015 11:06:22 +0200 Michał Górny wrote:
  Dnia 2015-04-15, o godz. 11:59:12
  Andrew Savchenko birc...@gentoo.org napisał(a):
  
   Hi,
   
   why manifest signatures are still optional for repoman?
   
   Repoman signatures are currently optional and this creates nasty
   consequences: if signing errors occurs, repoman still proceeds :/
   
   I just had a phone call during repoman commit and was not able to
   type my password. Due to gpg-agent timeout repoman completed commit
   without a signature :( Should signatures be mandatory, repoman will
   bail out on such conditions and devs can recommit again safely.
  
  This is problem with the CVS two-commit procedure. The only solution is
  to stop using CVS keywords which people don't want to do because THEY
  ARE SO VERY USEFUL.
  
  Or make repoman do first commit without Manifest, so instead of
  unsigned Manifest you'd have Manifest failure.
 
 Is there any way to commit manifest first, then the rest of the
 files? Of course there may be a network failure in-between, but
 this should easily fixable with one more repoman commit run.

no. the problem is that all the files change when they are committed.
the $ Header: x $ line has the commit time and stuff. so the two
phase first commits all the ebuilds and everything then when the lines
are fixed it re-makes the manifest and commits.

I dont think it can be fixed without getting rid of the $Header$ line.
I'd be all for it, those lines seem like more trouble than its worth to me.

-- Jason

Re: [gentoo-dev] shouldn't eselect be in app-eselect ?

[Jason Zaman]

On Sat, Apr 04, 2015 at 08:49:51PM +0200, Michał Górny wrote:
 Dnia 2015-04-04, o godz. 13:47:47
 Alex Brandt alund...@gentoo.org napisał(a):
 
  On Saturday, April 04, 2015 14:41:37 Philip Webb wrote:
   I read the recent thread re the new app-eselect.
   Doing my weekly system update,
   it strikes me that 'eselect' itself sb there too.
   
   Time to paint the bikesheds again ... (smile)
  
  I don't disagree but will simply point out that if this becomes true, we 
  should also move dev-lang/python to dev-python, dev-lang/ruby to dev-ruby, 
  and 
  dev-lang/perl to dev-perl (not an exhaustive list).
 
 Portage to app-portage/, web browsers with plugins to www-plugins/...

also, dev-java/oracle-jdk-bin, dev-java/icedtea ...

 
 -- 
 Best regards,
 Michał Górny

[gentoo-dev] [PATCH 1/2] Document policy of not relying on implicit eclass inherits]

[Jason Zaman]

Ian was having problems sending to the list so I am forwarding this to
the list on his behalf.

- Forwarded message from Ian Delaney idel...@gentoo.org -

From: Ian Delaney idel...@gentoo.org
To: perfin...@gentoo.org
Date: Sat, 28 Feb 2015 11:05:36 +0800
Subject: Fw: [gentoo-dev] [PATCH 1/2] Document policy of not relying on 
implicit eclass inherits
X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.25; x86_64-pc-linux-gnu)



Begin forwarded message:

Date: Sat, 28 Feb 2015 10:43:52 +0800
From: Ian Delaney idel...@gentoo.org
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH 1/2] Document policy of not relying on
implicit eclass inherits


On Wed, 25 Feb 2015 16:34:35 +0100
Julian Ospald hasuf...@gentoo.org wrote:

 ---
  ebuild-writing/using-eclasses/text.xml | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)
 
 diff --git a/ebuild-writing/using-eclasses/text.xml
 b/ebuild-writing/using-eclasses/text.xml index de9ec7f..49ec23b 100644
 --- a/ebuild-writing/using-eclasses/text.xml
 +++ b/ebuild-writing/using-eclasses/text.xml
 @@ -26,7 +26,15 @@ link=::general-concepts/portage-cache/).
  /p
  
  p
 -After inheriting an eclass, its provided functions can be used as
 normal. Here's an example ebuild, cfoomatic-0.1-r2.ebuild/c, which
 uses four eclasses: +After inheriting an eclass, its provided
 functions can be used as normal. +/p +warning
 +You must not rely on provided functions of implicitly inherited
 eclasses. +As an example: if you use cepatch/c in your ebuild,
 you bmust/b +inherit ceutils.eclass/c directly, even if
 another eclass (like distutils-r1) +already inherits it. Exceptions
 to this policy must be discussed and documented. +/warning
 +pHere'san example ebuild, cfoomatic-0.1-r2.ebuild/c, which
 uses four eclasses: /p
  
  codesample lang=ebuild

This effectively illegalises the very action I have gone to pains to
attempt to declare sane.  While the attempt to improve or standardise a
practice has merit, this text is objectionable.  There are dozens of
ebuilds that inherit only distutils-r1 and utilise its functions and or
vars.  This single change will make my commits of last 2 years a
violation of policy, in a retrograde manner ofcourse.  

While the principle here has some merit (somewhere), this approach is
declaring it a generalised policy, and unconditionally.   The approach
here is dogmatic and unyielding.  I decided long ago the inheriting of
eutils explicitly to be unwarranted duplication and a waste of bytes on
the line of inherit in so many ebuilds.  Now in the early stages of
attempting mass conversions and with a history of 2 years of an
established pattern of use, this change is now proposed which
illegitimises it all.

The flaw here is that it is using a black and white and reductionist
approach. It presumes the validity of reducing all scenarios to a single
broad sweeping rule. The impact of implicit inherits by any and all
eclasses are therefore presumed to apply under this one policy.  The
art of programming is an art as much as it is a science, and it comes in
shades of grey, at least 50 of them, not to mention rooms of various
shades of pastel red.  Surely by now we all grasp the variations and
subtleties that crop up in writing both ebuilds and eclasses.  In
doing the conversions I am forced to take the old packages' ebuilds on
a case by case basis.  While the scenarios don't wholly equate here
(those shades of grey again damn them), sweeping generalisations are
what frighten me. Do not back gentoo's ebuild writers into a corner
where they have to scrap their way out, under the accusing waving
finger of qa. We have enough of that already.

If the python eclasses or eutils were to be edited in the future, they
are duty bound to not break rev dependencies.  Sure there are scenarios
or rationale that warrant explicit inheriting in the style you're
recommending.  This change doesn't allow for those that don't.  It
generalises.

There are options.  You could make a policy instead that enforces the
duplication of the code of an eclass, whole or in part, and therefore
avoid the need of it being inherited at all; so much for write once use
many.

Enough said. Off to the blue room.



.-- 
kind regards

Ian Delaney


-- 
kind regards

Ian Delaney

- End forwarded message -

Re: [gentoo-dev] new bitcoin eclass

[Jason Zaman]

On Fri, Feb 06, 2015 at 02:46:37AM +, Luke Dashjr wrote:
 On Friday, February 06, 2015 2:10:31 AM hasufell wrote:
  Why does it not use git-r3?
 
 I just looked into this, and I don't see a way to get git-r3 to use the same 
 repositories already cloned for previous versions. What is the standard 
 practice for ebuilds already using git-2?

It might handle that automatically, there are some references in the
eclass about it but i am far from an expert on that eclass.

Also, there is the EGIT_COMMIT variable, so you can remove the whole 
BITCOINCORE_COMMITHASH bit.

also:
if [ -z $BITCOINCORE_COMMITHASH ]; then
inherit git-2
is weird, it's normally if [[ ${PV} = ** ]]


  I don't understand why bitcoincore_pkg_pretend(), bitcoincore_src_test()
  are defined twice. I think you mistyped the names here slightly.
 
 This was a remnant from an older version of the eclass, removed.

Is bitcoincore_src_test needed at all? The default src_test function
will do exactly the same thing (and better) so you can remove this and
just let the default be used.

Also, why does bitcoincore_src_install call bitcoincore_install? why
have two functions that are the same?

I would probably do:
bitcoincore_src_install() {
default
[ ${PN} = libbitcoinconsensus ] || rm ${D}/usr/bin/test_bitcoin
}

  autoreconf is not reliable and we know that it sometimes unpredictably
  fails. Running it unconditionally is a bit strong, no?
 
 What should be used instead, to generate configure etc?
 
  bitcoincore_conf() looks like it could make use of 'usex' and
  'use_enable' instead of those difficult to read if-else conditions.
 
 These will give QA issues for ebuilds that don't have the applicable USE flag 
 available in IUSE.
how about: in_iuse flag  my_econf = ${my_econf} $(use_enable flag)

I dont really understand the pkg_pretend stuff, shouldnt all that stuff
be in the useflag descriptions?

Re: [gentoo-dev] [PATCH] pym/portage/news.py: let slackers copy+paste the news read command

[Jason Zaman]

On Thu, Jan 29, 2015 at 11:00:21PM -0800, Zac Medico wrote:
  -   print(Use  + colorize(GOOD, eselect news) +  to read 
  news items.)
  +   print(Use  + colorize(GOOD, eselect news read new) +  to 
  read new items.)
 
 I guess that's fine, but I have to wonder how many people are really
 that lazy. To me, it actually seems like more effort to highlight the
 span of characters with the mouse than it does to type them out.

People are. I do recall some time ago someone asked me what the full
command was and why it wasnt just printed like the @preserved-rebuild
message.
 
 Also, when the work read appears twice on a short line like that, it
 gives a wordy/redundant feeling.

Perhaps better would be 'eselect news read' to view new items? ie.
view instead of the second read.

-- Jason

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Jason Zaman]

On Mon, Jan 19, 2015 at 08:31:45PM +0100, Michał Górny wrote:
 Hello,
 
 As we've discussed multiple times, the following kind of dependencies
 is completely broken and can't work:
 
   || ( media-libs/libav:= media-libs/ffmpeg:= )
 
 For this reason, I would like to employ the solution used by Exherbo.
 More specifically, use:
 
   libav? ( media-libs/libav:= )
   !libav? ( media-libs/ffmpeg:= )

Is this going to be wrapped in a ffmpeg ? ( ) block?
What happens if I want libav and not ffmpeg and i set -ffmpeg libav in
make.conf? Does that mean I get nothing? cuz that is pretty
un-intuitive.

-- Jason

Re: [gentoo-dev] overlays.g.o status

[Jason Zaman]

On Mon, Dec 01, 2014 at 12:52:49PM +0100, viv...@gmail.com wrote:
 hi,
   what's the status of o.g.o?
 
 May I offer an lxc container?
 
 Regards,
 Francesco Riosa
 
 
 http://infra-status.gentoo.org/
 
 The CVS and Git Overlays services have been successfully migrated to the
 new hosts.
 
 Update (2014-09-19):
 
 At this point there's still no ETA to resume the gitweb and http access.
 We're waiting on systems from a new sponsor to host these services.

The machine has arived and is being installed and migrated. The current
issues are converting the commit hooks from gitolite v2 to gitolite v3
so that it can be upgraded properly.

-- Jason

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-08-10 23h59 UTC

[Jason Zaman]

On Tue, Aug 12, 2014 at 11:55:51AM +0400, Sergey Popov wrote:
 11.08.2014 04:25, Robin H. Johnson пишет:
  The attached list notes all of the packages that were added or removed
  from the tree, for the week ending 2014-08-10 23h59 UTC.
  
  Removals:
  dev-vcs/gitosis 2014-08-04 04:35:46 robbat2
  dev-vcs/gitosis-gentoo  2014-08-04 04:35:46 robbat2
 
 
 What's about sec-policy/selinux-gitosis ? Should it be removed too?

No, the selinux-gitosis policy has labels for gitolite too. It could
perhaps be renamed eventually but not removed.

-- Jason