[gentoo-dev] Packages up for grabs

[Manuel Rüger]

Due to lack of time, dropping myself from these packages:

These are in need of a new maintainer:
app-admin/go-updater
app-admin/kube-bench
app-admin/linux-bench
app-emulation/cri-tools
app-metrics/prom2json
app-shells/zsh-completions
dev-python/docker-py
dev-go/goversion
net-misc/istioctl
sys-cluster/kube-proxy


These have a maintainer:
app-admin/helm
sys-cluster/kubeadm
dev-python/prometheus_client
app-metrics/prometheus
dev-util/promu
app-metrics/alertmanager
sys-process/tini
app-emulation/reg
app-emulation/docker-proxy
app-admin/docker-bench
www-apps/grafana-bin
app-emulation/img
app-metrics/burrow_exporter
app-metrics/blackbox_exporter
app-emulation/flannel
app-metrics/node_exporter
app-metrics/pushgateway
app-emulation/cadvisor
app-metrics/snmp_exporter
app-metrics/elasticsearch_exporter
sys-auth/docker_auth
dev-util/drone
dev-util/drone-cli
sys-cluster/minikube


Thanks,
Manuel

[gentoo-dev] Packages up for grabs

[Manuel Rüger]

Hi,

it looks like parts of the Gentoo project and I don't share the same
values anymore.
Therefore, I currently don't know if I want to continue contributing and
am looking for new maintainers for the following packages:

app-admin/docker-bench
app-admin/dxf
app-admin/go-updater
app-admin/helm
app-admin/ksonnet
app-admin/kube-bench
app-admin/kubectx
app-admin/su-exec
app-crypt/cfssl
app-emulation/cadvisor
app-emulation/containerd
app-emulation/docker-compose
app-emulation/docker-proxy
app-emulation/docker-runc
app-emulation/docker
app-emulation/flannel
app-emulation/hyperstart
app-emulation/img
app-emulation/kompose
app-emulation/reg
app-emulation/runc
app-metrics/alertmanager
app-metrics/bind_exporter
app-metrics/blackbox_exporter
app-metrics/buildbot-prometheus
app-metrics/burrow_exporter
app-metrics/elasticsearch_exporter
app-metrics/mongodb_exporter
app-metrics/nginx-vts-exporter
app-metrics/node_exporter
app-metrics/openvpn_exporter
app-metrics/postfix_exporter
app-metrics/postgres_exporter
app-metrics/prom2json
app-metrics/prometheus
app-metrics/pushgateway
app-metrics/snmp_exporter
app-misc/ckb
app-misc/faq
app-misc/go-jira
app-misc/mkcert
app-misc/notary
app-shells/zsh-completions
dev-db/etcd
dev-go/go-bindata-assetfs
dev-go/go-bindata
dev-go/gogo-protobuf
dev-go/goversion
dev-go/gox
dev-haskell/language-docker
dev-python/docker-py
dev-python/prometheus_client
dev-python/pycobertura
dev-python/python-consul
dev-util/clair
dev-util/drone-cli
dev-util/drone
dev-util/hadolint
dev-util/promu
net-dns/coredns
net-fs/docker-volume-netshare
net-fs/mc
net-fs/minio
net-misc/calico-cni-plugin
net-misc/calicoctl
net-misc/cni-plugins
net-misc/felix
net-misc/networkmanager-wireguard
sys-auth/docker_auth
sys-cluster/kube-apiserver
sys-cluster/kube-controller-manager
sys-cluster/kube-proxy
sys-cluster/kube-scheduler
sys-cluster/kubectl
sys-cluster/kubelet
sys-cluster/minikube
sys-cluster/zetcd
sys-process/tini
www-apps/gitea
www-servers/caddy

If some of them are already have another maintainer than me, please talk
to them first before picking the package up.

Thanks,
Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address

[Manuel Rüger]

On 09.07.2018 10:40, Michał Górny wrote:
> Hi,
> 
> We currently don't enforce any particular standard for e-mail addresses
> for developers committing to gentoo.git.  FWICS, the majority of
> developers is using their @gentoo.org e-mail addresses.  However, a few
> developers are using some other addresses.
> 
> Using n...@gentoo.org e-mail addresses generally causes problems
> in accounting for commits.  For example, our retirement scripts can't
> detect commits made using non-Gentoo e-mail address.  My dev-timeline
> scripts [1] account for all emails in LDAP (which doesn't cover all
> addresses developers use).  FWIK gkeys accounts for all addresses
> in the OpenPGP key UIDs.  In my opinion, that's a lot of hoops to jump
> through to workaround bad practice.
> 
> Therefore, I'd like to start enforcing (at the level of the hook
> verifying signatures) that all commits made to gentoo.git (and other
> repositories requiring dev signatures) are made using @gentoo.org e-mail 
> address (for committer field).
> 
> Is anyone opposed to that?  Does anyone know of a valid reason to use
> n...@gentoo.org address when committing?
> 
> [1]:https://dev.gentoo.org/~mgorny/dev-timeline.html
> 

Hi Michał,

just to be clear on the wording, are you talking about the author email
of a git commit (authorship) or the comitter email to the upstream git
repository (committer)?

Thanks,
Manuel

[gentoo-dev] Packages / Project up for grabs

[Manuel Rüger]

Hi,

as I want to keep my work on Gentoo focussed, the following packages are
up for grabs as I don't use them:

app-admin/certmgr
app-emulation/hyperd
app-emulation/runv
dev-haskell/pgp-wordlist
dev-haskell/parser-combinators
dev-haskell/prettyprinter
dev-libs/onigmo
dev-python/grafanalib
dev-util/goland
dev-util/uftrace
net-misc/casync
sys-apps/habitat


In addition, I left the lxqt project, which now is empty. Feel free to
join or dissolve it.


Thanks,
Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v2 10/11] glep-0063: Require renewal 2 weeks before expiration

[Manuel Rüger]

I disagree with adding this as a requirement.

Services should explicitly fail to work with expired GPG keys, key
renewal times should be at the key owner's descretion.
This should still be a recommendation that guarantees the key owner to
continue work without interruption.


Thanks,
Manuel

On 04.07.2018 12:24, Michał Górny wrote:
> Add a rule requesting renewal of keys at least two weeks before their
> expiration date, in order to give services time to refresh.
> ---
>  glep-0063.rst | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/glep-0063.rst b/glep-0063.rst
> index 7455674..6874b81 100644
> --- a/glep-0063.rst
> +++ b/glep-0063.rst
> @@ -32,6 +32,10 @@ v2
>specification. Changing the expiration date of existing keys is possible
>in-place so there is no need to provide for transitional 'minimum' value.
>  
> +  An additional rule requesting key renewal 2 weeks before expiration
> +  has been added. This is in order to give services and other developers time
> +  to refresh the key.
> +
>  v1.1
>The recommended RSA key size has been changed from 4096 bits
>to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
> @@ -82,7 +86,10 @@ not be used to commit.
>  
> b. Gentoo subkey: 1 year maximum
>  
> -4. Upload your key to the SKS keyserver rotation before usage!
> +4. Key expiration date renewed at least 2 weeks before the previous
> +   expiration date.
> +
> +5. Upload your key to the SKS keyserver rotation before usage!
>  
>  Recommendations
>  ---
> 




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Packages up for grab

[Manuel Rüger]

Dear all,

the following packages are looking for a new maintainer, I have no use
for them anymore:

dev-util/docker-ls
sys-process/ctop


Thanks,
Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

[Manuel Rüger]

On 22.03.2018 01:25, Zac Medico wrote:
> On 03/19/2018 09:49 PM, Manuel Rüger wrote:
>> Hi Zac,
>>
>> alternatively could --exclude be extended to support sets?
>> So users could --exclude @world or @profile.
> 
> Your idea doesn't really fit the current meaning of --exclude, since
> --exclude excludes packages from being merged, but still adds installed
> instances to the dependency graph in order to ensure that their
> dependencies remain satisfied.
> 
Thanks for providing the clarification, now I have a better
understanding what both approaches do and withdraw my suggestion for
this patch. :-)

> I'd question the usefulness of a finer-grained approach that you're
> suggesting. I don't foresee people wanting to fiddle around with which
> package sets they want to ignore, and I wouldn't encourage them to do so.
> 
> The intention of the --ignore-world option is to say, "I only care about
> the packages that I'm specifying in the emerge arguments, do anything
> necessary to install them." In this sort of situation, I think a person
> generally wants to ignore everything except the given packages and their
> dependencies, because they don't want to do a bunch of fiddling to
> figure out which sets they'd need to exclude in order to avoid
> conflicts. If they want to fiddle with something, they are free to
> adjust their package set configuration, so why wouldn't they?
> 
> Anyway, I'm not necessarily opposed to adding a finer grained
> --ignore-set option. However, it would be more work, it would be more
> complex, and I wouldn't advise anyone to use it.
> 
> If people want to automate something in a disposable system, or they're
> in a position to use --ask and check the result for sanity, then I think
> --ignore-world is a good solution.
> 
> If people want something that's safe to use on a production system, then
> I'll advise them to manually adjust their package set configuration.
> 



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] New category: app-metrics

[Manuel Rüger]

Hi everyone,

I'm planning to add a new category app-metrics, which is mainly (at
least for my own use case) going to be used for prometheus[0] and its
exporters providing endpoints for prometheus. It can be used for other
packages whose _main_ purpose is to provide metrics, transform or
consume them.

* net-analyzer/prometheus
* app-admin/bind_exporter
* app-admin/elasticsearch_exporter
* app-admin/mongodb_exporter
* app-admin/nginx-vts-exporter
* app-admin/prom2json
* dev-util/buildbot-prometheus

In addition, the following packages will drop their prometheus- prefix
during the package move:

* net-analyzer/prometheus-blackbox_exporter
* net-analyzer/prometheus-node_exporter
* net-analyzer/prometheus-redis_exporter
* net-analyzer/prometheus-snmp_exporter
* net-analyzer/prometheus-uwsgi_exporter
* net-analyzer/prometheus-pushgateway
* net-analyzer/prometheus-alertmanager

With the growing adoption of prometheus I expect more exporters to be
added (I have five more that I want to add in the near future).


Thanks,

Manuel

[0] https://prometheus.io




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

[Manuel Rüger]

Hi Zac,

alternatively could --exclude be extended to support sets?
So users could --exclude @world or @profile.

Cheers,
Manuel

On 22.03.2018 00:03, Zac Medico wrote:
> Ignore the @world package set and its dependencies. This may be useful
> if there is a desire to perform an action even though it might break
> the dependencies of some installed packages (it might also remove
> installed packages in order to solve blockers). This also alters the
> behavior of --complete-graph options so that only deep dependencies
> of packages given as arguments are included in the dependency graph.
> This option may be useful as an alternative to --nodeps in cases where
> it is desirable to account for dependencies of packages given as
> arguments.
> 
> Bug: https://bugs.gentoo.org/608564
> ---
>  man/emerge.1  | 17 +
>  pym/_emerge/create_depgraph_params.py |  4 
>  pym/_emerge/depgraph.py   |  8 ++--
>  pym/_emerge/main.py   |  9 +
>  pym/portage/tests/resolver/test_complete_graph.py | 18 ++
>  5 files changed, 54 insertions(+), 2 deletions(-)
> 
> diff --git a/man/emerge.1 b/man/emerge.1
> index a17b65ed2..01ce62e51 100644
> --- a/man/emerge.1
> +++ b/man/emerge.1
> @@ -630,6 +630,23 @@ Therefore, \fB\-\-usepkgonly\fR (or 
> \fB\-\-getbinpkgonly\fR) must be
>  used in order to enable soname depedency resolution when installing
>  packages.
>  .TP
> +.BR "\-\-ignore\-world [ y | n ]"
> +Ignore the @world package set and its dependencies. This may be useful
> +if there is a desire to perform an action even though it might break
> +the dependencies of some installed packages (it might also remove
> +installed packages in order to solve blockers). This also alters the
> +behavior of \fB\-\-complete\-graph\fR options so that only deep
> +dependencies of packages given as arguments are included in the
> +dependency graph. This option may be useful as an alternative to
> +\fB\-\-nodeps\fR in cases where it is desirable to account for
> +dependencies of packages given as arguments.
> +
> +\fBWARNING:\fR
> +This option is intended to be used only with great caution, since it is
> +possible for it to make nonsensical changes which may lead to system
> +breakage. Therefore, it is advisable to use \fB\-\-ask\fR together with
> +this option.
> +.TP
>  .BR \-j\ [JOBS] ", "  \-\-jobs[=JOBS]
>  Specifies the number of packages to build simultaneously. If this option is
>  given without an argument, emerge will not limit the number of jobs that can
> diff --git a/pym/_emerge/create_depgraph_params.py 
> b/pym/_emerge/create_depgraph_params.py
> index fc7fa60d7..0405011fd 100644
> --- a/pym/_emerge/create_depgraph_params.py
> +++ b/pym/_emerge/create_depgraph_params.py
> @@ -26,6 +26,7 @@ def create_depgraph_params(myopts, myaction):
>   # ignore_soname_deps: ignore the soname dependencies of built
>   #   packages, so that they do not trigger dependency resolution
>   #   failures, or cause packages to be rebuilt or replaced.
> + # ignore_world: ignore the @world package set and its dependencies
>   # with_test_deps: pull in test deps for packages matched by arguments
>   # changed_deps: rebuild installed packages with outdated deps
>   # changed_deps_report: report installed packages with outdated deps
> @@ -56,6 +57,9 @@ def create_depgraph_params(myopts, myaction):
>   myparams["selective"] = True
>   return myparams
>  
> + if myopts.get('--ignore-world') is True:
> + myparams['ignore_world'] = True
> +
>   rebuild_if_new_slot = myopts.get('--rebuild-if-new-slot')
>   if rebuild_if_new_slot is not None:
>   myparams['rebuild_if_new_slot'] = rebuild_if_new_slot
> diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
> index 6c728684f..f7ea27c37 100644
> --- a/pym/_emerge/depgraph.py
> +++ b/pym/_emerge/depgraph.py
> @@ -163,7 +163,10 @@ class _frozen_depgraph_config(object):
>   self.trees[myroot]["bintree"] = DummyTree(
>   
> DbapiProvidesIndex(trees[myroot]["bintree"].dbapi))
>  
> - self._required_set_names = set(["world"])
> + if params.get("ignore_world", False):
> + self._required_set_names = set()
> + else:
> + self._required_set_names = set(["world"])
>  
>   atoms = ' '.join(myopts.get("--exclude", [])).split()
>   self.excluded_pkgs = _wildcard_set(atoms)
> @@ -7554,6 +7557,7 @@ class depgraph(object):
>   ignored_uninstall_tasks = set()
>   have_uninstall_task = False
>   complete = "complete" in self._dynamic_config.myparams
> + ignore_world = 
> self._dynamic_config.myparams.get("ignore_world", False)
>   asap_nodes = []
>  
>   def 

[gentoo-dev] Packages up for grabs

[Manuel Rüger]

Packages up for grabs:

* app-crypt/yubikey-manager-qt
* sys-apps/etckeeper
* sys-auth/yubico-piv-tool
* dev-libs/libsodium
* app-editors/retext
* sys-apps/rkflashtool
* dev-embedded/esptool
* app-shells/thefuck
* app-crypt/paperkey
* dev-util/bumpversion
* dev-python/python-afl
* dev-python/pyotherside
* dev-util/docker-distribution-pruner



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] [PATCH] dev-util/shadowman: Unified tool to update ccache/distcc/icecc shadow dir

[Manuel Rüger]

On 19.08.2017 12:53, Michał Górny wrote:
> Dnia 19 sierpnia 2017 12:19:18 CEST, "Manuel Rüger" <mr...@gentoo.org> 
> napisał(a):
>> On 17.08.2017 10:36, Michał Górny wrote:
>>> Hi, everyone.
>>>
>>> I've written a new tool called shadowman [1] that aims to partially
>>> replace the current *-config tools shipped with ccache, distcc, icecc
>>> and potentially more.
>>>
>>> Why? Because the existing tools are inconsistent, inconvenient
>>> and usually incomplete. The README [2] states a number of advantages:
>>>
>>> | 1. one usage syntax that works for all tools,
>>> |
>>> | 2. ability to update/clean masquerades for multiple tools in one
>> call,
>>> |
>>> | 3. consistent (and *good*) implementation -- now all tools get the
>> same
>>> | executable list,
>>> |
>>> | 4. reduced code duplication,
>>> |
>>> | 5. modular layout that allows adding extra tools/compiler wildcards
>>> | by third-party packages.
>>>
>>> This thread includes patches that:
>>>
>>> a. add the package for shadowman (skipping some bundled modules for
>>> external inclusion) -- for testing it's just a live ebuild with full
>>> keyword set; I will obviously change that before the final inclusion;
>>>
>>> b. adds shadowman support to ccache, distcc & icecream packages
>>> (preserving the old utilities for compatibility),
>>>
>>> c. adds shadowman update call to toolchain.eclass & clang ebuilds
>>> so that the masquerades get updated automatically on gcc/clang
>> upgrade.
>>>
>>> Please review. Alternatively available as PR on GitHub [3].
>>>
>>> [1]:https://github.com/mgorny/shadowman
>>> [2]:https://github.com/mgorny/shadowman/blob/master/README
>>> [3]:https://github.com/gentoo/gentoo/pull/5386
>>>
>>>
>> Have you considered moving it under the gentoo umbrella (e.g., mirror
>> it
>> on git.gentoo.org or move it to the gentoo organisation)?
> 
> No, I'm not interested in giving away credit to my personal work which I'm 
> personally maintaining.
> 
Why do you consider it to "give away credit" when it's under
github.org/gentoo/ or on git.gentoo.org? You'll still be author of the
commits.

>>
>> Thanks,
>> Manuel
> 
> 

Re: [gentoo-dev] [RFC] [PATCH] dev-util/shadowman: Unified tool to update ccache/distcc/icecc shadow dir

[Manuel Rüger]

On 17.08.2017 10:36, Michał Górny wrote:
> Hi, everyone.
> 
> I've written a new tool called shadowman [1] that aims to partially
> replace the current *-config tools shipped with ccache, distcc, icecc
> and potentially more.
> 
> Why? Because the existing tools are inconsistent, inconvenient
> and usually incomplete. The README [2] states a number of advantages:
> 
> | 1. one usage syntax that works for all tools,
> |
> | 2. ability to update/clean masquerades for multiple tools in one call,
> |
> | 3. consistent (and *good*) implementation -- now all tools get the same
> | executable list,
> |
> | 4. reduced code duplication,
> |
> | 5. modular layout that allows adding extra tools/compiler wildcards
> | by third-party packages.
> 
> This thread includes patches that:
> 
> a. add the package for shadowman (skipping some bundled modules for
> external inclusion) -- for testing it's just a live ebuild with full
> keyword set; I will obviously change that before the final inclusion;
> 
> b. adds shadowman support to ccache, distcc & icecream packages
> (preserving the old utilities for compatibility),
> 
> c. adds shadowman update call to toolchain.eclass & clang ebuilds
> so that the masquerades get updated automatically on gcc/clang upgrade.
> 
> Please review. Alternatively available as PR on GitHub [3].
> 
> [1]:https://github.com/mgorny/shadowman
> [2]:https://github.com/mgorny/shadowman/blob/master/README
> [3]:https://github.com/gentoo/gentoo/pull/5386
> 
> 
Have you considered moving it under the gentoo umbrella (e.g., mirror it
on git.gentoo.org or move it to the gentoo organisation)?

Thanks,
Manuel

Re: [gentoo-portage-dev] [PATCH v2] Support different compressors for binary packages

[Manuel Rüger]

Pushed as:
https://gitweb.gentoo.org/proj/portage.git/commit/?id=cff2c0149142843316e1851c2e73bcec30f08471

Thanks for the patient reviews, Zac!

Cheers,
Manuel

On 28.07.2017 18:24, Zac Medico wrote:
> The patch is looking really good now. Thanks for working on this!
> 
> On Fri, Jul 28, 2017 at 2:59 AM, Manuel Rüger <mr...@gentoo.org> wrote:
>> @@ -518,6 +526,26 @@ def doebuild_environment(myebuild, mydo, myroot=None, 
>> settings=None,
>> mysettings["KV"] = ""
>> mysettings.backup_changes("KV")
>>
>> +   binpkg_compression = mysettings.get("BINPKG_COMPRESSION", 
>> "bzip2")
>> +   try:
>> +   compression = _compressors[binpkg_compression]
>> +   except KeyError as e:
>> +   writemsg("Warning: Invalid or unsupported 
>> compression method: %s" % e.args[0])
>> +   else:
>> +   try:
>> +   compression_binary = 
>> shlex_split(varexpand(compression["compress"], mydict=settings))[0]
>> +   except IndexError as e:
>> +   writemsg("Warning: Invalid or unsupported 
>> compression method: %s" % e.args[0])
>> +   else:
>> +   if find_binary(compression_binary) is None:
>> +   missing_package = 
>> compression["package"]
>> +   writemsg("Warning: File compression 
>> unsupported %s. Missing package: %s" % (binpkg_compression, missing_package))
> 
> It's going to be very helpful if we add some code to detect this case
> in emerge's action_build function, and exit unsuccessfully if the
> global BINPKG_COMPRESSION setting is invalid or the required package
> is missing. This will ensure that people don't build a bunch of binary
> packages, only to find out later that their BINPKG_COMPRESSION setting
> was ineffective.
> 




signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH v2] Support different compressors for binary packages

[Manuel Rüger]

This patch allows to set the compressor for binary packages via a
BINPKG_COMPRESSION variable. BINPKG_COMPRESSION_ARGS allows to specify
command-line arguments for the chosen compressor.
---
 bin/misc-functions.sh  |  6 ++-
 bin/quickpkg   | 62 --
 man/make.conf.5| 25 +
 pym/_emerge/BinpkgExtractorAsync.py| 43 +--
 pym/portage/dbapi/bintree.py   |  8 +--
 .../package/ebuild/_config/special_env_vars.py |  2 +-
 pym/portage/package/ebuild/doebuild.py | 34 ++--
 pym/portage/util/compression_probe.py  | 45 +---
 8 files changed, 186 insertions(+), 39 deletions(-)

diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index 58755a1e1..079369313 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -453,7 +453,7 @@ __dyn_package() {
# Make sure $PWD is not ${D} so that we don't leave gmon.out files
# in there in case any tools were built with -pg in CFLAGS.
 
-   cd "${T}"
+   cd "${T}" || die
 
if [[ -n ${PKG_INSTALL_MASK} ]] ; then
PROOT=${T}/packaging/
@@ -478,8 +478,10 @@ __dyn_package() {
[ -z "${PORTAGE_BINPKG_TMPFILE}" ] && \
die "PORTAGE_BINPKG_TMPFILE is unset"
mkdir -p "${PORTAGE_BINPKG_TMPFILE%/*}" || die "mkdir failed"
+   [ -z "${PORTAGE_COMPRESSION_COMMAND}" ] && \
+die "PORTAGE_COMPRESSION_COMMAND is unset"
tar $tar_options -cf - $PORTAGE_BINPKG_TAR_OPTS -C "${PROOT}" . | \
-   $PORTAGE_BZIP2_COMMAND -c > "$PORTAGE_BINPKG_TMPFILE"
+   $PORTAGE_COMPRESSION_COMMAND -c > "$PORTAGE_BINPKG_TMPFILE"
assert "failed to pack binary package: '$PORTAGE_BINPKG_TMPFILE'"
PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}} \
"${PORTAGE_PYTHON:-/usr/bin/python}" 
"$PORTAGE_BIN_PATH"/xpak-helper.py recompose \
diff --git a/bin/quickpkg b/bin/quickpkg
index 4f26ee912..750400592 100755
--- a/bin/quickpkg
+++ b/bin/quickpkg
@@ -8,6 +8,7 @@ import argparse
 import errno
 import math
 import signal
+import subprocess
 import sys
 import tarfile
 
@@ -22,11 +23,13 @@ from portage.dbapi.dep_expand import dep_expand
 from portage.dep import Atom, use_reduce
 from portage.exception import (AmbiguousPackageName, InvalidAtom, InvalidData,
InvalidDependString, PackageSetNotFound, PermissionDenied)
-from portage.util import ConfigProtect, ensure_dirs, shlex_split, _xattr
+from portage.util import ConfigProtect, ensure_dirs, shlex_split, varexpand, 
_xattr
 xattr = _xattr.xattr
 from portage.dbapi.vartree import dblink, tar_contents
 from portage.checksum import perform_md5
 from portage._sets import load_default_config, SETPREFIX
+from portage.process import find_binary
+from portage.util.compression_probe import _compressors
 
 def quickpkg_atom(options, infos, arg, eout):
settings = portage.settings
@@ -50,16 +53,16 @@ def quickpkg_atom(options, infos, arg, eout):
" ".join(e.args[0]))
del e
infos["missing"].append(arg)
-   return
+   return 1
except (InvalidAtom, InvalidData):
eout.eerror("Invalid atom: %s" % (arg,))
infos["missing"].append(arg)
-   return
+   return 1
if atom[:1] == '=' and arg[:1] != '=':
# dep_expand() allows missing '=' but it's really invalid
eout.eerror("Invalid atom: %s" % (arg,))
infos["missing"].append(arg)
-   return
+   return 1
 
matches = vardb.match(atom)
pkgs_for_arg = 0
@@ -108,16 +111,16 @@ def quickpkg_atom(options, infos, arg, eout):
in settings.features))
def protect(filename):
if not confprot.isprotected(filename):
-   return False
+   return 1
if include_unmodified_config:
file_data = contents[filename]
if file_data[0] == "obj":
orig_md5 = 
file_data[2].lower()
cur_md5 = 
perform_md5(filename, calc_prelink=1)
if orig_md5 == cur_md5:
-   return False
+   return 1
excluded_config_files.append(filename)
-   return True
+   

[gentoo-dev] Package up for grabs

[Manuel Rüger]

The following packages are up for grabs:

app-admin/gixy
app-admin/mei-amt-check
app-admin/ngxtop
app-admin/passwordsafe
app-arch/lz5
app-crypt/acme
app-crypt/certbot
app-crypt/certbot-apache
app-crypt/certbot-nginx
app-crypt/easy-rsa
app-crypt/libmd
app-crypt/manuale
app-crypt/pgpdump
app-emulation/docker-gc
app-misc/jira-cli
app-misc/pdfpc
app-text/blahtexml
app-text/itex2mml
app-text/mathtex
dev-go/cli
dev-go/delve
dev-go/go-gitlab-client
dev-go/glide
dev-go/toml
dev-python/parsley
dev-python/safety
dev-python/txsocksx
dev-python/vcversioner
dev-libs/libgit2
dev-lua/luadbi
dev-lua/luasocket
dev-lua/lua-zlib
dev-util/bloaty
dev-util/cookiecutter
net-analyzer/linkchecker
net-libs/libssh2
net-misc/kafkacat
x11-misc/flow-pomodoro
x11-plugins/pidgin-opensteamworks
x11-plugins/pidgin-xmpp-receipts

There is another set of packages, which have a backup project
maintaining it. Please talk to the respective project if you're
interested in maintaining those:

app-office/texstudio
dev-python/cookies
dev-python/freezegun
dev-python/future
dev-python/hiro
dev-python/hvac
dev-python/parsedatetime
dev-python/parsley
dev-python/pyhcl
dev-python/pykka
dev-python/pyrfc3339
dev-python/pytest-capturelog
dev-python/pytest-localserver
dev-python/responses
dev-python/vcrpy
dev-python/zope-component
dev-python/zope-event
net-firewall/nftables
net-libs/libnftnl

Best regards,
Manuel Rüger




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] Leader election

[Manuel Rüger]

Voting for Zac as well

Am 9. Juli 2017 23:33:07 MESZ schrieb "Michał Górny" :
>On wto, 2017-07-04 at 13:02 -0700, Zac Medico wrote:
>> On 07/02/2017 12:02 PM, Brian Dolbec wrote:
>> > On Sun, 2 Jul 2017 11:28:09 -0700
>> > Brian Dolbec  wrote:
>> > 
>> > > On Sat, 24 Jun 2017 20:20:16 -0700
>> > > Brian Dolbec  wrote:
>> > > > On Sun, 18 Jun 2017 15:48:44 +0200
>> > > > Alexander Berntsen  wrote:
>> > > >   
>> > > > > Friends,
>> > > > > 
>> > > > > It's that time of year. We're having a leader election again,
>as
>> > > > > well as a general development meeting. The agenda will be
>updated
>> > > > > in more detail at:
>> > > > > https://wiki.gentoo.org/wiki/Project:Portage/Meetings
>> > > > > 
>> > > > > Please schedule a time at: http://whenisgood.net/portage
>> > > > > 
>> > > > > Thanks.
>> > > > > - -- 
>> > > > > Alexander
>> > > > > berna...@gentoo.org
>> > > > > https://secure.plaimi.net/~alexander
>> > > > >
>> > > > 
>> > > > I've picked Sunday, July 2 at 4:00 PM UTC
>> > > >   
>> > > We've decided (the members in attendance), to do the lead
>election via
>> > > email.
>> > > So, nominations are open from now to July 5, 2017.
>> > > Voting will be closed July 10, 2017, results posted here again.
>> > > - -- 
>> > > Brian Dolbec 
>> > 
>> > 
>> > I nominate Zac 
>> 
>> Thank you, I accept.
>> 
>> I also nominate Brian Dolbec and Alexander Berntsen.
>
>My vote goes for Zac as well.
>-- 
>Best regards,
>Michał Górny

Re: [gentoo-portage-dev] [PATCH] Support different (de)compressors for binary packages

[Manuel Rüger]

On 04.07.2017 21:29, Zac Medico wrote:
> On Fri, Jun 30, 2017 at 2:49 AM, Manuel Rüger <mr...@gentoo.org> wrote:
>> +
>> COMPRESSION_COMMAND=$(PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}}
>> \
>> +   "${PORTAGE_PYTHON:-/usr/bin/python}"
>> "$PORTAGE_BIN_PATH"/binpkg-helper.py \
>> +   compressioncmd ${CATEGORY}/${P})
>> +   [ -z "${COMPRESSION_COMMAND}" ] && \
>> +   die "Failed to get COMPRESSION_COMMAND"
>> tar $tar_options -cf - $PORTAGE_BINPKG_TAR_OPTS -C "${PROOT}" . | \
>> -   $PORTAGE_BZIP2_COMMAND -c > "$PORTAGE_BINPKG_TMPFILE"
>> +   $COMPRESSION_COMMAND -c > "$PORTAGE_BINPKG_TMPFILE"
>> assert "failed to pack binary package: '$PORTAGE_BINPKG_TMPFILE'"
>> PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}} \
>> "${PORTAGE_PYTHON:-/usr/bin/python}"
> 
> If all that we really need is COMPRESSION_COMMAND, then the helper
> script is overkill. We should just pass a variable from
> doebuild_environment function. The variable name must be prefixed with
> PORTAGE_.
> 
> Also, note that your mail client wrapped lines in this patch.
> 

Thanks for the review Zac!

We'd need a bit more as the COMPRESSION_COMMAND depends on
${CATEGORY}/${P} here in order to avoid a catch22 when using a
decompressor that is set to something a standard install doesn't include.

Assume all binpkgs are set to be compressed with zstd, the patch makes
sure an app-arch/zstd binpkg will still be compressed with bzip2.

Mails were sent with Thunderbird, I'll set up git send-mail next time.



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH] Support different (de)compressors for binary packages

[Manuel Rüger]

This patch allows to set the compressor for binary packages via a
BINPKG_COMPRESSION variable. BINPKG_COMPRESSION_ARGS allows to specify
command-line arguments for that compressor.

---
 bin/binpkg-helper.py  | 91
+++
 bin/misc-functions.sh |  9 +++-
 bin/quickpkg  | 67 +++---
 man/make.conf.5   | 25 ++
 pym/_emerge/BinpkgExtractorAsync.py   | 43 +++--
 pym/portage/dbapi/bintree.py  |  8 +--
 pym/portage/util/compression_probe.py | 45 ++---
 7 files changed, 253 insertions(+), 35 deletions(-)
 create mode 100755 bin/binpkg-helper.py

diff --git a/bin/binpkg-helper.py b/bin/binpkg-helper.py
new file mode 100755
index 0..b603747cf
--- /dev/null
+++ b/bin/binpkg-helper.py
@@ -0,0 +1,91 @@
+#!/usr/bin/python -b
+# Copyright 2009-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+import argparse
+import sys
+
+import portage
+portage._internal_caller = True
+from portage import os
+from portage import cpv_getkey
+from portage.process import find_binary
+from portage.util import (
+   shlex_split,
+   varexpand,
+   )
+from portage.util.compression_probe import _compressors
+
+def command_compressioncmd(args):
+   settings = portage.settings
+   usage = "usage: compressioncmd ${CATEGORY}/${P}\n"
+
+   if len(args) != 1:
+   sys.stderr.write(usage)
+   sys.stderr.write("One argument is required, got %s\n" % 
len(args))
+   return 1
+
+   cpv = args[0]
+   binpkg_compression = settings.get("BINPKG_COMPRESSION", "bzip2")
+   try:
+   compression = _compressors[binpkg_compression]
+   except KeyError as e:
+   sys.stderr.write("Invalid or unsupported compression method: 
%s" %
e.args[0])
+   return 1
+   # Fallback to bzip2 for the package providing the decompressor
+   # This solves bootstrapping a client without the decompressor
+
+   if cpv_getkey(cpv) is None:
+   sys.stderr.write("The argument must be in the 
${CATEGORY}/${PN}-${PV}
format. Provided argument was: %s\n" % cpv)
+   return 1
+
+   if cpv_getkey(cpv) == compression["package"]:
+   compression = _compressors["bzip2"]
+   try:
+   compression_binary = 
shlex_split(varexpand(compression["compress"],
mydict=settings))[0]
+   except IndexError as e:
+   sys.stderr.write("Invalid or unsupported compression method: 
%s" %
e.args[0])
+   return 1
+   if find_binary(compression_binary) is None:
+   missing_package = compression["package"]
+   sys.stderr.write("File compression unsupported %s. Missing 
package:
%s" % (binpkg_compression, missing_package))
+   return 1
+   cmd = [varexpand(x, mydict=settings) for x in
shlex_split(compression["compress"])]
+   # Filter empty elements
+   cmd = [x for x in cmd if x != ""]
+
+   print(' '.join(cmd))
+   return os.EX_OK
+
+def main(argv):
+
+   if argv and isinstance(argv[0], bytes):
+   for i, x in enumerate(argv):
+   argv[i] = portage._unicode_decode(x, errors='strict')
+
+   valid_commands = ('compressioncmd',)
+   description = "Returns the compression command"
+   usage = "usage: %s COMMAND [args]" % \
+   os.path.basename(argv[0])
+
+   parser = argparse.ArgumentParser(description=description, usage=usage)
+   options, args = parser.parse_known_args(argv[1:])
+
+   if not args:
+   parser.error("missing command argument")
+
+   command = args[0]
+
+   if command not in valid_commands:
+   parser.error("invalid command: '%s'" % command)
+
+   if command == 'compressioncmd':
+   rval = command_compressioncmd(args[1:])
+   else:
+   raise AssertionError("invalid command: '%s'" % command)
+
+   return rval
+
+if __name__ == "__main__":
+   rval = main(sys.argv[:])
+   sys.exit(rval)
diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index 58755a1e1..0ba0db226 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -453,7 +453,7 @@ __dyn_package() {
# Make sure $PWD is not ${D} so that we don't leave gmon.out files
# in there in case any tools were built with -pg in CFLAGS.

-   cd "${T}"
+   cd "${T}" || die

if [[ -n ${PKG_INSTALL_MASK} ]] ; then
PROOT=${T}/packaging/
@@ -478,8 +478,13 @@ __dyn_package() {
[ -z "${PORTAGE_BINPKG_TMPFILE}" ] && \
die "PORTAGE_BINPKG_TMPFILE is unset"
mkdir -p "${PORTAGE_BINPKG_TMPFILE%/*}" || die "mkdir failed"
+
COMPRESSION_COMMAND=$(PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}}
\
+   "${PORTAGE_PYTHON:-/usr/bin/python}"

[gentoo-portage-dev] [PATCH] emerge: Add head commit per repo to --info

[Manuel Rüger]

This adds the following to emerge --info output for git and rsync based
repositories:

Head commit of repository gentoo: 0518b330edac963f54f98df33391b8e7b9eaee4c
---
 pym/_emerge/actions.py | 10 ++
 pym/portage/sync/modules/git/__init__.py   |  3 ++-
 pym/portage/sync/modules/git/git.py| 12 
 pym/portage/sync/modules/rsync/__init__.py |  3 ++-
 pym/portage/sync/modules/rsync/rsync.py| 12 
 pym/portage/sync/syncbase.py   |  5 -
 6 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py
index c8a62fb01..3c6c265f7 100644
--- a/pym/_emerge/actions.py
+++ b/pym/_emerge/actions.py
@@ -1644,8 +1644,18 @@ def action_info(settings, trees, myopts, myfiles):

for repo in repos:
last_sync = portage.grabfile(os.path.join(repo.location, 
"metadata",
"timestamp.chk"))
+   head_commit = None
if last_sync:
append("Timestamp of repository %s: %s" % (repo.name, 
last_sync[0]))
+   if repo.sync_type:
+   sync = 
portage.sync.module_controller.get_class(repo.sync_type)()
+   options = { 'repo': repo }
+   try:
+   head_commit = 
sync.retrieve_head(options=options)
+   except NotImplementedError:
+   head_commit = (1, False)
+   if head_commit and head_commit[0] == os.EX_OK:
+   append("Head commit of repository %s: %s" % (repo.name, 
head_commit[1]))

# Searching contents for the /bin/sh provider is somewhat
# slow. Therefore, use the basename of the symlink target
diff --git a/pym/portage/sync/modules/git/__init__.py
b/pym/portage/sync/modules/git/__init__.py
index e7206e12d..2f1d35226 100644
--- a/pym/portage/sync/modules/git/__init__.py
+++ b/pym/portage/sync/modules/git/__init__.py
@@ -43,12 +43,13 @@ def _check_depth(self, attr):
'sourcefile': "git",
'class': "GitSync",
'description': doc,
-   'functions': ['sync', 'new', 'exists'],
+   'functions': ['sync', 'new', 'exists', 'retrieve_head'],
'func_desc': {
'sync': 'Performs a git pull on the repository',
'new': 'Creates the new repository at the 
specified location',
'exists': 'Returns a boolean of whether the 
specified dir ' +
'exists and is a valid Git repository',
+   'retrieve_head': 'Returns the head commit hash',
},
'validate_config': CheckGitConfig,
'module_specific_options': (
diff --git a/pym/portage/sync/modules/git/git.py
b/pym/portage/sync/modules/git/git.py
index bea79c7e7..8df9ca612 100644
--- a/pym/portage/sync/modules/git/git.py
+++ b/pym/portage/sync/modules/git/git.py
@@ -130,3 +130,15 @@ def update(self):
cwd=portage._unicode_encode(self.repo.location))

return (os.EX_OK, current_rev != previous_rev)
+
+   def retrieve_head(self, **kwargs):
+   '''Get information about the head commit'''
+   if kwargs:
+   self._kwargs(kwargs)
+   rev_cmd = [self.bin_command, "rev-list", "--max-count=1", 
"HEAD"]
+   try:
+   ret = (os.EX_OK, subprocess.check_output(rev_cmd,
+   
cwd=portage._unicode_encode(self.repo.location)))
+   except CalledProcessError:
+   ret = (1, False)
+   return ret
diff --git a/pym/portage/sync/modules/rsync/__init__.py
b/pym/portage/sync/modules/rsync/__init__.py
index 7ebb5476c..c2fdc4188 100644
--- a/pym/portage/sync/modules/rsync/__init__.py
+++ b/pym/portage/sync/modules/rsync/__init__.py
@@ -17,11 +17,12 @@
'sourcefile': "rsync",
'class': "RsyncSync",
'description': doc,
-   'functions': ['sync', 'new', 'exists'],
+   'functions': ['sync', 'new', 'exists', 'retrieve_head'],
'func_desc': {
'sync': 'Performs rsync transfers on the 
repository',
'new': 'Creates the new repository at the 
specified location',
'exists': 'Returns a boolean if the specified 
directory exists',
+   'retrieve_head': 'Returns the head commit based 
on
metadata/timestamp.commit',
},
'validate_config': CheckSyncConfig,
'module_specific_options': (
diff --git 

[gentoo-dev] Packages up for grabs

[Manuel Rüger]

Hi,

I have no use for those packages anymore.
Feel free to add yourself as a (proxied) maintainer to:

dev-tex/biblatex
dev-tex/biblatex-apa
dev-tex/biber
dev-vcs/git-num
www-apps/jekyll
www-apps/jekyll-coffeescript
www-apps/jekyll-gist
www-apps/jekyll-paginate
www-apps/jekyll-sass-converter
www-apps/jekyll-sitemap
www-apps/jekyll-watch
www-servers/spawn-fcgi

Thanks,
Manuel

Re: [gentoo-dev] RFC: Userkit.eclass

[Manuel Rüger]

On 23.11.2016 10:08, Michał Górny wrote:
> On Wed, 23 Nov 2016 09:44:33 +0100
> Manuel Rüger <mr...@gentoo.org> wrote:
> 
>> I have not started to write it, but I am considering it and rather want
>> to gather feedback on my idea first.
>> I am aware that https://wiki.gentoo.org/wiki/GLEP:27 exists, but as of
>> right now I haven't seen anyone working on it. The goal of this eclass
>> is to improve user/group handling without touching the PMS.
>>
>> tl;dr: Userkit eclass will improve the user handling by externalizing
>> the configuration to variables that can be set from outside of the ebuild.
>>
>> Userkit.eclass will inherit user.eclass and require bash arrays
>> USERKIT_USER and USERKIT_GROUP for configuration.
>> I will export a pkg_setup with the corresponding setup (basically
>> calling enewuser and enewgroup). It will provide get_user, get_uid,
>> get_group, get_gid and get_home functions.
>> This would allow to do something like "fowners $(get_user):$(get_group)
>> foo".
>>
>> If ${CATEGORY}-${PN}_user and ${CATEGORY}-${PN}_group are set, these
>> will replace the contents of USERKIT_USER and USERKIT_GROUP, allowing
>> the user to fully define everything user/group related.
> 
> How does that all map to multiple users/groups? How does that map to
> USE-conditional users/groups? How does that map to users/groups shared
> between multiple packages?
> 
simply via calling the function conditional in pkg_setup
My goal is not to focus on handling multiple users/groups. Synchronizing
settings between multiple packages is a task of the user, it doesn't
make any sense to make guesses there. People will come up with wonderful
symlinked solutions.
> Besides, this sounds a lot like games.eclass... will developers be
> required to patch upstream software now to force support for using
> custom users/groups?
I am not aware of any patches that are required. What I care about is
having predictable uid/gid and home for everything I can configure via
an ebuild.

> 
>> What happens if the ebuild wants to create multiple users/group?
>> Currently, I want to ignore that case and focus on the 80% ebuilds that
>> can profit from such an eclass.
> 
> Do you have specific numbers? I don't see 80% of ebuilds caring about
> users/groups. I don't see the problem you are trying to fix.
> 
Okay let me rephrase that here: "probably more than 80% of the ebuilds
that are calling enewuser/enewgroup" install a single user or a single
group. There will be some cases this eclass is not applicable to, but
that is fine. If this is something we really want to coveras well using
the eclass based approach, we probably could start enumerating the
variable and if those available to what needs to be done. Something like
USERKIT_USER_2. Not sure if we want to do that.

> Is it one of those problems that someone thinks it's awesome to make
> everything declaratory, and add tons of middleware to make the
> declaratory work somehow for the most common use cases?
> 
I don't see "tons of middleware" here.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] RFC: Userkit.eclass

[Manuel Rüger]

Hi everyone,

I have not started to write it, but I am considering it and rather want
to gather feedback on my idea first.
I am aware that https://wiki.gentoo.org/wiki/GLEP:27 exists, but as of
right now I haven't seen anyone working on it. The goal of this eclass
is to improve user/group handling without touching the PMS.

tl;dr: Userkit eclass will improve the user handling by externalizing
the configuration to variables that can be set from outside of the ebuild.

Userkit.eclass will inherit user.eclass and require bash arrays
USERKIT_USER and USERKIT_GROUP for configuration.
I will export a pkg_setup with the corresponding setup (basically
calling enewuser and enewgroup). It will provide get_user, get_uid,
get_group, get_gid and get_home functions.
This would allow to do something like "fowners $(get_user):$(get_group)
foo".

If ${CATEGORY}-${PN}_user and ${CATEGORY}-${PN}_group are set, these
will replace the contents of USERKIT_USER and USERKIT_GROUP, allowing
the user to fully define everything user/group related.

It will also be possible to enable a switch to that makes the ebuild
fail if those are not set, as you then can set those variables first.
Another one allows to make them nops (which is nice for testing the
ebuild via "ebuild $PN test").

My only concerns right now are:
Where to store those ${CATEGORY}-${PN}_user and ${CATEGORY}-${PN}_group?
One solution could be to have another eclass named userkit-data.eclass,
which is empty by default and needs to be forked to an overlay and then
use the eclass-override setting in repos.conf. Unfortunately this will
cause a lot of md5-cache rewrites.
Another solution would be portage/package.env or portage/env.

What happens if the ebuild wants to create multiple users/group?
Currently, I want to ignore that case and focus on the 80% ebuilds that
can profit from such an eclass.

Any thoughts?

Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: net-print/foomatic-filters

[Manuel Rüger]

# Manuel Rüger <mr...@gentoo.org> (05 Nov 2016)
# Masked for removal in 30 days, bug #568980
# Unmaintained and deprecated.
# Use net-print/cups-filters as a replacement
net-print/foomatic-filters



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] portage-2.3.2 stable request?

[Manuel Rüger]

On 05.11.2016 00:15, Zac Medico wrote:
> On 11/04/2016 03:55 PM, Zac Medico wrote:
>> On 11/04/2016 03:47 PM, Brian Dolbec wrote:
>>> On Fri, 4 Nov 2016 13:53:02 -0700
>>> Zac Medico  wrote:
>>>
 On 11/04/2016 01:43 PM, Michał Górny wrote:
> On Fri, 4 Nov 2016 13:19:39 -0700
> Zac Medico  wrote:
>   
>> On 11/04/2016 01:14 PM, Brian Dolbec wrote:  
>>> On Thu, 3 Nov 2016 15:55:23 -0700
>>> Zac Medico  wrote:
>>> 
 In about a week, portage-2.3.2 will be eligible for a stable
 request.

 The only potential problem that I've noticed is the complaint
 about changes from bug 552814 causing issues for people using
 git sync with overlay filesystems, but setting sync-depth = 0
 gives those users a workaround. There's also bug 597838, about
 the sync-depth setting being ineffective, but I only know of a
 couple of people that have been able to reproduce that.

 So, do we want to do a stable request portage-2.3.2 when the time
 comes?
>>>
>>> I'm not sure.  Do we -r1 it adding a patch or two and ask it be
>>> stabled? 
>>
>> There are just 4 commits since 2.3.2, and they all look good.
>> Maybe we should just cut a 2.3.3 release and wait another 30 days
>> (we also need to stabilize app-crypt/gkeys since it's needed by
>> emerge-webrsync now).  
>
> Wouldn't it be better to have a really working version of gkeys
> before it's stabilized? Like one that could be used without having
> to create custom configuration files and/or run it as root?  

 Well, gkeys stabilization is not really mandatory, since
 emerge-webrsync has a --insecure option.
>>>
>>> Why don't I/we work on whatever changes are needed to merge the
>>> meta-manifest code to both portage and gkeys.  I'll push out another
>>> release.  I also had some initial code that added gkeys use to verify
>>> the pkg Manifest file, but I don't know if that is needed still, the
>>> meta-manifest system will need to run a verify at the end of the sync.
>>>
>>> We'll have to poke Robin some more to get some new infra keys setup.
>>>
>>> If I have to, maybe I'll create some ansible scripts to run the dev
>>> seeds update on vulture, transfer it to my system to push --sign to
>>> api.g.o or break down and get Kristian to help me get key forwarding
>>> better setup so I can do it from vulture.
>>
>> Sounds good, but I think we should cut a portage 2.3.3 release before we
>> make any more changes. Maybe do a release branch that includes
>> everything except the emerge-webrsync change.
> 
> Let's just revert the emerge-webrsync patch, so we can tag a 2.3.3
> release on the master branch.
> 

Will repoman be released with the same tag as well or is the portage and
repoman version not going to be syncronized?

Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Multiple misc. Python packages for grabs

[Manuel Rüger]

On 29.10.2016 23:21, Michał Górny wrote:
> Hello,

> dev-util/bumpversion

Added myself as a maintainer.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [gentoo-proxy-maint] Package up for grabs

[Manuel Rüger]

On 11.09.2016 20:57, Nick Vinson wrote:
> Hi,
> 
> I am the former maintainer of net-print/hplip-plugin, and because I have
> removed myself as the package maintainer, there are no other maintainers
> listed in metadata.xml.
> 
> Thus, the net-print/hplip-plugin package is now up for grabs.
> 
> - Nicholas Vinson
> 

Thanks for creating and maintaining the package, Nicolas! I've added the
printing project as the maintaining team.

Cheers,

Manuel

Re: [gentoo-dev] Looking for a new mentor...

[Manuel Rüger]

On 21.07.2016 02:46, Mikle Kolyada wrote:
> 
> 
> 21.07.2016 02:41, Manuel Rüger пишет:
>> Hey,
>>
>> have you tried contacting recruit...@gentoo.org?
>>
>> https://wiki.gentoo.org/wiki/Project:Recruiters
>>
>> Cheers,
>>
>> Manuel
>>
>> On 20.07.2016 21:13, alexmcwhir...@triadic.us wrote:
>>> I've been working towards becomming a gentoo developer for while now in
>>> order to bring the sparc port up to speed with the rest of the gentoo
>>> project. In short there appear to be no active gentoo developers working
>>> on sparc.
>>>
>>> I had a mentor earlier this year, but i can no longer get in touch with
>>> him.
>>>
>>> I have both quizzes nearly complete, i just need someone to look over
>>> them and answer a question or two. Any help would be greatly
>>> appreciated.
>>>
>>
> 
> Recruiters take care of recruitment process, not about mentors:)
> 

They do. But they usually are aware of possible and active mentors and
can recommend some.

Cheers,

Manuel.

Re: [gentoo-dev] Looking for a new mentor...

[Manuel Rüger]

Hey,

have you tried contacting recruit...@gentoo.org?

https://wiki.gentoo.org/wiki/Project:Recruiters

Cheers,

Manuel

On 20.07.2016 21:13, alexmcwhir...@triadic.us wrote:
> I've been working towards becomming a gentoo developer for while now in
> order to bring the sparc port up to speed with the rest of the gentoo
> project. In short there appear to be no active gentoo developers working
> on sparc.
> 
> I had a mentor earlier this year, but i can no longer get in touch with
> him.
> 
> I have both quizzes nearly complete, i just need someone to look over
> them and answer a question or two. Any help would be greatly appreciated.
> 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[Manuel Rüger]

On 04.05.2016 11:19, Duncan wrote:
> Ulrich Mueller posted on Wed, 04 May 2016 10:00:05 +0200 as excerpted:
> 
>>> On Wed, 4 May 2016, Austin English wrote:
>>
 Your list of affected packages obtained with "git grep" in the Portage
 tree will not be complete, since the command won't catch any init
 scripts installed from elsewhere. You should look for the set of
 installed files instead.
>>
>>> How is that relevant here at all? I'm cleaning up portage installed
>>> init scripts, [...]
>>
>> You are cleaning up only those init scripts that are installed from
>> FILESDIR, but you will miss the ones that are installed from a file in
>> SRC_URI.
> 
> While you are correct, the current problem isn't lack of low hanging 
> fruit to fix in the files dir, as he said there's 700 packages on the 
> list already, too many to file individual bugs for.
> 
> So while it is indeed worthwhile to keep in mind the init-scripts 
> installed from SRC_URI...
> 
> There's seven hundred "miles of open road" to cross before we have to 
> worry about that SRC_URI bridge, so maybe worry about that when we're 
> within 50 or 100, or even a couple hundred, "miles", not 700. =:^]
> 

Hi Austin,

to be honest, I'm not too happy with the fixes you applied.
Although it's just a tiny change, I'd rather have expected a revision
bump to the ebuilds and a revision bump to the init files themselves
than just a in-file rewrite.
Your fix changes the content of files that are installed to ones system.
Such a change usually requires a revbump.


Cheers,

Manuel




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

[Manuel Rüger]

Hello gentoo-dev,

I'd like to announce the NGINX_MODULES_STREAM use expand.

It will include nginx modules used for stream support.
Initially, there will be the following descriptions included:


access - This module allows limiting access to certain client addresses.
limit_conn - This module is used to limit the number of connections per
the defined key.
upstream - This module is used to define groups of servers that can be
referenced by the proxy_pass directive.


Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 05/16] ebuild-writing/misc-files: replace the code for cvs commit with git #558642

[Manuel Rüger]

On 17.01.2016 08:55, Gokturk Yuksek wrote:
> Replace "cvs commit" with the equivalent "git add && git commit" version.
> 
> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
> Signed-off-by: Gokturk Yuksek 
> 
> diff --git a/ebuild-writing/misc-files/metadata/text.xml 
> b/ebuild-writing/misc-files/metadata/text.xml
> index e506b1c..a8beacc 100644
> --- a/ebuild-writing/misc-files/metadata/text.xml
> +++ b/ebuild-writing/misc-files/metadata/text.xml
> @@ -532,7 +532,8 @@ is currently:
>  
>  xmllint --noout --valid metadata.xml
>  glep31check metadata.xml
> -cvs commit -m "Adding category metadata.xml for my-category" metadata.xml
> +git add metadata.xml
> +git commit --gpg-sign -m "Adding category metadata.xml for my-category"
>  
>  
>  
> 

Can we discourage to use "-m" and prefer to open up an editor instead?

Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Packages up for grab

[Manuel Rüger]

Feel free to add yourself to:

app-editors/diakonos
app-misc/ddccontrol
app-misc/ddccontrol-db
net-libs/txtorcon
net-wireless/mfoc
sys-apps/fwts
sys-apps/fxload
x11-plugins/pidgin-indicator


- M



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Manuel Rüger]

On 12.01.2016 20:22, Aaron W. Swenson wrote:
> There are several ebuilds that repeat the same checks and need to
> perform the same duties when it comes to working with PostgreSQL. For
> example, making sure the users' currently slot is compatible with the
> ebuild requirements. postgres.eclass addresses this and has
> additional conveniences to build a dependency string and add a new user
> into the postgres system group.
> 
> Additionally, as most of you are aware, we have a slot capable
> dev-db/postgresql. There is some difficulty that needed to be resolved
> so that extensions could also be installed into multiple slots, which is
> addressed by postgres-multi.eclass.
> 
> I've an overlay at:
> https://github.com/titanofold/titanofold-gentoo-x86
> 
> With the pgsql-eclass branch containing the eclass and a postgres-multi
> enabled PostGIS.
> 
> Naturally, the eclasses work for me, so far.
> 
> For your convenience, I've also attached the eclasses.
> 

You might wanna add some quotes around the variables in that line:
enewuser $1 $2 $3 $4 ${groups}

Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] packages to grab

[Manuel Rüger]

On 07.01.2016 14:50, 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.
> 
> I will move all packages I maintain [1] to the associated projects if
> possible. All devs are free to take what ever you are interested in. I
> am also happy to proxy contributors if they like to maintain a package.
> 
> My plan is to focus more on task which I can handle more flexible.
> 
> Regarding the projects I am involved in I have the following ideas:
> 
> _Recruiters_
> 
> We are again actively looking for someone who is doing the review
> session. The candidate should have solid knowledge about the various
> aspects for Gentoo reaching from packaging to institutional aspects.
> Further, you should be able to work with inexperienced contributors
> and have fun teaching the necessary bits.
> 
> Secondly, I would like to work strategically on our recruitment
> process. This includes reworking of the quizzes and a general
> assessment of the process as well as new options. We won't change
> anything over night, but I really think we can do simpler and better.
> 
> In case you are interested in either topic, feel free to drop a mail
> to recruit...@gentoo.org.
> 
> _Science_
> 
> We are understaffed for a long time. So in case you like to join feel
> free to do so. This is also and especially directed to the community.
> I strongly encourage you to contribute via PR to the overlay or the
> main gentoo.git. If you have proven yourself in contributions and
> still nobody encouraged you to become a full dev, don't hesitate to
> express your wish and we will manage your recruitment.
> 
> _Council_
> 
> My council duties should not be affected.
> 
> _Other project_
> 
> For the time being, I need to drop most work there.
> 
> Cheers,
> Justin
> 
> 1)
> http://euscan.gentooexperimental.org/maintainers/jlec%40gentoo.org/
> 

Hi Justin,

I'd like to take over maintenance for

app-office/texstudio
app-admin/ngxtop
dev-vcs/git-cola
net-analyzer/linkchecker

Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: media-tv/xawtv

[Manuel Rüger]

# Manuel Rüger <mr...@rueg.eu> (24 Dec 2015)
# Effectively unmaintained, multiple bugs
# Bug 288611,358013,413987,468186,480854,528750,548480,566226
# Masked for removal in 30 days.
media-tv/xawtv



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] metadata: add slots element

[Manuel Rüger]

On 13.10.2015 11:39, hasufell wrote:
> On 10/13/2015 09:51 AM, Alexis Ballier wrote:
>>
>> that would work too, but dtd provides standardization, and avoids
>> duplicating package-wide information (meaning of slot/subslot) in every
>> single ebuild.
>>
> 
> Yeah, the only thing that I wasn't sure about is the subslots part. With
> the proposed patch we don't document a subslot for a specific slot, but
> for the whole package. Everything else looked too complicated/ugly in
> xml and I'm not sure we even need it. If someone has a better idea,
> please speak up.
> I think it should be kept simple, because we want devs to fill in this
> kind of information, not confuse them.
> 

Should we extend the definition, so it can optionally
include a number of libraries the subslot is created from?

libfoo.so libbar.so libbaz.so

This would enable us to write a tool that checks for changed sonames
automatically (by using some command like find ${DESTDIR} -name
"libsoname.so" and run objdump on it.

Cheers

Manuel






signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Manuel Rüger]

On 11.10.2015 10:29, Brendan Horan wrote:
> - On 11 Oct, 2015, at 4:17 PM, wraeth wra...@wraeth.id.au wrote:
> 
>> On 11/10/15 18:52, Ian Delaney wrote:
>>> On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier
>>>  wrote:
>>>
 On Sat, 10 Oct 2015 10:09:11 +0200 Michał Górny
  wrote:

> Hello, developers.
>
> I have the pleasure
>>>
>>> :?
>>>
> to announce that we have formed a new Reviewers team [1] for
> Gentoo. The team is going to assemble developers willing to
> perform ebuild reviews and help contributors improve their
> ebuild skills.
>
> The main goal of the team is to handle GitHub pull requests. We
> are going to review incoming PRs, communicate with maintainers
> and merge them as appropriate. In particular, we're going to
> help willing contributors get high-quality, PGP-signed commits
> into Gentoo, therefore helping them prepare to become Gentoo
> developers.

 This is cool

> The side goal is to review current Gentoo commits for major QA
> violations and other issues, aiming at improving the quality
> of ebuilds in Gentoo and helping other developers using bash,
> ebuilds and git effectively.

 This is completely unrelated: since we've had gentoo-commits ml,
>>>
>>> which was promptly utlised
>>>
 every one has been able to do commit reviews easily, and most
 devs have done so. Self-proclamed reviewers project certainly
 does not have the monopoly of best practices nor perfect
 knowledge. I hope they do keep the monopoly of being harassing
 though :)

 Also, you should probably focus on what's really important:
 reviews like "this is weird, care to explain?" or stylistic
 nitpicks are just a waste of every one time, meaning more
 important stuff does not get done.

>>>
>>> To my observation the reaction to this has been between displeasure
>>> and dismay.  Yesterday the dev-ML was flooded with the first day's
>>> publication of the members' reviews. Firstly the gentoo-commits ML
>>> to my understanding is intended to be used for and by qa members.
>>> This project has one whom we presume has the discretion to declare
>>> the use of the qa hat at whim.
>>>
>>> As someone once put it, it's not the product or message it's the
>>> delivery of the package.  This project in its creation is made of
>>> self appointed members who assume the status and qualification to
>>> suddenly launch their evaluations upon unsuspecting folk the
>>> community wide with neither  warning  nor their prior knowledge nor
>>> consent. The editing to the page illustrates already significant
>>> back pedalling from feedback already challenging its selected mode
>>> of delivery.
>>>
>>> The project goals and 'would be' mission statement are in fact
>>> legitimate and have the backing of Council members.  The execution
>>> has been done independently, unilaterally and with no input or
>>> collaboration with Council to my knowledge.  The actions of this
>>> project potentially impact on every developer / user of the gentoo
>>> project, addressing the core skills of both. Yet it has been made,
>>> announced and executed in this style.
>>>
>>> I invested study time in several units in teaching and lecturing in
>>> my university education under the education department. Sorry but
>>> the modi operandi by these self proclaimed teachers and educators
>>> thus far violate almost every fundamental principle in the art of
>>> teaching that I learned from the course. There have also been users
>>> who have expressed concern to me over this directly, some of which
>>> have indicated they will also email this list to make their views
>>> known.
>>
>> I am one of the users who spoke to idella4 about this, but I wanted to
>> repeat this publicly in order to highlight the point of view of
>> contributing user as opposed to a developer.
>>
>> Firstly I would like to say that I appreciate feedback on my work - it
>> helps me to improve the quality of my work both for Gentoo and personally.
>>
>> I also agree whole-heartedly to the concept of the Reviewers project, in
>> that highlighting common improvements that could be made would benefit
>> both contributors who participate and Gentoo as a whole.
>>
>> Having said that, however, I do not appreciate the method in which these
>> criticisms were delivered, and believe it extends beyond the idea of
>> the Reviewers project.
>>
>> I feel that it is inappropriate for criticisms of contributor's work to
>> be broadcast on a mailing list that is read not only by the developer
>> community, but by users as well, without their consent. This is not a
>> case where I am particularly embarrassed or upset - if others can learn
>> from my mistakes, then they are mistakes I am happy to make (preferably
>> only once). But doing so publicly, with identifying information, is
>> inappropriate.
> 
> I will second your 

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgit2/

[Manuel Rüger]

On 10.10.2015 16:15, hasufell wrote:
> On 10/10/2015 03:54 PM, Manuel Rüger wrote:
>>
>> Dear Julian,
>>
>> avoiding this mailing list for further reviews is great news.
>> Still, I'd like to opt-out from receiving any mails arising from project
>> "Reviewers".
>> If there are QA-related issues with packages, I maintain, please file a
>> bug on bugs.gentoo.org.
>>
> 
> That's a great start for us, having developers announce publicly that
> they will ignore our project or require us to create bugs for every
> missing "|| die" in an ebuild.
> 
> Not everything belongs on bugzilla. If there are common mistakes (e.g.
> missing SLOT :0 on openssl, libpng, jpeg and whatnot), we might still
> post them here, so that people are made aware of that. And that also has
> happened recently (I'd say not even half of the ebuilds I was looking at
> during my libressl work had a correct openssl depstring).
> 
> Knowing that you will ignore all those mails is very motivating. I'll
> leave it to your own consideration whether that is in accordance with
> our CoC/social contract. But ignoring each other is already very common
> in gentoo and accepted practice, so what can I say.
> 
> 
> Nevertheless, we'll try to continue, reduce public noise and keep the
> reviews useful.
> 

Dear Julian,

I guess you misunderstood my reply somehow.
Neither I am ignoring the project, as I welcome QA-related reviews nor
do I want to turn down your motivation to review packages. I simply just
want to become notified via bugzilla instead of plain mail.

There are various reasons. I probably should have explained them before.
I am sorry for that.
* While I receive countless mails on multiple accounts every day and
also read those on (mobile) devices, that do not allow access to Gentoo
repositories, I will simply miss to fix those issues.
* A bug in bugzilla reminds me in an organized way about issues, that
should be fixed.
* It is also organized in a way, that is easily searchable for others
that come across the issue.
* Bugzilla allows to change the assignee, CC yourself get notified about
changes and lots of other possibilities a mailing list doesn't serve.
* And finally: Bugzilla is not a broadcast medium as mailing lists are,
allowing people to subscribe to things they actually are interested in.

Regarding the issues you consider too low-hanging for bugzilla, have you
considered to use IRC for that?

With best regards,

Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgit2/

[Manuel Rüger]

On 10.10.2015 15:25, hasufell wrote:
> On 10/10/2015 03:14 PM, Manuel Rüger wrote:
>>
>> Dear Michał,
>>
>> first of all, please stick to the truth.
>>
>> In #gentoo-dev:
>>  mrueg: as i pointed out, it was because i see it in pull
>> requests and gentoo developers are teaching bad practices to new recruits
>>  mgorny: please don't CC me in future then, thanks.
>> [...]
>>  I already set up a sieve filter to filter out those Re:
>> [gentoo-commits] mails in gentoo-dev, I don't want to filter those I
>> receive because they actually could be QA-related and not a
>> stylistic-nitpick.
>>
> 
> We are trying to do useful reviews and we may make mistakes. This is not
> to annoy people and if we find that particular things are controversial,
> we will just stop adding those to our reviews.
> 
> But setting up sieve filters to throw out everything that the project
> devotes time on is very motivating.
> 
>> I guess your actions were part of the recently established project
>> "Reviewers". Therefore, I'd like to remind you and the other members of
>> this project about our CoC:
>>
>> "Using the correct forum for your post. Bug reports and idle chatter do
>> not belong on the gentoo-dev mailing list; discussion about a
>> wide-ranging change to the tree probably does not belong on Bugzilla.
>> Different fora will also have different standards of behaviour – a joke
>> that is perfectly acceptable on IRC will be taken differently when made
>> on a mailing list." [1]
>>
> 
> As you might know, I haven't really reviewed much on dev ML either,
> until people started ranting about our Social Contract, how github is
> against it and that everything must be public on our own infra channels.
> 
> I'll stick to sending (semi-)private mails then and CC
> review...@gentoo.org. So in case you just want to set up another sieve
> filter.
> 

Dear Julian,

avoiding this mailing list for further reviews is great news.
Still, I'd like to opt-out from receiving any mails arising from project
"Reviewers".
If there are QA-related issues with packages, I maintain, please file a
bug on bugs.gentoo.org.

Thanks for your consideration.

- Manuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgit2/

[Manuel Rüger]

On 10.10.2015 14:55, Michał Górny wrote:
> Dnia 2015-10-10, o godz. 13:51:34
> Michał Górny <mgo...@gentoo.org> napisał(a):
> 
>> Dnia 2015-10-10, o godz. 11:31:45
>> "Manuel Rüger" <mr...@gentoo.org> napisał(a):
>>
>>> commit: 9d15a1c12b3c4f98445a45c051733eb2a67fdb28
>>> Author: Manuel Rüger  gentoo  org>
>>> AuthorDate: Sat Oct 10 11:30:54 2015 +
>>> Commit: Manuel Rüger  gentoo  org>
>>> CommitDate: Sat Oct 10 11:30:54 2015 +
>>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9d15a1c1
>>>
>>> dev-libs/libgit2: Version bump
>>>
>>> Package-Manager: portage-2.2.23
>>
>> Pretty much picking up a random commit to point out a common mistake.
> 
> (removed mrueg@ from CC as he doesn't wish to be notified of QA issues
> with his commits)
> 

Dear Michał,

first of all, please stick to the truth.

In #gentoo-dev:
 mrueg: as i pointed out, it was because i see it in pull
requests and gentoo developers are teaching bad practices to new recruits
 mgorny: please don't CC me in future then, thanks.
[...]
 I already set up a sieve filter to filter out those Re:
[gentoo-commits] mails in gentoo-dev, I don't want to filter those I
receive because they actually could be QA-related and not a
stylistic-nitpick.

I guess your actions were part of the recently established project
"Reviewers". Therefore, I'd like to remind you and the other members of
this project about our CoC:

"Using the correct forum for your post. Bug reports and idle chatter do
not belong on the gentoo-dev mailing list; discussion about a
wide-ranging change to the tree probably does not belong on Bugzilla.
Different fora will also have different standards of behaviour – a joke
that is perfectly acceptable on IRC will be taken differently when made
on a mailing list." [1]

Thanks

- Manuel

[1] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LibreSSL import plan

[Manuel Rüger]

On 19.09.2015 23:04, hasufell wrote:
> Friends,
> 
> I think it is time to import LibreSSL[0]. There are not many packages
> left that don't compile OOTB and those can be patched (e.g. dev-lang/ruby).
> 
> My idea would be:
> 
> 1. import "dev-libs/libressl" (this will block dev-libs/openssl) and
> introduce the global USE flag "libressl" with the following description:
> """
> libressl - Use dev-libs/libressl as SSL provider (might need ssl USE
> flag), packages should not depend on this USE flag
> """
> 

Devmanual says to discuss global useflags here before introducing them.
IMO merely announcing them is not enough. See
288d8cd90fca12fafd021d86837851d8cb5c6efe.

> Did I miss anything?
> 
> 

Yeah you missed to wait till the discussion has settled before you start
to commit your plan.
Please stop introducing further tree-wide changes regarding libressl.

- Manuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LibreSSL import plan

[Manuel Rüger]

On 20.09.2015 16:26, hasufell wrote:
> On 09/20/2015 03:27 PM, Manuel Rüger wrote:
>> Please stop introducing further tree-wide changes regarding libressl.
> 
> That's not possible, because in order to introduce the USE flag, we have
> to break the dep-graph on ~arch temporarily (for 'libressl' USE flag
> only ofc), because of circular deps.
> 
> I am working on restoring it now. This does not affect stable branch at
> all and no one who is not using 'libressl' USE flag (which is
> practically impossible currently).
> 

Yet the way you execute your plan now violates several devmanual
policies. Is there any reason for that rush?

> If you have useful comments regarding the transition, please speak up.
> 

I remember you being one of the devs who considered code reviewing as a
useful tool.
Why don't you add a pull request to Gentoo's github mirror and let other
devs review and ack it there?


- Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LibreSSL import plan

[Manuel Rüger]

On 20.09.2015 18:57, hasufell wrote:
> On 09/20/2015 06:47 PM, Manuel Rüger wrote:
>> On 20.09.2015 16:26, hasufell wrote:
>>> On 09/20/2015 03:27 PM, Manuel Rüger wrote:
>>>> Please stop introducing further tree-wide changes regarding libressl.
>>>
>>> That's not possible, because in order to introduce the USE flag, we have
>>> to break the dep-graph on ~arch temporarily (for 'libressl' USE flag
>>> only ofc), because of circular deps.
>>>
>>> I am working on restoring it now. This does not affect stable branch at
>>> all and no one who is not using 'libressl' USE flag (which is
>>> practically impossible currently).
>>>
>>
>> Yet the way you execute your plan now violates several devmanual
>> policies. Is there any reason for that rush?
>>
> 
> Any reason to bother me? There have been several threads about libressl
> and the overlay has been up for more than one year I think. If you have
> a suggestions, say it.
> 
There has been an ongoing discussion after you announced your plan.
Instead of getting your suggestion actually reviewed and probably
improve your plan on a further iteration, you're creating accomplished
facts.

>>> If you have useful comments regarding the transition, please speak up.
>>>
>>
>> I remember you being one of the devs who considered code reviewing as a
>> useful tool.
>> Why don't you add a pull request to Gentoo's github mirror and let other
>> devs review and ack it there?
>>
> 
> Because then I could simply give up with ~550 packages, where for most
> of them the change is a two-liner in RDEPEND. It is common in gentoo to
> not ask every single maintainer for tree-wide changes. The python herd
> does that too.
> 

What about the packages that are not part of "most"? Some include
patches, that haven't seen any testing by their downstream maintainers.
See 1fbc7d68335e35af898606f1dfdaedf9bf6bea14 or
9c9eff93fe71c5b446df8367d69c407d62811b05.


> If I don't know how to do something or if the changes are non-trivial,
> then I will definitely open a bug/PR.
> 
> Again: this all happens in unstable arch and practically effects no one,
> because people cannot effectively enable the USE flag yet.
> 

And after you're done, people will argument: "Should we really change
500 packages again?"
This renders any further discussion redundant and is not how an open
development process should look like.

- Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

[Manuel Rüger]

On 14.09.2015 10:41, konsolebox wrote:
> On Mon, Sep 14, 2015 at 4:32 PM, konsolebox  wrote:
>> On Mon, Sep 14, 2015 at 4:28 PM, Kent Fredric  wrote:
>>> On 14 September 2015 at 20:22, konsolebox  wrote:
 If we use an arithmetic operator like ~> then that could be decided
>>>
>>> As a counter proposal I'd suggest a different suffix character than
>>> "*" instead. It just seems less confusing to have something like
>>>
>>> =cat/foo-1.30+
>>>
>>> Instead of
>>>
>>> ~>cat/foo-1.30
>>>
>>> Because ~> to me conveys some combination of ~ and > effects, when it
>>> is neither of those two.
>>
>> I thought ~> is good as it's already famous to fellow Ruby users but I
>> don't mind.  =cat/foo-1.30+ seems good as well.
> 
> @cat/foo-1.30 is also another.  It only uses one symbol doesn't look
> bad if negated: !@cat/foo-1.30
> 

Please don't add any more syntactic sugar to dependency strings.
People might become confused about stuff like this:

=cat/foo-1.3.1_rc3_p20130829-r42+[!a=,!b?,c(+)]:3=

Is there any real need to express this in a single line except for
saving a single line?

- Manuel



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: app-i18n/atokx2

[Manuel Rüger]

# Manuel Rüger mr...@gentoo.org (26 Aug 2015)
# Masked for removal in 30 days.
# Superseded by app-i18n/atokx3.
# See bug #553208
app-i18n/atokx2



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] News item: Ruby 1.9 removal; Ruby 2.0/2.1 default

[Manuel Rüger]

Hi,

this news item is just an updated version of 2014-03-16-ruby-1.8-removal.

Check [1] for more information.


Cheers,

Manuel

[1]
https://archives.gentoo.org/gentoo-dev/message/989e7e69f231291736c0c632a2df69e3
Title: Ruby 1.9 removal; Ruby 2.0/2.1 default
Author: Manuel Rüger mr...@gentoo.org
Content-Type: text/plain
Posted: 2015-08-26
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: dev-lang/ruby

Ruby MRI 1.9 has been retired by upstream in February 2015.[1]
We remove Ruby MRI 1.9 support from the tree now. In parallel Ruby MRI 2.1 
support will be activated in base profile's RUBY_TARGETS variable by default 
in conjunction with Ruby MRI 2.0.

If your currently eselected Ruby interpreter is ruby19, our recommendation is 
to change it to ruby20. At the moment Ruby MRI 2.0 delivers the best possible 
support of all Ruby interpreters in tree.

Check the current setting via:

eselect ruby show

Change the current setting to Ruby MRI 2.0 via:

eselect ruby set ruby20

[1] 
https://www.ruby-lang.org/en/news/2015/02/23/support-for-ruby-1-9-3-has-ended/


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Removal of dev-lang/ruby:1.9

[Manuel Rüger]

Hi,

as upstream stopped maintaining ruby 1.9 in February 2015, it is about
time to phase out ruby 1.9 support in Gentoo [1,2]. Recently ruby 2.1
has been stabilized on all supported architectures.
Therefore, the Ruby team will update RUBY_TARGETS from
RUBY_TARGETS=ruby19 ruby20 to RUBY_TARGETS=ruby20 ruby21.
This will enable support for ruby21 and remove the support for ruby19 at
the same time to keep the compilation effort for our users minimal.

See [2] for packages that require further attention by their
maintainers (CC'd).

Our schedule for the removal:

Today: Post news item to gentoo-dev
Today + 3d: Add news item to gentoo-news repository
Today + 1 week: Start masking USE=ruby for packages that still rely on
ruby19 (again see [2]); update RUBY_TARGETS in base profile to ruby20
ruby21
Today + 2 weeks: Mask ruby 1.9 and deps for removal

Cheers,

Manuel


[1] https://bugs.gentoo.org/show_bug.cgi?id=536852
[2] https://wiki.gentoo.org/wiki/Project:Ruby/Ruby_1.9_deprecation




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] golang-build.eclass updates

[Manuel Rüger]

On 23.07.2015 00:19, William Hubbs wrote:
 All,
 
 after some testing, i decided that the eclass should make both the
 golibdir and the prefixed version of it available with functions.
 
 The reason for this is that the prefixed golibdir should be part of
 GOPATH when building packages.
 
 The functions are get_golibdir and get_golibdir_gopath.
 
 Here's the updated patch.
 
 William
 

Have you tested this with FEATURES=multilib-strict?

I guess you need $(get_libdir) from multilib eclass to set the correct
libpath.

Manuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] News item about mysql client and server packages

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 17.07.2015 19:56, Brian Evans wrote:
 Title: MySQL client libraries and server packaging changes
Be more specific, call it split instead of changing.
 Author: Brian Evans grkni...@gentoo.org Content-Type: text/plain 
 Posted: 2015-07-17 Revision: 1 News-Item-Format: 1.0 
 Display-If-Installed: virtual/mysql
 
 The future of the mysql packages is changing.
 
That is probably the reason, write you write that news. I'd drop it,
as it is kind of redundant.
 First off, a new virtual is being introduced,
 virtual/libmysqlclient. virtual/mysql will represent the server and
 tools while virtual/libmysqlclient will represent the shared and
 static libraries.
 
Explain first what virtual/libmysqlclient is and then what
virtual/mysql does. Makes it better to read.

 Developers and ebuild writers should reference
 virtual/libmysqlclient when linking against the libraries as the
 package will keep the subslot the same as the soversion for easy
 rebuilds.  This is getting more difficult in the current virtual
 situation as MySQL and MariaDB start to diverge versions and
 features.  The old method could force users to mask new versions or
 delay the posting of one server package which advances the
 soversion until the others catch up.
 
I'm not sure if this is necessary to know for a user.

 As for the server packages themselves, the minimal USE is being 
 replaced. The new USE flags are client-libs, +server, and +tools. 
 The server and tools flags are on by default to signify the
 primary purpose of those builds.
This is probably one of the most important things (plus maybe the
following sentence in the next paragraph), when targeting users. If
you don't drop the part directed at ebuild writers, you should move
that paragraph up to the beginning (plus the following sentence).
Otherwise users might skip reading the news if they have to read
unrelated notes first.
 
 The primary provider for libraries will be a new package 
 dev-db/mysql-connector-c.  A tinderbox run did not turn up any
 issues, but packagers are permitted to block any provider of 
 virtual/libmysqlclient that does not work correctly.  A comment in
 the ebuild would be helpful to track this.  The server packages can
 still provide libraries if the client-libs USE is enabled.
 
Probably many users don't know what a tinderbox is, so drop that or
rephrase it, e.g., We tested the new packaging style thoroughly..


Cheers,

Manuel.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVqVIlXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc0wQP/2rSN7tb03yPZUh5UNK1xk21
kj8ihGo9RgccE+iMTpTz3Yo/Bd4WMWgSdrkiPwTay3MoS55V8DfHbmDfxoPEJgWC
w7IUR02VLxyrFXOqOmEFYCbzwtglFXq5yXPX+QWALJMU0nNckpHMjW9LxqySbu2b
2oMyT2clPWUtcNi0tSsTmRdFCfCvmHCS1xsGBJ6ziTwVfrJIzKWAB/tlbz8E1kzs
vAIjOaODNRz67XVebu2RAjqIebd1iF6EgPUvMIITBjBuR3dzc3ojEtOFpNnvGLWB
RTX2xmekY6sUvN1IuH1lp/o5+E3ODfdUaTOX+BMcyvSYVKQUfe9yXSEmUErZJjME
7hDLd0Ts8PloXkuCK14AI2QqfCyuLRmIfEhC6ZyFPEIfsriK+pzHt/UN7DgBMoXn
t0kiYSAH6oAGLg7J0tbKJCIF/X8TFYs/HIRRdEHwJagcbZpzmrJjqpjl1bxwgwUM
i/LqHZLY/FnmHjvIZriB5k3aI8vlzdhZ40JxC73lPK+8pHbNUOUe4SQVUN8EcBQo
Ueeqf1sNJXGTny94cfUfcz11jTkewBBBLItmaWNUaAjmjacPth6STlcmZQA/FvpN
sjcDvrJdoUJ34VWzYyb/09G6x1/BT6xRD5SoH3ALI1tOusjUa75IMjmtr1lcQFbf
6uZAg4x9COvGPjluyh/J
=hCUC
-END PGP SIGNATURE-

[gentoo-dev] Last rites: app-text/deplate, app-text/migemo, dev-utils/travis-yaml

[Manuel Rüger]

# Manuel Rüger mr...@gentoo.org (5 Jul 2015)
# Mask for various issues (missing ruby20 support, test failures)
# Removal in 30 days
app-text/deplate
app-text/migemo
dev-utils/travis-yaml



signature.asc
Description: OpenPGP digital signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

[Manuel Rüger]

On 03.07.2015 22:22, Robin H. Johnson wrote:
 (Breaking the thread, because I believe this topic needs further
 discussion).
 
 On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote:
 Are there still any plans to use a code review system like gerrit that
 will avoid merges, rebases etc. to the tree by just accepting and
 serializing patches?
 Merges are a fact of life, they will be happening.
 This was included on:
 https://wiki.gentoo.org/wiki/Gentoo_git_workflow
 
 Rebases of already published commits must be avoided.
 
 But beyond that, the general discussion was that a code review system
 was not in the immediate future...
 
 If the merge workflow becomes too problematic due to the high rate of
 change, then we can revisit those systems, to take advantage of their
 auto-merging functionality, but probably only in combination with the QA
 testsuites.
 

Using a Code Review System and allowing direct commits are not mutually
exclusive.
If infra has got time to set it up, this could be an option in addition
to direct commits for developers and we could make it obligatory (e.g.
for the first month) for new developers.

It would also allow proxied maintainers to commit to the tree more
easily, as it will require just an additional ack by the proxy maintainer.

Manuel




signature.asc
Description: OpenPGP digital signature

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

[Manuel Rüger]

On 02.07.2015 23:39, Robin H. Johnson wrote:
 Hi all,
 
 The Git migration is moving forward, and I'd like to announce a
 tentative schedule for that end.
 https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status
 
 2015/08/08 15:00 UTC - Freeze
 2015/08/08 19:00 UTC - Git commits open for developers
 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
 2015/08/11   - History repo available to graft
 2015/08/12   - rsync mirrors carry up-to-date changelogs again
 
 I've allocated time for an 8 hour freeze, but hope to be completed much
 sooner than that.
 

Thanks to all who helped to make this possible! :-)

Are there still any plans to use a code review system like gerrit that
will avoid merges, rebases etc. to the tree by just accepting and
serializing patches?

Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Herd/project cleanup

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 27.06.2015 22:20, Brian Evans wrote:
 On 06/27/2015 03:39 PM, Johannes Huber wrote:
 Hello Kentoos,
 
 i think this topic is overdue. Compared to the list of members
 and real activity i would love to cleanup the herd/project.
 
 So please raise your hands to say yes i want to stay part of
 it or no i am not interested anymore. Please answer me within
 90 days. If you reading this mail after the 90 days and be
 removed, feel free to re-join.
 
 Greetings,
 
 I wish to stay with the mysql and php herds/projects
 
 Brian
 

I think this topic is only about kde project, other projects might
handle it differently. Actually I don't know why it was CC'ed to g-dev.
:)

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVkCagXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcrq4QAJwJ0gAT5uJFVQekzVTfkkc5
uqHnzFONwz4RnputD4pNhHpAWV61CvFua2xlqdZ8UlxegXNNtRLvqn3qIzsikwWR
J0FhfDsdfzzwcNLMzBAmmPfJlyy+6nNFEIWSMQOVvUVdT8zwGbiymD7fIk1bDrzH
DkH2YWDqH9vA8zm9nebuzwSMebr1+6SFCwGOewN820XAAix9G+0iG4/z6Ae8ATXm
Ga9KKGx5OYWJtdU9i0v5e+EExM5f+BsDSFqhph+r9aSN14MRPVrBXbvc4BdNTk7B
wzDYFxIXryNES0XzjZlF3P2s1Pgqx9EghHKZXajdzc+65bEAFj3UHqqbboeINdXT
yBSXi5h/C+Sylhu4mlrV3J2xxrahBVtNJug4ua5Q87vED68mDlwc/5O3ND6ipztd
QZKvnI7GuUGzsIOSj/joLumyu6tjYXa5hKYvn9ZXL5eA09Xx8rkPRhvpUZ97YYjZ
Y1pMQW78PwGtO2dMvSKMktkdFDUAEr0Q3i9ZBKNAzr6/i7Kh0+k+bU/EuFpnGcbT
dTBKlvboaeiKLM78zy4r5sbctqh9ZCpMxUPgI9JR3FomzAbDafACIcPt5qQjDH+v
Znl3yyL6F0ffio22EKzt9i458sFS36kSPhcOCknipJrV9ScIeuKUEgbCRzBtf+z8
QXEHQKfMlbLVQ6NwNK/O
=aHXc
-END PGP SIGNATURE-

Re: [gentoo-dev] Gentoo repository mirror CI project update: first public results

[Manuel Rüger]

On 20.06.2015 23:16, Michał Górny wrote:
 Hello,
 
 I've reduced my work hours this week and used the extra time to finally
 finish setting up some scripts for the repository mirror  CI project.
 They're all now running in cron on the machine offered by Todd Goodman
 for the task, and uploading the results to github.
 
 
Thanks for your work!
 Long story short, what we have now is:
[zip]
 2. Git mirrors of repositories supported by the scripts and passing
 basic QA checks, with metadata cache pregenerated. Hosted at [2].
 
How about overlays that do not use the default Gentoo Foundation GPLv2
header? You might need to filter overlays, as they might not allow
mirroring (assuming they don't use GPLv2 for their ebuilds).

[zip]

Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

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

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11.06.2015 11:16, Alexis Ballier wrote:
 On Wed, 10 Jun 2015 22:43:10 +0200 Ulrich Mueller u...@gentoo.org
 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?
 
 
 are those 60 ebuilds best visible ones ? better convert the last
 few remaining so that best visible one is not eapi1 before banning
 it
 
 my bet would be that those 60 ebuilds are from packages barely 
 maintained, and i doubt banning their eapi will improve that,
 rather the contrary
 
 Alexis.
 


Here's a list of all remaining ebuilds:
https://bpaste.net/show/dca95bc1e22b

There's also a tracking bug available:
https://bugs.gentoo.org/show_bug.cgi?id=512122

Cheers,

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVeWtDXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcr9oP/A8zz9fR1T7ezZwpAzQyTRi2
DfRg9RVMOZUcmOkysFulgQ0kDXiYqXExJuakt7TjKyeLLS+0/I+jMlG8flsBK5/K
zvuYxncNhOBq1LRpEu9g9+XisH05EzQUksNNd9732eozbUbNjmHSO3d3oOmmr4qK
RHVYy5EM3MKHfQVrbjsMDjH/a51rARBYdh4u2Fao5lWYZbH8hsCdreHswI2C8VgQ
t+TMMW+KQMqG3cs30o/pcuoc/JckBstJ67R5qqmo0GCAfSaWLgOioPsCQKnhYt7J
bpo2khdx2O0ncUULmnEtQ1+V/LYzUdnXHU8QIKBEIhvmJKt+RLVKFAvQZ4h0CpPL
szKuxcomI5rHDq1kTWp+CLECVRbb8bQTpRvdWFo68qbDJnoUfyog+2h6wmrtRLVK
G1zeO9rlGhtqa1EAdnSwOwWOnIPnDP4sx5pev1A9GfVjz7/jdlCceZahJsVHS6xG
Iy+gnKqF2gAVXV2DWwbXTQsDoHGrfIwO0Tk3wU+03XBTishYBTsNmDpZYAWHNCaJ
fmq1nF3MvSiVBG5cCy7RcMgRADh2Qmc5TwyqSRH/O5XmQS3/q6BNlMr53ErCYD+I
UFYPhZ/dzlUDjfJ9W7Ibrh3gTzPmK6AJdKx9rMMuzxzhn4qcgC6aPGRUCPfzrKRk
9/hQW9JSVVbr1CE4YReN
=iC5/
-END PGP SIGNATURE-

Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 14.03.2015 23:37, Rich Freeman wrote:
 On Sat, Mar 14, 2015 at 6:25 PM, Robin H. Johnson
 robb...@gentoo.org wrote:
 0. What names for the tree/repository.
 
 Suggestions: gentoo-repo gentoo-repository gentoo-main 
 gentoo-repo-main gentoo-repository-main
 
 1. We have some namespaces in Git: proj, dev, priv, data, sites,
 exp; should the tree be in one of those namespaces, a new
 namespace, or be without a namespace?
 git://anongit.gentoo.org/NEW-NAME.git.
 
 
 I'd suggest creating a repository(-ies) namespace (or maybe call
 it repo(s)), since conceivably we might have more than one at some
 point, overlays might end up in there at some point, etc.
 

iirc most deb and rpm based distributions use main for their central
repository, so +1 for gentoo-main.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVBMSUXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcIW4P/RLzP0OhM6SpFbCPvXRNbIqJ
ggL/BXHY7G6xOO++CHxIvNx00cLtoK0lq0MANBbjNffQ5Wv/LHxhrF2oX4CwO91a
AYwZEkmtaauLkx8xrVmhFvuq/liPD4So1JMZ/HMomMa1yb2VevPMjSXW2YwimnM4
wADziajFGcdJR+yXkv3agl/mLC+vugGRlkMTDBXbwVG9qyhI+8Lmgup7UNerikKB
Rz+oOzGuAxm35B/WqEHN1okME2WLce7sK1iCUfHscgPAuyz3tbB7B3VuDMLtyisL
lDo3IOroI5Xug1u0+dABmuGgEeWb1GsZH059E05dmRMoEicyimFmwAw0YTfmqP0k
/e4QhMiEX4xB8GnASByWSAMPR5cDd5FzS1nImcE6Vm/3PfPhWwdFhAWk5irna3iw
dzQ4SGt0HH6G5EQKPSFtCkNYOfDDzXNCWFPwDzyppkr0NdpR0vmLOK8ZNW/RiSMJ
Rqmsghbecp/ISx+Df1fEnOrOtZY+8NwnyWbe2kVDJnUaxRXnqmm7Jydn1kL0v1dC
b9g87wBdMzxR1Wa1qA0elhbR5V8x89XTflrJAzSO+Q7NTEDfnsUTQnbKEMMNIEwT
halUzQ3ztbVErZ/pedP4a3zY0VgIMPECFo9aFcJz6zYZUtD+QImNQMyRu3Llibc6
erviQ5ymtEymKsoOSVn0
=Ju4K
-END PGP SIGNATURE-

[gentoo-dev] Packages up for grabs

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Feel free to take over and drop me from metadata.xml, if you're
interested:

* app-editors/diakonos
 Description: A Linux editor for the masses
* net-wireless/mfoc
 Description: Mifare Classic Offline Cracker
* sys-apps/fwts
 Description: Firmware Test Suite
* sys-apps/fxload
 Description: USB firmware uploader


Cheers,

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVBJ1RXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcygIQAKmK3VO4lldVCMvNhW8NpETR
/v2FqqRYSLQTDOhx8Qqgv0lLR9zKOd9BrAv/Q7HDKs1iRNJUGYll1eyh+LqaQKjl
x0Kv3X9bH9Gz7+PQauYY6v8vrPyAEKDaqekjx6Zr+E19m6sC6wZI6d9sPaXyGB5h
GTXDoQj2NlkDcdGwu/H04SuHOq2PNjrfeuI5PnfvH1AVlcmmS3RP/mXcDasAmBX/
Yj4kxS4lvp9rNXlulhtH071cRPRfFeKP8L7slPNDY1tqLJTr5VUatpiupxCcTrGU
bgnvedOVLM5JvCcDZ8oEE9JPfpI6s2bpDxbIhuoBqn76L5qdptVDj8AlkIPx6RnG
BRGUNPdhiDCoznQy0PVuKt4OHMO3i0aEf+qSe37dTa6UkvV1+ekN0vFDDdTMCVkn
u4CWa0EAYRnQRUS8Js1MpoplDHWgeauRHY28mnqdI60ne1WTFADdodWQyvthi5tx
IRcTPj/oltckOQe+u9XLG0HNFtVPn16YNQy6AT3E5SnrYNQ9KSWgqjmqa/sia6j6
PVdFXEH8fmg6S4w7RKOisTJExCPh1wv1q2QdwmOqRSO/ghbBuTgMRC62uJoAOTAr
o00n7yt8sb3EryfSIWg0brOQ8YoCfzf2w/zyB95DujFRvPfehj/c3lCZ2g0FikSN
EUxmqXLfmFkXOOMm7TBX
=IqkG
-END PGP SIGNATURE-

[gentoo-dev] Last rites: net-libs/libmsn, net-im/pebrot, net-im/msnlib, net-im/pymsn-t

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Manuel Rüger mr...@gentoo.org (2 Mar 2015)
# MSNp18 clients are not able to connect anymore
# See also: http://ismsndeadyet.com
# Masked for removal in 30 days
net-libs/libmsn
net-im/pebrot
net-im/msnlib
net-im/pymsn-t



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ7BAEBCgBmBQJU9LY4XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcuVwP+Ng1+gENkQK7k6oucGxmU+7X
CY6uZRkQ6zOvmtEpNSQL50n4/NToWC0N6OhHgUss1CebdU/N9/e7fr08X0hZ3Anw
7OWC/KlVsX1G4F874+AZsvNe40F3wvWdeDVZytX4qhlipn7bFV0LzVqRl4vRjIOo
TjFZHErFbncEEgxiTTBswzMJ0/laipyBTQp/tclUwg/ETQ4/szKJQ95V+wc2BZcC
Ds4K7II39E4oMx06V1o+bpoVR9pg6TfogSSRBnBPCJ0TTGHpPUwvjLeFXUN9/Uko
jIzD5OxBuvTwGkpgJnTBf9oqxUmz/xSN7SmVpwP0DZzGNkMSGuDNqlBRmXdXbQS9
0GgpFj8cZS+jTExhKl4IHAgQ54GYpwly0EvVLEWoZIAW/Xg5zjlYY0vXIw4k/Ds4
x6FPKn14XE0o0l9c958X+gcknOC9uqel1fXblCAUd7ue84CvhWcGGoS2XIlRfHOu
ER+cF/iC8PdsSJEF9sn/NW7XuBpnu0hU6zTOegR+Zu2asodNBEH+mWhMLspPeege
S6rUuIqcJxl8TlTtappcWGMXbPSIqmy+kaIWJvZ84IHhsz8/RDmzR9FPuJeTHIpU
vare4LueeDlXPfl7VN7rrQ25LIbkGXF0HISNbaOWs8g2SNNADS0ItD7mTTkJcBbO
hXCuBNUmb3vwP54spIo=
=ZN7l
-END PGP SIGNATURE-

Re: [gentoo-dev] Call for help: app-admin/chef

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

as app-admin/chef is still missing a dedicated maintainer and the
outdated version depends on a vulnerable library [1] plus being still
ruby19-only, we are going to treeclean it soonish.

If you want to help out here, feel free to ask in #gentoo-ruby.

Cheers,

Manuel

[1] https://bugs.gentoo.org/show_bug.cgi?id=540254


On 27.07.2014 21:33, Matthew Thode wrote:
 On 07/26/2014 08:38 AM, Manuel Rüger wrote:
 Hello,
 
 app-admin/chef and its related packages are currently
 maintainer-needed.
 
 So if you're using chef on Gentoo, this is your chance to step
 up!
 
 These packages have some restricting dependencies (e.g. 
 dev-ruby/json-1.7.7), that ruby herd doesn't want to deal with. 
 Currently two version bumps (one major, one minor) are missing
 [1].
 
 Ruby herd is willing to assist and help to work with ruby
 eclasses.
 
 Feel free to ping me on IRC (#gentoo-ruby) if you want to help
 out, otherwise we will have to treeclean it sooner or later.
 
 Cheers,
 
 Manuel
 
 
 [1] 
 https://bugs.gentoo.org/buglist.cgi?quicksearch=app-admin%2Fcheflist_id=2433248


 
I'm going to be working on app-admin/chef (client), might make a package
 for omnibus-install type thing from the deb they provide for the
 server.
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJU58fJXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNclGgQAL1TuC0kw7RMLeitgtRXRD0G
vWlE+WA6/+669NzSQkL54hJTORSo/3TBCitNIgVU9i0Iv5Sg+h5wHfsfaBuXC6Cr
cz3GzDmMrD1vvzwNZlT656Ax4qptElR1806hpxKrThdk02d1Jd6oajL9YO8GVe+J
ttIAVUlGOi17bd7wFatpSbBi+VNjX1+UKD9Frc+lLamCQqugigGbpX5cYaAa/5cb
cQlsRiKEaYmnnW4V4SUxVT+mVn8NHnR++q/88sNWZNyO2iwS2+18P1XkU1PANBaT
LixIBhKMS0LUXEJ4x0CRUlIPusBig31jk/JbeIDwZfLfUuweXjHFKj+YIeGtiPAY
TIeByho32u63xc7DO3EAfpDN0Ueag12hP1BHE1k9mh1xwZpXYsOBYdbwc9yOV1dt
+dvIUwEBSozKOKXkBcO76ulSHTMBM704+RkUWNaS47Gh1OBuLHU60HTwZvZ07fDw
rs3IpKp1iqvNKqO767FvKwl1L2jOtBIC+jJq6KBXOcqyUzZ2UGZWfqv6JLtuOZIY
/Hk4xJvWK2eX5vGaN3+y52N7jq3SvgS2IJymRaooiGn0Dbv/MVHMd9wIB010zIHJ
qPK2SAAQqULnwIsWiKu3t2p35/8gvBKcJiav+bv/elsPS7++FmDWjy69Cq9tK/IZ
H56WJGj1fVqwo+4h5E8E
=y+5N
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage news announcement review

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02.02.2015 22:58, Brian Dolbec wrote:
 
 sys-apps/portage-2.2.16 is ready for release and is just waiting
 for the news announcement about the new plug-in sync system being
 used and the changes in it's operation.
 
 Attached is the news announcement for review.
 
 
Please replace 3rd party with third party to increase readability.

Cheers,

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUz/iAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcl/wP/2r3gixo3A7jWYBb9nINzMVB
HzbwzlYYdE/HFGm6TQnT4DcP4QUiRze70Jr5H4mNsoD0Sw7lOL0cSb5B+jTsIYGc
qHp4DBRFJmA2fXEt2YUPFBrV4B4+9IGPWph3+kJpcolFTGmngNpBaacc17t0td07
YSMySK7DJyeC5ihHyXqiVEaj45AH+C/Ho4l6vzm1H0+UneKLyNOdPTQ20I38VYLw
1yeJx4eoltK7T53MyG9uFLnjOgM4r9x2Ak0IMu/oQ5b1GnB0bfa+KxP2ZMhjbdIf
esiEAbgcme2mIHMvyQZ6RLIhMdGxixhPtbM639KkOBE+6SLSHSoG8nUGFxbc5Ron
cCxeIy2kk5H269EAd/jnl1QdP2f6XvOCohoYyc7fHIxTPVGWc+quYTIbZDJx4bXY
cnXBL6dFSjab/VCL3ICWo7Pjlmc47QvsK/peEz0mttjRVQizrjb5uLZ5weA29lFt
L8w5yRJ01RY7EpGwfc7eaN+7GoUY0wlZYQ/1aBCErhz3/vZ+/enJ6NCat4/lyp49
RNABQlyZrijz2GLGC7dv8ts54pxUQ/QB1VTgNNnnCm/2wA/n462yXZKg4Z40RLNX
9ACOr0trMEOnsYaB8LHZ/2FRa753ehf4+8hRc1I181Hh96y8pYQ18sjsFhbJeEAf
g/yDygjBv9mpxGB6DPYt
=taxX
-END PGP SIGNATURE-

Re: [gentoo-dev] news item: nfsmount renamed nfsclient

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 30.01.2015 23:22, William Hubbs wrote:
 All,
 
 this is covered in the nfs-utils-1.3.1-r1 ebuild by ewarns;
 however, qa asked me to write a news item as well, so here it is.
 
 Let me know what you think.
 
 Thanks,
 
 William
 
 
 2015-02-02-nfsmount-renamed-nfsclient.en.txt
 
 
 Title: nfsmount service renamed nfsclient
I think, there should be enough characters left.
nfsmount service renamed to nfsclient

 Author: William Hubbs willi...@gentoo.org Content-Type:
 text/plain Posted: 2015-02-02 Revision: 2 News-Item-Format: 1.0 
 Display-If-Installed: net-fs/nfs-utils-1.3.1-r1 
 Display-If-Installed: sys-apps/openrc
 
 When you upgrade to nfs-utils-1.3.1-r1, you must also upgrade to 
 openrc-0.13.8.
 
 As part of this upgrade, the OpenRC service that handles mounting
 nfs file systems has been renamed to nfsclient instead of nfsmount,
 because it starts the nfs client daemons only, and netmount now
 mounts the file systems.
 
 If you mount nfs file systems, you should add nfsclient  and
 netmount to the same runlevel nfsmount was in before.
Add a command how to add nfsclient to a runlevel here.
Maybe something like that?
rc-update add nfsclient $(rc-update | awk '/nfsmount/ {print $3}')

 
 If yu are using OpenRC, for more information on NFS file systems,
 see
s/yu/you/
 the following url:
 
 http://wiki.gentoo.org/wiki/NFSv4

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUzBVVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcnaAP/3AHdZRWawN/Ehm1e47dcG0h
yn6Hl/GKsO5ujXPkUh5LaW/mZhf11En2RvrWzPVlAErYHjbH/nVHhHbtaLfEEk7S
PZSizEZl5gHmmH0ZrtOP9ok3ty0/F+56qAtTHoY5KWpGT1dyP7mPt9/KRmB6/pzW
orDStalxTxqOUzodveOMqRVh8x1RAqK44ImphEv9csz8/uclPZv/ty+P6NvizNzI
BF4julMUH3+el1OD73NyA41wDDiK+cUBCKqrGVoMUh9lmQ/4oFqgJuub/2PfEyQZ
Ba0hLdSx1ZfrDsrDJlmdAQRIidf3ZTuexwfr/ZUpUkvxvVomyNmipcbRxAfNNM0y
BuKmBOhGOMxYwni+nBbrr2U2T5WVGGXXSncQkj10GgguNrDmL75N4AFXW5vvOG/A
Yd9mFak1IcyNNU45rC6+mm0pGeDaaqsPAkEJLvlUrLifF4WMvUDFAogGNGWYAC4F
bIKP9XoVh6/PgbNKpAvI5coTUo1oKmB/xaNNRUttrXCZyRgTTOB7NrmXwvH7dliq
ftTfy1LQp8DVVe3aI3Nv7aM1MK6OX3FnEBYQ2kzJJkjNUD4+rh+UxsGLd/SEJSsC
1UpGgqQgRUJgtSlBxWczdEBC1As08CH++SKcLk3BWFxGWCEDOJsNz1itgKmBr0aS
Fb6Vlj2xVpcYfab0fH6F
=Jt+d
-END PGP SIGNATURE-

[gentoo-dev] Last rites: Further packages, that build only with Ruby 1.9

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Manuel Rüger mr...@gentoo.org (18 Jan 2015)
# Ruby 1.9 only packages, do not build with later rubies
# Removal in 30 days.
dev-ruby/flickr
dev-ruby/gemcutter
dev-ruby/ruby_parser:0
dev-ruby/drydock
dev-ruby/net-dns
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUvCaQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcVDYP/1UxCcMlMFdybea3BzmRJrd8
o1YHrK5JVzHZ4JuTBuy1wTKo+dnQpoy0HpvnK8Va8MFSaY3HUIhW5CY9J7zceKGr
7JnvvkVIlUfdJVPFlkhbGQjZRI0vZVdYTIRPB7yme+hVWYGwUipI50WVzCPrOtJW
2k4ou06+gVjVOMGvZXW8eFZoW5wZeGkylX6MoqeyufHV48XO+UqyZ71MAEBHFfli
cIfaLrjC3EXMdlr8PZrMQY133nn9JF7VId8qNQasBW9wepVo3ikgOMnEp1nDKwgS
3oGUemf3usHBiu2yS4nTyaEUr8uigNI6bhS/ZmSwwf5w0ZWGr+v165vuqjS00lmb
9QYnmFWy16F0r7ZkI7BY+FMzOISabusztwYqIbf7RHNby1zMIgErwjt5fUW/zorL
Mpspg7qSST0tbEXsszRhsi/VCA3UTptzZhjeDNyWdsXvxw7o6jI/H9tsWZbJcWH/
5hOnFXruFc4zodUxZqOyLf03WNWXFNy0rB4qI81O8xf+8uqcD/WlNC9J7Vf1GbwT
GpVLkEJR8HSjxuiIewho3JeoCk6nJYwfSOYIHm9QAci9uR6QlKG+Yaz49TrIM0vO
aCKp9D5DYkGAZTGDlvjiAzZvu/3ZARhXxl8SFhasExoDJfUax1lqgikangOw15ee
HaNjdzZDy6ZKYHahBDhh
=r395
-END PGP SIGNATURE-

[gentoo-dev] Last rites: rox-base/* and rox-extra/*; rox.eclass and rox-0install.eclass

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Manuel Rüger mr...@gentoo.org (17 Jan 2015)
# Unmaintained. Old eclasses, EAPIs and various bugs.
# See bug #533642
# Removal in 30 days.



rox-base/mime-editor
rox-base/oroborox
rox-base/pager
rox-base/rox
rox-base/rox-autostart
rox-base/rox-clib
rox-base/rox-launch
rox-base/rox-lib
rox-base/rox-session
rox-base/systemtrayn
rox-base/tasklist
rox-base/tasktray
rox-base/thumbs
rox-base/traylib
rox-base/volume
rox-base/xdg-menu
rox-base/zeroinstall-injector
rox-extra/archive
rox-extra/clock
rox-extra/contacts
rox-extra/diff
rox-extra/edit
rox-extra/fetch
rox-extra/find
rox-extra/gnome-thumbnailer
rox-extra/lithium
rox-extra/magickthumbnail
rox-extra/memo
rox-extra/mp3ogg2wav
rox-extra/musicbox
rox-extra/picky
rox-extra/resolution
rox-extra/reticker
rox-extra/ripper
rox-extra/rox-tail
rox-extra/rox-wifi
rox-extra/rox-xplanet
rox-extra/roxcd
rox-extra/roxdao
rox-extra/roxget
rox-extra/roxiso
rox-extra/songer



rox-extra/videothumbnail
rox-extra/wallpaper
rox-extra/weather


In addition rox.eclass and rox-0install.eclass have been marked @DEAD
and will be removed in 30 days.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUuszYXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNceLgP/ijIpkO/ruEnVGxd31XYcj+h
yITErG121GND1H+57gZJiQ0KfKCXiQc84Nnl46nFU5wNV/3hxyN3SDroPDmgcO3f
l66Z/I4356EEi926YvT7tvkfmOPdAPQp3UX8uR/olx6TSSvEW3DR2bBVOWDeKgE9
5ofNwUz6phz+rW0e+dDBQ4sCT+QkEzMT9NKqEwmGa+koPcVOsa4xdi5qhz9IGGuV
0b9Jd27UFWsbi9OpXBPyd1s3qHxWPJEBnxpapwwSQj0pZcId9LUaypF2otZ8YESZ
xe8iF+72YmyE5ExrN1udw/51OIiu8h5tOOYC31mJAddYctBxK8NUnPKhKh/JMq3V
kc8iJqwuLjgyKBFosw9PAA7ZCvKlWmkAwGloFFvegGDgRrEY8rVvi2L6s9ShST/e
WZnkEUQZ2qPTiZ0ypEQ3yD4NTo3FNhBlcA8FLNCxJiyaou0VohkTz/Us1eH/iNbE
LXAsJszXtyJVJRch9zogir6+Bylo2rUe/wntPHKoSuOgysEwMcZbHaGDTzWny/dt
MXYVsU9wtiDZWAY79P5MylWCzkZ9cp3/1LLogCO6UoYL1kCfCoywVhai6dlSjGR9
VPXxyev3qMqLTw15tlk3666JZIWHqGbNzhtqYdt+uAY7nS+qZqP2HGU1mQ3plPKL
GXBOby2q6VS3gR65+i4L
=fzsO
-END PGP SIGNATURE-

Removal of gpe-* (Was: [gentoo-dev] stepping out)

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12.10.2014 20:47, Angelo Arrifano wrote:
 
 packages: - * gpe-* We should probably talk about removal
 of the gpe category. GPE made sense when Linux in cellphones was
 still on its infancy. Nowadays I doubt anymore is using it
 anymore.

What is the current status on this matter? Is gpe-* still in
development/use nowadays?

There are several build failures on gpe-*:
https://bugs.gentoo.org/buglist.cgi?quicksearch=gpe

Plus
repo.eapi.deprecated gpe-base/gpe-icons/gpe-icons-0.25.ebuild: 1
repo.eapi.deprecated gpe-base/libgpepimc/libgpepimc-0.9.ebuild: 1
which need to be converted otherwise to a more recent EAPI.

Should I fill a bug requesting the removal of gpe-*?


Cheers,

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUrDWaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcD/wP/2KHCSnnj2eJL7FlNs4dDIQ8
61sAlHDMqoZ//evl8wOlxk5aKU/+cgzWNw1NFGhcmY4vs1T/q5B4b1uNONY+zSfl
9aiAOWlZlg5+9WTSQ1V+DbgMmAi//LwDHFI1rcYquEXkq/OqXVkAGCyH3clbmDJ9
7ZNx94GeT6iXzMOz0D/jg2TmWSry7rFr77kBhZDZ1QJBei5tMuJR6AmVzYgmwFv0
F0/uWD3KYGnhEWUdymvX+exJFcAVUfXhcjXHDqTpKnAa8ciYAOI5vAovtq6uhXSj
7chyBT6ENlY35oaY2zOwq5ySpkh/ezAw6w/FwOX/xvCiXiNqrvz7obWC4AaJ4Cr7
Z/vm7gUQhNjF1eLgcDfHYk6J7aWadkP1Dckiv48+GKMVvliekGgzFOiYf8jMlwMi
9ue3MfJOKtcX0hOY7LhgcOLVFelIv2iIaUJO0XmK/XOmRvTb1Pno+OXTNaaOkh3P
2Qg6o5EEeLYJXHBaM1TgHnHhtNE2c//3QiJU64zGUtgHsxUSPOSCSg4ik9BtjXAl
4no9ml5EjRHVxOVuHUk3WCY+f/8cvLgaMLmcHdWyN/KZGK+uXmBrSfC1r9UtDvEp
3+srFwkjlXlpzipnyyhxCruSRTqLo9JTFhbkDcqoyhlkV1kzsgzRTlQSNItfmpRJ
NTHS9JvGEfEIE1uOgwcm
=zCM9
-END PGP SIGNATURE-

Re: Removal of gpe-* (Was: [gentoo-dev] stepping out)

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06.01.2015 20:48, Pacho Ramos wrote:
 El mar, 06-01-2015 a las 20:20 +0100, Manuel Rüger escribió: [...]
 Should I fill a bug requesting the removal of gpe-*?
 
 
 From a treecleaner point of view, please do, to ensure we don't
 forget about this (also, if possible, pointing to the mail thread
 for future reference).
 
 

I've filled https://bugs.gentoo.org/show_bug.cgi?id=535844
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUrFcNXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcaaQQAId+nEW73T2pkCx+BkywSBqw
caQgiJQSDVozXNpNWirxXggAxGYL9mmzgQ5mrEpr7g42rbVnsSG76gBQxCU5jSW0
zgRVcv80OtkuLD2X/+ipKGpiuchgK7zlNslgVMrAV5MUjY6ANt75K4wfp6txVFWO
yP3qz2f/tP/OLJTs2kjyeBwDRDwLCnMYQJd1zb8K5OqqSuygLnt90bO8orGL4WQw
FPwAuZDzELUBrouGx4mlvhUv4112pePXjfOBl6TMHxaqAm4Mjk5F9DppXAkzqak2
I5YFGtRzRCKWJIOMNfBAlTOK9Kqn+YKHQ47mB51kaQDfUKjT7PYgE2y4f7TyEJS2
Wi2XfAr1Ygh2eaA0snp2Ec7HTILjgiD6U+MF0jufQAWyzThaioV8NxL5mQwpliTZ
VYDlZMXp/DijtrEU6krylRffXudbTLbg7XAw6rPLbsaOpQHjMyEJvHvWq7Fd14SQ
rAGAWRZtPqizdG5HVndFjQtYSGvSQNscZ2JVddNFOcXL+q+kpC2RSBynQwPlrQUn
mLNr6DgifBsSfOVkAowEuwj2wAZQ0ZvKhOvJREJaq2Q2XiVxO38n4VtX+pr0JqN1
Z+pNtfyc7X9Uunl6Gp19EZBt4Uwc/XdBUiuqNd1K6UyQKj1Spimgx5aJWr8FR1RE
L4rHfEiCFA4rKw3KOpXR
=/KbG
-END PGP SIGNATURE-

[gentoo-dev] Last rites: Various further ruby-1.9 only packages

[Manuel Rüger]

Next round of ruby-1.9 only removal

# Manuel Rüger mr...@gentoo.org (20 Dec 2014)
# Mask further ruby-1.9 only packages.
# Removal in 30 days
dev-ruby/awesome_nested_set
dev-ruby/directory_watcher
dev-ruby/gem_plugin
dev-ruby/mysql-ruby
dev-ruby/refe
dev-ruby/tmail



dev-ruby/twitter:4



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH] Update links to handbooks

[Manuel Rüger]

Since handbooks moved to the wiki, we should update the links.
Fixes also bug 532736.
From cc503f68dfa077b50aa5d316c1660203b801522a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Manuel=20R=C3=BCger?= man...@rueg.eu
Date: Sat, 20 Dec 2014 16:31:31 +0100
Subject: [PATCH] Update links to Handbooks


diff --git a/cnf/make.conf.example b/cnf/make.conf.example
index 6603b42..70384c6 100644
--- a/cnf/make.conf.example
+++ b/cnf/make.conf.example
@@ -11,7 +11,7 @@
 # example, quite a few packages have optional X, gtk or GNOME functionality
 # that can only be enabled or disabled at compile-time. Gentoo Linux has a
 # very extensive set of USE variables described in our USE variable HOWTO at
-# http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=1
+# https://wiki.gentoo.org/wiki/Handbook:X86/Working/USE
 #
 # The available list of use flags with descriptions is in your portage tree.
 # Use 'less' to view them:  -- less /usr/portage/profiles/use.desc --
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index fcc1a90..67e4b4e 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -9059,7 +9059,7 @@ def show_mask_docs():
 def show_blocker_docs_link():
 	writemsg(\nFor more information about  + bad(Blocked Packages) + , please refer to the following\n, noiselevel=-1)
 	writemsg(section of the Gentoo Linux x86 Handbook (architecture is irrelevant):\n\n, noiselevel=-1)
-	writemsg(http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked\n\n;, noiselevel=-1)
+writemsg(https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage#Blocked_packages\n\n;, noiselevel=-1)
 
 def get_masking_status(pkg, pkgsettings, root_config, myrepo=None, use=None):
 	return [mreason.message for \
-- 
2.2.1



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] New categories: kde-apps kde-plasma, deprecated category: kde-base

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

With things brewing in kde-overlay, we would like to propose the new
categories 'kde-apps' and 'kde-plasma'.

kde-apps will contain approximately 220 packages.
kde-plasma will contain approximately 30 packages.

KDE Applications, KDE Plasma and KDE Frameworks will be released
independently and each with different release cycles. It is for this
reason that we feel a new category for them is appropriate.

As there won't be any future KDE SC 4 releases anymore, kde-apps will
contain packages that already reside in kde-base. These will block
each other and we will provide kde-apps/*meta ebuilds for a smooth
transition.

Before we introduce kde-apps to the tree, the KDE team is going to
adjust in tree dependencies on
kde-base/foo
to
|| ( kde-apps/foo:4 kde-base/foo )
which will enable us to push a properly working KDE Applications
release to the tree.

'kde-base' category is deprecated now and will likely go away with KDE
SC 4 and KDE Workspaces 4.


Best regards,

Manuel Rüger
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUfd89XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNct1IP/2qC4mv7W4ntqaYTJdUk7pmb
6Mp3HYJTBAqCkbgMjNLTnEnasEvY3ErX6zvoi2XbSwjHI9MqvLVGZJNcHG5+7MGd
KDfpsW/CkIgO12ylmSsQu3FWRqki0MLRAPF7WjSKhmeUPzNgK02s+gY4Em7BrN90
ZeKbec+FtKfoQEqJ7qZku64WNNlFlh5/+y1QmccMEFV6iUYqTdtYaFjPbSJEoVYZ
PwAV/k90aJvgefTcnF6XMdTGG5nTROEbBxFik7kvzd7my96bbXeJQymVKhnMPrhT
/6upo0qPs66ZUyZ1lcIec++47G6omK/KhZENFbCwIR43eqzlA2k+HWwd42xKoxCO
t6rQvEaZgXDdY2kwscKWLYWhONiufZe2t+CKpIUHr5O09bXpKi+tcTvbu5a5jFX4
f5sVCetI0in7l9Kc5CpEW7QCfWvoTMEoPl/pK+22Yj0wVZ5aRmQIcML1I0Cmey26
hcoYrOks37HD07Xgh2Pm1vzjbNFUMKgWn5YN3tUzZ1qC2mMWbXfLJ2EgKx2aJcbo
RMDiKC9hEzlGqqpXb7+n9q0uA1EcUg0WH5stLlvR2574hp2j2pa5VbH5E8Q2oOvo
d6igLdkddWwWn6d6fdwfMA8Y7mYMHCwLgWXl1fX+cAgALBZlRSO5agIKcxDSK4rv
V1BtBvKGVgCeRxLEYkVc
=mvj7
-END PGP SIGNATURE-

[gentoo-dev] Last rites: app-admin/rudy et al.

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# No support for ruby 2.0 or later.
# Ruby 1.9 is EOL
# Masked for removal in 30 days
dev-ruby/storable
dev-ruby/rye
dev-ruby/sysinfo
dev-ruby/tryouts
dev-ruby/hexoid
dev-ruby/gibbler
dev-ruby/attic
dev-ruby/caesars
app-admin/rudy

See also
https://www.ruby-lang.org/en/news/2014/01/10/ruby-1-9-3-will-end-on-2015/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUfC33XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcWvgQALU+20V0XiNvw1mtFapWiUNY
yepCPI+A85BH6f0wvhwxG3oww/4BVcYCTT8dN9XtAVh+v5DQlCmrWZuuOdB4xLnq
C7c1pYYI9UPBvLO42+Ko4Tlc3swX7uIOc2DaeGtQnLoZpOenIh4GaGFSgLVLpYep
7FhJ4OdNl7aKqwPRPqLEZGv4w9GdIBb0/qe8RhGU2WfTbajkQBvX0Waf/7d7m+q8
YedHsI9VyfnLwHcgntLqX8QDG7/QKb+zAgKQrCjeCGGHcYDrX6a3JL65Hq/gnmov
Yq1MeN3GrIkZ48kIh55iM36g7OpXRbEYrgK0R++tEzMNDOaQEyDgMBwgvyL0v4+r
CkTBBi/qQ0fGETwM1iI0nHO4lyzx4R223LVp09U5D9uNUnM5GVLJ1tYLCNxKQN8S
2b8FlR2nlT4p8FebCJptB7KhPOqE3gNd4CvqmwolILht0cgH4cHe9EEffcXxg6w7
U9CXZuAGyH4mkKhUZnRaaF7Lc3OB4n0fvUbe7Qr9BHz4XoIi1Zg1OvhBWyolKxpB
XrxsCPGhS2RSk7aRHL4psMiYx8eiwEtBGZ0gHeSVAKTbZZH56L6f+xx00SavRYRY
rZ+F1LU50od04TP2ub1PgMNIFuWXTYC8AP5zM7gi5E9ptrm6NyhvWoQxR3aObveL
pFJthuJxLpJzLIazklaB
=01Rd
-END PGP SIGNATURE-

Re: [gentoo-dev] Packages up for grabs

[Manuel Rüger]

On 11/24/2014 02:17 AM, hasufell wrote:
 packages up for grab:
 
 I didn't change metadata.xml, nor bug reports for any of those, because
 I was too lazy. If you grab one, please do so yourself.
 
 
 sys-apps/etckeeper

Looks like this slipped in here by accident.
I can handle it myself, so I'll drop you from metadata.xml.

 co-maintained by ruby r...@gentoo.org
   app-text/jist
   dev-ruby/paint
 
Ruby herd can take dev-ruby/paint.
Please move app-text/jist to maintainer-needed, if nobody else wants to
take care of it. But keep ruby herd in it. We won't maintain it, but
we'd like to be CC'ed on bugs and help out on ruby(-eclass) related things.


Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites media-fonts/oxygen-fonts

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Manuel Rüger mr...@gentoo.org (6 Nov 2014)
# Use kde-base/oxygen-fonts instead
# Masked for removal in 30 days
media-fonts/oxygen-fonts
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUW+IeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc61cP/1FWtmr643gbri9fhDtnQqO0
2p3gB7PdIg36wThjYUZwx9lWovmOE45ZDMvK9ZWCaLkvmF3DmlM2eK3rwuZ3j0W9
00pEdMh4gjU6mVUZLkUloXvVxqDz7bim9U4bCZQo0lBnlVMHaaRtU+KjWvaFjCQe
+KdlGamDyxdNBMQp+OhPgWQu9d7kwa8seGvWIKPJEoEPdOMS7bBfHTYTp8wCje8j
aansMNAKsqlURSAus821deMTPd9QcywWN414VLpKeJuXl1rBueybrEt48RTQhOe+
wC8NuDno9Y9+fo7r2Zi1VSa1vkl2TiaBLZZlihSoP9M0XS6NLI/2Xn1tOonq/mqx
0VcatbRssRHWRTEi3qnFrOW7m49gtoZOh5ff375xV/uOOUgO59ZLu92OdczTzFgX
oAAZLIVLVcfiJmIf8cGX4teB+58IC4qCmY+G8kZ1gS6ijsk4y37j1R+oA3We9V9A
3eJx0qixYaHO/M9giOY6ffHYLNAx04560tIlGC6yTZ2yVuwmDor3//ShAbha9utf
pYYUZkGXtiJ4IcgqKbyI6i1uTqentqe1Gq7OOLFjBrSP9W8I405Ita1eseDWCQgx
ZGP7TKXPSSMapaLuGhkUIDIavy0RikZ/lDHGNto3uKg1vF5LtAc8G3MFCsARhl6i
4TpH4B6FX93zO/cSDnXb
=ZCIS
-END PGP SIGNATURE-

[gentoo-dev] Last rites: dev-ruby/prawn:0, dev-ruby/prawn-{core,layout,security}

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Manuel Rüger mr...@gentoo.org (6 Nov 2014)
# Unmaintained slot, move on to dev-ruby/prawn:1
# Masked for removal in 30 days
dev-ruby/prawn:0
dev-ruby/prawn-security
dev-ruby/prawn-layout
dev-ruby/prawn-core
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUW+KGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNclNUP/A6ou3ARedcRy+KFCiAuswBK
qCfXFAL5z9u0KZa1E+CQEZpI/CEO3GYDxIuZWChCggym9D5qw13HvM8t+pUWJMy0
+YqpOmqUkBdMUDGQ4Smu/sQD2BpY1m65xPnnwMEJgMnSkJ2XUpPhaGGm+Y5CaD9m
zL5sBep3ZOmzeWxrgNuBgUIV0LZ0nyvE+d4elAwBYvfYHdugTzC4egNUzNXBW2n8
NAsz5P6Y2uhFGKlx6bDsg6IUkFpxwcWPyZF8MwSk2pw5oF6aqDsU84+3ZbmYpNua
NfPjeBDwNZhV/6TDk8Ybhy3ZuGoHb4xSoW/dWe/RyEGobhTqRtEPyoJbMDv2OMVA
G8BMacjZJ9+DSZAh+n9xKQynubT3XXQO1is/mt/Ta+J02ATzS8Rwp7FvWSSGbd6s
5L6mbVQ6T8XZ4mGvlrUBfc8M72E9GfiDRKmTklRsHqBiE4WNnkynxklzq5zLXZ9q
BkrZVDiNT/CNtAT1zfqYQxMf1MG/bHBmms041F33LK/aAtzrEU/c9PhBERaGGI3S
oawoUalnI35i8EnwD3GkI54fb9MO+9sZwiRD/aMhT/vrIgJ0da3Y7Hn6s/DWXq9m
xIGPOA0/lz0dNpX9MK5kTyy17RM3shGYs6REvReePF0sNvU5olnDBr2YIPsgiIBd
PBzS2ROb5dQAbnsSStGH
=pH0t
-END PGP SIGNATURE-

Re: [gentoo-dev] Last rites media-fonts/oxygen-fonts

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06.11.2014 23:19, Jeroen Roovers wrote:
 On Thu, 06 Nov 2014 22:03:26 +0100 Manuel Rüger mr...@gentoo.org
 wrote:
 
 # Manuel Rüger mr...@gentoo.org (6 Nov 2014) # Use
 kde-base/oxygen-fonts instead # Masked for removal in 30 days 
 media-fonts/oxygen-fonts
 
 That one wasn't up for a pkgmove?
 
 
 jer
 

It could have been introduced to the tree as a pkgmove, but it wasn't.
The best solution for now is imho to lastrite it.

Manuel

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUW/nIXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNciz8P/j7y7KEWrZ3B30iSeIco3dHf
vWReIbdt9/h8VBl1LH8q+rSvB/AckpuMZunoVBCCgBk58aK9gu3z1oRqs+vxbros
+RwCyDATfDhZRwkCCeQ7xqPto1FC8Uca4xCJHLUBlSkRwvnZcg7ZH2EAlXAwcldI
NP/nvKuDI3BGaQGp9YuorD0MbnvJzgrRX1CEqgQb82cN0zgBoIJ/dS1On9Yl1Qs/
4yA+QoKnDaSFnmpI3AZoL39E3Ygvq1B5pJbZ4O1Docd/1MhESpar2VieUcb/F14g
STrYtGvWIIttlNlwqobJXTMzxrRJVpF3x9zqFrVXFypjzH2uV0Ipb5/lAHFgSj1r
dmsHwx/lbsu1NqCt/eFqIxVfb9CPmiCavLb2zdySTUx0t1F6pVJcG+9IvsVjBLcR
DD437AAM6t4BpiFr9fcGc4XyjY84n8oNGL+8B1vYiilAzUAFC/7PjgEfK7yWF4RF
TIYhw2Fquuz1GT9DLFlWeFGge36p/Cpm2n2JlWnf97yPn4dTmEqDaQCiAwRlcKJL
TB2nZTjVIrDLOMV0I7AN4sxXhNze/ci8tlSKo6W93e/AXn6XXrCeXgbmDV/PfZfm
KMAYsIN4XRLQlJQaPnckr2iPfBO9rFVMwXEYd/orBFdYbK+fasI9VDDAOth/lwNm
DzEo19bRVc/Nbm3usWO2
=mkWh
-END PGP SIGNATURE-

[gentoo-dev] Last rites: net-print/foomatic-filters-ppds

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Deprecated by upstream, Debian removed it in 2010.
# Contents of this package moved to foomatic-db{,-engine,-ppds}
# and cups-filters.
# Masking for removal in 30 days.
net-print/foomatic-filters-ppds

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUS8tYXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcKWQP/3NOhheSMwswhk3pO7p98juW
s78boQxlhUUB56O9Wd0pLEXwz8KLdwEf5plJiDCTQ1ulxs+SNNMJoR0/rCCr3a6+
h7v2rKsjoLhglRmxKFQJRg4akd8ZShLsP74wMXWQ6kPri8H97V70KWdBGMuQV9Zd
71Kr/LcD9Qvl1+OSm7/qg43dPX9LWQa3yhLlUGnsKVD9juzFedDhquL6O+HRIS7S
Ekjop5xkTsw/o5C6GBXabSPasp9Rw9p+0/BqSQJpo+yxsetbyv7eRMUnKfXnwqOu
6Q4SxZdsPBchkRjcoD1ClpwlHZF56fmlgBODDI5G6hi2a/RkYgP9nsqYDbB+LSLg
4Ko/BSEiFLkad94398oBf53dcxbhBaXb8K9/CI/9hpSOdbXSZuyKl22k7TDQ6Hxw
6VJo/gazDMMeU2oZTO/LSj9BTC7limh0hhkKhxvk8pGggMfkf2ilciXgVlrEaz4T
XwYR/Qt2VnIZl+kn8VAR8F0dLQ9scBRfB7n1Jb8QTNT5IdvbpMz6EyLtCu0DKgfQ
4LS2JVPkiAWE/AwPy/mFzuJXHM4ySLtgLXmfz1MRupDkcmpHaQD2WdT4oQ+vcFNq
uY6yWI/uFg4XTDvpuPPu+nDctTCBW7GDeGvmMVt4q7VnHKCKcoR7I0t+HrOyxWV1
rcQs4ExZzzG8Ry1sXlOk
=hpf9
-END PGP SIGNATURE-

[gentoo-dev] last rites: kde-misc/kcm_touchpad

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Manuel Rüger mr...@gentoo.org (11 Oct 2014)
# Dead upstream use kde-misc/kcm-touchpad instead
kde-misc/kcm_touchpad
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJUOI5KXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc1FIP/3sMQuC8Q/p0R2l6jHq4RDyL
2VNJ6gKBuN3fPhVMef5V8eFRoa56v8mPS7AhoGZWjmjnJqxzH5RqgovpyLadwoNi
84gHtu3RR99xewwAdV/6vhxPnzUmXvkHByN6Q37m06A/Tw9m+iQVL/opZeICYomZ
8+i1WfsJM8TMKF9yrnTR0wsj+z9XYEw76nSSqqmczY8SZHygjoqSdpRaYDqh17Hs
/HiCmVVrbxHTGtPpml3iw88SUdNJWi8rBwqdYf1+pxwfEcpXpDFsXUPYdVO2wSKs
wRfaUYM4EmaTIDbvr0KIiEdO3dktJ3TlRzbqc/a9FlLeBF10kZKHyDX7SgBFcRGQ
S+v1Vl5ymimWmz/cCDTY6AP2D2qTPI2sj4rxUBcehpcQdYZB/SsGETd4e1GvGC/3
wz4FPBpBAQm8hyL72cZEYbClLJpmf/mY1SPpx4ALefAkcuVfKvXBac+/bnHtZX1X
hfHlB7G8AQnVskCLrxiKidxgJxUrdsFgtm7xr6lnpgHHYiD1xkpoCNjv8mL8FgOh
Iy8yBcgLof7ezRk1kwzAuZ+q9vVUiIEY+CFjBduIpi6LuuWf37iLp7MTY5SHP9+H
QM2za9Vo3LIoPZmkjzspMsoqaRp5IDPo55eaVc6uut5CGgHkoxUkVRDAVfI9Dltp
wDlfuY7QKps1DUWa2B8b
=maJX
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: mysql-5.5 upgrade and mysql-5.1 mask news item

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/14/2014 09:58 PM, Brian Evans wrote:
 Display-If-Installed: dev-db/mysql-5.5

Display also if virtual/mysql-5.5 ?

Maybe you can add an additional note that mariadb is now the
recommended mysql package?


Cheers,

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJT7SBeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc9gwP/RFJ1EfTd2BsaoSNy7arE6AX
uBt0SC9k7iPcC3fT0qEd39Zr3fRyuphQltef+BytTlGvWORpnca5y99XUEqt9Xoq
/EgXnQ3CjAQQQe3zn5D78sOaTLxP0rh7Obu0kA1hDhgjT7244WMye5Srof8VkdPz
AArcsGBYU6Wj1j+3FmAMh3IbCeojS5WqAm2b+ur111WYulOG7Y0Z3r+YRN4OzTsm
iF8e92/PBwtOywEFCP3wOPZKCaZ0lvNs8QoD6XvYqodLdmo/caLj16N+VxAFb77c
2JVUyTOxGwmYh5j22pBpU9hbRo6zDikTQZudAyq6EWXrxTs2DRLPMhXVp+B8RGjR
55hFPlcjaHmwF9CZMsLF0Yi5AaVXGVcRuHroMdPyxY0dyI9OGcpEXXZRiKpc34Ro
WJiHf16ojaaNoFYoYR0X9X+0zbgnemwo9ULHeKo6lINEV508Y6U1qilB+VYwXc3X
J2hBb3Dg1+bpRGVkOh06FscDzubE0CobAmWkgpmXrYevSQvzC4FKe+DZbg3kTYbB
iC6Z+ZScUG4ncaQpiWHksl185Xc2Cc/3q4T33kD044ZiQbiQnTuj0bapVkf6RcAa
aH8AhrcZHSbaM19ADHhIPZf+T7TyYpDSxlP2QMlTZfs6rxIbiHUFfiijHj0ExO2c
dS415hDgMyULIM5cUQ7q
=/Uj4
-END PGP SIGNATURE-

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/12/2014 03:48 AM, William Hubbs wrote:
 On Sun, Aug 10, 2014 at 03:22:11PM +0300, Sergei Trofimovich
 wrote:
 Hello World!
 
 TL;DR: This evening I plan to mangle ~3000 ebuilds in the main
 tree by dropping trailing '.' in all 'DESCRIPTION=' fields
 (except etc. case)
 
 Long story:
 
 As you may know newest portage release 2.2.11 got a minor (but
 chatty) QA warning: DESCRIPTION ends with a '.' character
 
 Why is this a QA warning in the first place?
 
 I don't recall a policy mandating that descriptions can't end with
 '.'. I asked our QA lead about it and was told that he didn't
 recall that we have an official policy about it either. Also, the
 devmanual never mentions any such requirement.
 
 If someone can point me to something I'm missing, let me know. 
 Otherwise, I think the warning should be removed.
 
 William
 

These links might be helpful:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=06637c4215d55c57517739214c6e0fd6f8f53914

https://bugs.gentoo.org/show_bug.cgi?id=438976

http://comments.gmane.org/gmane.linux.gentoo.devel/80786


What's still missing is a patch for devmanual (if we still really want
to enforce this).


Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJT6XUCXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcJ8kP/RPn7b+TO/KJef2qdkuDQ7r9
6A86HEylCFMoKDJKk8jV4ne+Ns/zDydiD+JNWidOfdNpiVHbs9FA+WYW+mLzo4dB
MvcsQ03afPC320z817RAYjPJAg+SRI+RmTy+0d9v65wuwjowNY+uOReCAvjEBiCu
Qe5yEmMzhrGDud+xV7RveNsByXhSmZuDxFM+qsDc/+T2iBf+oX1x7jKSd9rMQP5d
A/Q6dB3/54QQxkAkawFMuyYl/FX2WvE/QSDqJD8S8R7KWM2nEGNP9S7F83F6RZJd
yPrV3GpVwrY/A7K995MHCkdM1/lSg2h0+48Q/P4frJCvE5yfAkYYmo0THx/7/DNA
XVpcrq1/31wgmYATa1qacF6NHSwWqt0+JMQTn4HDw8WajIkdiMbJ4x9VIbFcvRT2
GcbsE2zPYEeybK7OdslA9V6Am8M0rDWby+r1S+QKwTvWXJDRQndUmrNTD5riLU8R
RG+vhLm+U+u2tSn9Cy/jhl+H3mgVkZ1Fmk4Gnw4Nvob1Vxxc8bWzzppDCu2gZWVS
paz97341YghYUdx3rknU8cat8J+sYeEx26b4s5Dvj9o9WOpQBIRMfzBQ3/nV8hK9
imlgNCHMaBYvwKM0/yn+7Jm/+JU+STmhexL0dBkja1LgfbGWcNRQeuXh881cU1WN
Am75VVTGrpU9FPN8IqIc
=bmFg
-END PGP SIGNATURE-

Re: [gentoo-dev] About current ppc/ppc64 status

[Manuel Rüger]

On 07/26/2014 11:09 AM, Johannes Huber wrote:
 Am Samstag, 26. Juli 2014, 10:44:26 schrieb Pacho Ramos:
 El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió:
 El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
 On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
 On 07/25/14 15:50, Pacho Ramos wrote:
 El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió:
 On 07/25/14 15:28, Pacho Ramos wrote:
 That is the reason for me thinking that maybe the way to go would
 be to
 do the opposite - keep only base-system and a few others stable
 and
 drop stable for most of the rest. This big effort could be
 accomplished
 in a week by other developers willing to help (like me) and would
 solve
 the issue for the long term. I guess that is what HPPA team did in
 the
 past and I think it's working pretty well for them (in summary,
 have a
 stable tree they are able to keep stable). That will also help
 people in
 ppc* teams to know that the remaining stabilization bugs, apart of
 being
 much less, are important enough to deserve rapid attention, as
 opposed
 to current situation that will have some important bugs mixed with
 tons
 of stabilization requests of apps that got ppc stable keywords
 years ago
 and are currently no so important.

 Yes, please let's just do base system stable.  I've been randomly
 taking
 care of ppc but nothing systematic.  Its pretty spotty.  But at the
 same
 time I don't like the idea of just loosing all the stabilization
 effort
 on the base system, so that might work best. Something to think
 about
 for mips too.

 Nice, one think we would need to discuss is what do we consider base
 system :/

 I guess packages maintained by base-system, toolchain and...
 xorg-server
 and co... what more

 Not sure if we could have a list of current stable tree for ppc*,
 once
 do we have that list, ppc* teams can drop from that list what they
 want
 and we get a new list that will be the final result. What do you
 think
 about that?

 At the very least, its what's needed to build the stages with
 catalyst.
 I would think we should start with base/packages, but I don't want to
 limit it to just those because I at least need a more for building and
 maintaining.  Where should we start to compile such a list?

 If we are going to do this, I think we should drop these arch's
 to exp status in the profiles. That way, it keeps repoman from bothering
 the rest of us about stabilizations, and we don't have to worry about
 filing stable requests on them.

 That would let you stabilize things that you need to build the stages.

 William

 But, moving ppc* to exp wouldn't lead us to likely break their tree?
 (because we wouldn't get any dependency issue even with base
 packages...)

 I was thinking in this plan:
 - Get a list with all packages stable on ppc
 - Drop from that list what ppc teams want
 - Run on all that packages ekeyword ~ppc*
 - Run repoman to the full tree to fix the dependencies, use.stable.mask
 some, tune the list of stable packages...
 
 ++ from Gentoo kde point of view
 

+1 from ruby.

How do we solve keyword requests?
https://bugs.gentoo.org/show_bug.cgi?id=477648 is ~ 12 months and hasn't
seen any reply from the ppc* teams.
https://bugs.gentoo.org/show_bug.cgi?id=497396 ~ 6 months
https://bugs.gentoo.org/show_bug.cgi?id=487206 ~ 9 months
https://bugs.gentoo.org/show_bug.cgi?id=487178 ~ 9 months

We can start dropping ppc* from dev-ruby/* if that eases maintenance and
gives you more time for core packages?

Cheers
Manuel



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Call for help: app-admin/chef

[Manuel Rüger]

Hello,

app-admin/chef and its related packages are currently maintainer-needed.

So if you're using chef on Gentoo, this is your chance to step up!

These packages have some restricting dependencies (e.g.
dev-ruby/json-1.7.7), that ruby herd doesn't want to deal with.
Currently two version bumps (one major, one minor) are missing [1].

Ruby herd is willing to assist and help to work with ruby eclasses.

Feel free to ping me on IRC (#gentoo-ruby) if you want to help out,
otherwise we will have to treeclean it sooner or later.

Cheers,

Manuel


[1]
https://bugs.gentoo.org/buglist.cgi?quicksearch=app-admin%2Fcheflist_id=2433248



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined

[Manuel Rüger]

On 07/25/2014 08:49 PM, Ian Stakenvicius wrote:
 Hey all..  So, putting aside for now how much of a mess this would be
 to implement in the virtuals' ebuilds themselves, what do people think
 of changing the virtuals so that they contain an entry in IUSE for
 each provider that can satisfy it?
 
 The idea here is that the package satisfying a virtual could be
 optionally explicitly-chosen through package.use (or USE= in
 make.conf, perhaps) instead of having an entry in @world, that way if
 nothing depends on the virtual then it and the provider can be
 --depclean'ed from the system.  The idea is specifically NOT to have
 rdeps depend on these flags, that would undermine the whole purpose of
 the virtual; it would just be for end-users to set if they so chose.
 
 This may also help with getting portage to peg a virtual's provider to
 a specific package instead of constantly trying to switch from one to
 another, ie, how systemd kept getting pulled in, in relation to the
 upower virtual.  Note - I haven't done any tests to determine if this
 actually helps with such issues tho (or even attempted to reproduce
 them, as i was apparently one of the lucky ones that it didn't happen to).
 
 I don't know if this would aid heavy binpkg users or not.
 
 
 For completion, here's one of those rather messy examples:
 
 --- virtual/krb5-0.ebuild   2013-06-28 09:04:47.0 -0400
 +++ virtual/krb5-0.ebuild.new   2014-07-25 14:47:48.0 -0400
 @@ -2,7 +2,7 @@
  # Distributed under the terms of the GNU General Public License v2
  # $Header: /var/cvsroot/gentoo-x86/virtual/krb5/krb5-0.ebuild,v 1.2
 2013/06/27 20:42:55 aballier Exp $
 
 -EAPI=3
 +EAPI=5
 
  DESCRIPTION=Virtual for Kerberos V implementation
  HOMEPAGE=
 @@ -11,7 +11,12 @@
  LICENSE=
  SLOT=0
  KEYWORDS=alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh
 sparc x86 ~amd64-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos
 -IUSE=
 +IUSE=heimdal mit-krb5
 
  DEPEND=
 -RDEPEND=|| ( app-crypt/mit-krb5 app-crypt/heimdal )
 +RDEPEND=!mit-krb5? ( !heimdal? ( || ( app-crypt/mit-krb5
 app-crypt/heimdal ) ) )
 +   mit-krb5? ( app-crypt/mit-krb5 )
 +   heimdal? ( app-crypt/heimdal )
 +
 +REQUIRED_USE=heimdal? ( !mit-krb5 )
 +   mit-krb5? ( !heimdal )
 
 
 Thoughts?
 

Thinking in another direction:
Would it be possible to introduce pseudo-versioned useflags?

This would solve a problem for virtual/libusb just with adding
IUSE==dev-libs/libusb-1.0.18

virtual/libusb-1-r1 depends on either dev-libs/libusb or
sys-freebsd/freebsd-lib. The latter one is only compatible with
libusb-1.0.9, so packages depending on dev-libs/libusb-1.0.9 can't use
the virtual.

Assuming freebsd-lib becomes compatible with dev-libs/libusb again,
packages will have to switch back to the virtual to support both.

Depending on virtual/libusb[=dev-libs/libusb-1.0.18(+)] instead would
just need a change in the virtual.

Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Default HOMEPAGE for packages with unavailable website

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi everyone,

currently there is no default link, when the website of a package
becomes unavailable or never existed at all.
I've created a wikipage, which can be used instead of filling HOMEPAGE
with www.gentoo.org or non-valid urls like none.

Please check your packages and update them to this link:
HOMEPAGE=https://wiki.gentoo.org/wiki/No_homepage;

Feel free to add further useful information to the wikipage.


Cheers,

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTzT4+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcIQ4P/2RI964BhJFXrewAGs7lD2gR
7RKWYRS8Psm68E5oR3p+4LNFASlEyZttFxEh++DnVxGAE9Te6A7nygnFQ3T39kEb
7htpADGPqWI4UGGKdck7+6Kgnfmr8SNhBCg4yFdiICxL6UM130/pnXdReH7eT5kQ
SqD1ymPQCSwxNZLEAnKeyiBuseKilVxZTzvHMdwHSEdt1+YI6XiuB21TAsMF8PJI
n1sWc6bUNaaoGSwQ6nqtSc4zMeTZTFEmNredxP+zr489R4znZeN3nsxqqOchVJ7o
FNUilTuLFRjtvh6V+12Dum6dIwE+fOfpsf2lExWam1wpC3I+y70JAFUpoWkYHS7H
tycA02byNM775FcAenewIhjVjyd+Fkqo+k6DgWz7O02Tt9oaHWy34y0Kku3ErFAH
dcti82gPALGaLuiNUAxVZ0o2SQ3a/+neVr2xg7j4MC6dirxzG0pOCRaStWd7qu05
GSvSHnEd2q2/U9DVyIWj7ArTUtRpAs0o/rvviMM9EICR4eCp2qNF0fXbDPLgvuBM
jwxXlGmubAIxcIuJ5hxcyj6BmjgJstIcQPB6fcqwza2SC/6Jjb2htSew1qZWXtqS
TITi6jXKZI3o6Bkeow5PI0VdCYRz2fuqlFULee3+WZrsn1DxCtQaRMFbsnC6WOAG
nXgo5EyRP4Tz8u63NtyX
=Ygfo
-END PGP SIGNATURE-

Re: [gentoo-dev] Default HOMEPAGE for packages with unavailable website

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/22/2014 01:20 AM, Gordon Pettey wrote:
 On Mon, Jul 21, 2014 at 5:06 PM, Alexander Berntsen
 berna...@gentoo.org mailto:berna...@gentoo.org wrote:
 
 On 21/07/14 19:41, Ciaran McCreesh wrote:
 What's wrong with HOMEPAGE=() ?
 It is not very informative.
 
 The wiki page is equivalently informative. What's the point of
 metadata that just says there's no metadata?

Users expect a url, not something like () . none or anything else.
The url gives information, that the website is not available anymore -
as it is part of the url itself: No_homepage.
The wikipage gives hints where to find further information about the
package.

Cheers,

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTzafuXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNceDUP/3BbUqqJz8uUXV35D9IDCFSZ
/Ei3SxEy6/wCojyE9e/2hmuSo6fsdujNRB9VCGIHWoz8WfhZJSQktuXgXzyP8zbD
M6CBWcnx2xWpqYZBECoh6+jdltySWVu5YWZXX6gShlID9dhfLt9hRzBeL9YNGQ7J
deI8pDnbWP2LY+9CUPydXyQCr2N6hfXAfOhmTyQlfsr2JoA7AVFDTL0w+q5U4v/X
ss92kpi+joCHeJKRLsyVQk8HQMTKUZ6bgbXXvt/eb9ppuc+U4uVpmejiflMnq2vL
vfuH+KHNNrnj450UYgtaXnIn8Ot2VxC6X8+GR/PsDL7xqn6kcQgFk7mtgx/IZImq
EhyjCpNc/DEfqSmGA7fe0feOlTCTsDymocS+2TAN+ZkLV/WdJzbmMzuK6gkdntOe
MNRo05do2B2serYrOCFKm6ql7CrI0+68Dsnpd8P4tONugzL6g4Wg2uK3D3zrutD5
blS3m4rtS5VVMwhuNefFockJxkTVtR+q3Gc3ES9kYaTdA7TL5EYF/bHWVBdwk9BM
b+ZtJUyo2PQXVRxdURRWF4IDQwDoCS1kjeovameLo3QdLMakMQTmGGUPzpqoOKgh
3u8cFg+RelmJzgxKvUfM2H892RLXpvhuSLY1wGicdJeOYpxlEl5wtaR6KlKpv0xS
EUnC838zhcRGVSILaIx8
=ZtUb
-END PGP SIGNATURE-

Re: [gentoo-dev] splitting out arm keywords

[Manuel Rüger]

On 07/09/2014 01:40 PM, Anthony G. Basile wrote:
 On 07/09/14 05:09, Joshua Kinard wrote:
 On 07/08/2014 21:48, Matthew Thode wrote:
 arm has a historical problem with stabilization, while keywording
 doesn't require access to all arm sub-arches the problem with the
 stabilization slowness causes running a full ~arm to become hard.  By
 that I mean that if someone keywords something for arm because it works
 on armv7 and I run ~arm because stabilization takes forever then my
 system may break because of both non-stabilized packages and because I
 could be running armv6.

 In any case I propose splitting out arm into armv4, armv5, armv6 and
 armv7.  armv8 seems to be here already as arm64.
 Couldn't this be better handled with some profile work?  These sound like
 versions of Instruction Set Architectures.  In the MIPS world, you
 have your
 original ISAs, mips1 through mips4, then you have the newer variants of
 mips32r* (branches from mips2) and mips64r* (branches from mips4). 
 Anything
 supporting mips4 could also support earlier ISAs.  Throw in our three
 supported ABIs (o32, n32, n64), and machine-specific curiosities (SGI,
 Cobalt, Yeelong/Loongson, etc), and life can be quite fun.  But we can
 cover
 all of this with just a single 'mips' keyword in the tree.
 
 Yes, this should be done via the profiles.  Code requiring later ISAs
 and/or with extensions like thumb and neon will probably break on lower
 ISAs.  These should be masked on the profiles.
 
 Is that similar to how these ARM variants work?  Can an armv7 run code
 for
 armv6 and earlier?
 
 Its a bit more complicated that MIPS.  You can test for yourself.  I did
 this via a chromebook (cortex-a15) using my hardened stages
 (march=armv7a) available at mirror/experimental/arm/hardened, so you
 can test too:
 
 chrome ~ # echo int main() { return 0; }  test.c
 chrome ~ # gcc  -march=armv7-a -o test test.c
 chrome ~ # gcc  -march=armv6 -o test test.c
 chrome ~ # gcc  -march=armv5 -o test test.c
 chrome ~ # gcc  -march=armv4 -o test test.c
 chrome ~ # gcc  -march=armv3 -o test test.c
 /tmp/ccZjsI2O.s: Assembler messages:
 /tmp/ccZjsI2O.s:45: Error: selected processor does not support ARM mode
 `bx lr'
 chrome ~ # gcc  -march=armv3m -o test test.c
 /tmp/cc1o59kQ.s: Assembler messages:
 /tmp/cc1o59kQ.s:45: Error: selected processor does not support ARM mode
 `bx lr'
 chrome ~ # gcc  -march=armv2 -o test test.c
 /tmp/ccmTNSyh.s: Assembler messages:
 /tmp/ccmTNSyh.s:45: Error: selected processor does not support ARM mode
 `bx lr'
 chrome ~ # gcc  -march=armv2a -o test test.c
 /tmp/ccTIXZ46.s: Assembler messages:
 /tmp/ccTIXZ46.s:45: Error: selected processor does not support ARM mode
 `bx lr'
 chrome ~ # gcc --version
 gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3
 Copyright (C) 2012 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
 
 So it looks like gcc can emit compat code back to armv4.  This doesn't
 necessarily mean that armv2 code won't run on an armv7a, but that
 gcc-4.7.3-r1 can't produce such code, which is sufficient for our
 purposes of masking.
 
 

 Splitting 'arm' into four new keywords, on top of 'arm64' is just
 going to
 give you guys major headaches later.  You might even consider
 dedicated USE
 flags for the arm subvariants and use those to control things in an
 ebuild
 where applicable.
 
 arm64 might as well be a totally different arch.  There is no
 compatibility between 32-bit and 64-bit arm variants --- at least not
 that I know of, its a new arch that I'm just now getting familiar with. 
 On the other hand ppc and ppc64 should never have been split, but that's
 another story.
 
 We do not want keywords for every subarch otherwise we'll go crazy
 stabilizing.  We could adopt a policy of stabilizing on armv7a and when
 a package doesn't build on a lower ISA, just mask it in the profiles.
 

 I think this would be beneficial because of not all developers that want
 to help with arm have or what all the sub-arches necessary.  It also
 allows us to move faster on stabilization because most of us have access
 to armv7 a bit easier.  This would take some pressure off of the people
 doing stabilization for older sub-arches, but not much.
 What's the support status of Gentoo on the older variants, such as
 armv4 and
 armv5 stuff?  How fast is the CPU clock on those?  Do they include L2/L3
 cache?  Lots of memory?  Generally, anything that could be a
 bottleneck or
 severely increase the build time should be weighed against the potential
 number of users and possibly support dropped if there aren't enough
 developers or contributing users to maintain it.

 I.e., w/ MIPS, we don't support anything under the mips3 ISA, which
 includes
 DECStations (Debian does support those).  Build times would just be
 tremendously slow and I haven't seen a lot of desire to support those.

 
 Regarding MIPS, 

[gentoo-portage-dev] [PATCH] Add support for travis ci

[Manuel Rüger]

This patch adds support for travis continuous integration.

Example output: https://travis-ci.org/mrueg/portage/builds/29268364

Cheers

Manuel
From 3bee849868cf53fb5814f81fa368e91b59f7220b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Manuel=20R=C3=BCger?= mr...@gentoo.org
Date: Mon, 30 Jun 2014 18:13:51 +0200
Subject: [PATCH] Add support for travis-ci.


diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..c114a4a
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,10 @@
+language: python
+python:
+ - 2.6
+ - 2.7
+ - 3.2
+ - 3.3
+script:
+ - echo $(python -V 21 | sed -e 's/Python//' -e 's/\.[^\.]*$//')
+ - sudo ln -s /usr/bin/python /usr/bin/python$(python -V 21 | sed -e 's/Python //' -e 's/\.[^\.]*$//')
+ - ./runtests.sh --python-versions $(python -V 21 | sed -e 's/Python //' -e 's/\.[^\.]*$//')
\ No newline at end of file
diff --git a/README b/README
deleted file mode 100644
index 5558dde..000
--- a/README
+++ /dev/null
@@ -1,49 +0,0 @@
-About Portage
-=
-
-Portage is a package management system based on ports collections. The
-Package Manager Specification Project (PMS) standardises and documents 
-the behaviour of Portage so that the Portage tree can be used by other 
-package managers.
-
-
-Dependencies
-
-
-Python and Bash should be the only hard dependencies. Python 2.6 is the
-minimum supported version.
-
-
-Licensing and Legalese
-===
-
-Portage is free software; you can redistribute it and/or
-modify it under the terms of the GNU General Public License
-version 2 as published by the Free Software Foundation.
-
-Portage is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with Portage; if not, write to the Free Software
-Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  
-02110-1301, USA.
-
-
-More information
-
-
--DEVELOPING contains some code guidelines.
--LICENSE contains the GNU General Public License version 2.
--NEWS contains new features/major bug fixes for each version.
--RELEASE NOTES contains mainly upgrade information for each version.
--TEST-NOTES contains Portage unit test information.
-
-
-Links
-=
-Gentoo project page: http://www.gentoo.org/proj/en/portage/
-PMS: https://dev.gentoo.org/~ulm/pms/head/pms.html
-PMS git repo: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git
diff --git a/README.md b/README.md
new file mode 100644
index 000..bed2ca3
--- /dev/null
+++ b/README.md
@@ -0,0 +1,53 @@
+About Portage
+=
+
+Portage is a package management system based on ports collections. The
+Package Manager Specification Project (PMS) standardises and documents 
+the behaviour of Portage so that the Portage tree can be used by other 
+package managers.
+
+
+Dependencies
+
+
+Python and Bash should be the only hard dependencies. Python 2.6 is the
+minimum supported version.
+
+
+Licensing and Legalese
+===
+
+Portage is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License
+version 2 as published by the Free Software Foundation.
+
+Portage is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with Portage; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  
+02110-1301, USA.
+
+
+More information
+
+
+-DEVELOPING contains some code guidelines.
+-LICENSE contains the GNU General Public License version 2.
+-NEWS contains new features/major bug fixes for each version.
+-RELEASE NOTES contains mainly upgrade information for each version.
+-TEST-NOTES contains Portage unit test information.
+
+
+Links
+=
+Gentoo project page: http://www.gentoo.org/proj/en/portage/
+PMS: https://dev.gentoo.org/~ulm/pms/head/pms.html
+PMS git repo: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git
+
+Build Status
+=
+[![Build Status](https://travis-ci.org/gentoo/portage.png)](https://travis-ci.org/gentoo/portage)
-- 
2.0.0



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: sci-biology/ncbi-tools++

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Manuel Rüger mr...@gentoo.org (23 May 2014)
# Fails to build with gnutls-3.
# See bug #421777
# Masked for removal in 30 days
sci-biology/ncbi-tools++
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTf4byXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNclUgQAKIY3wNI0UdFSodW5ncuatZF
ZH7iL00fV3aNiSfKqmTIn1rOKeUq2oouRdE0w5aww8hQAE8ne8pZPKNd5tzKiAwH
dSU3KzOak/c2cNXTiZhb37KUsHLzqaKsGJWMYomHJAyeTEsuMjRH0i7CzgBDHj4N
Mj0XZZDMLs74x9ChxSI17iQ/0NCardMFUtpj10E33x5RVivrm/weFsBM/80HoOC4
aoO3L86bR4ZfHvf40O6yS6CAafGX2TpjG1jX9NXgBqiIzTqp9STe9mt2BSucKJis
arb7roBf2WoXRtvLHZikarOpQvEScBdtlYSOiMjNmDPBJlsvoYIhc9uZPHZ4sTQ0
64FBbHsjuMoAwU5DK7Wj3D0Q4BUkbLSvwEexg+RgrfmAiqmCF0o8Gxxj+8zSl7Dz
R9JeqX8z9AYW084BM53syG+kxaYUEe8dvP/EOAXHvUlRpyU8jg0hGzbHjV4vn4/W
lyR27GFqxn47KmaXf7lmDGQnLdmwX7lKm6iQGjQqfS5EEV+gslEo83+U8z+ZSkrR
+G8xpZ6wKrig9hTDyWiCo11Iuum4DUwc4X0geyIO6Sc7jUjblmRaO7d7M29s31DX
uzaGv1bVN9H8TRp+hWYHtvScJu4jkqfrCjybiUKpYIq0jX7eLmFXK/XM0eulaQP5
FLI9anxnQYkg4vK7dsgy
=yV+f
-END PGP SIGNATURE-

[gentoo-dev] Continuous repoman using travis-ci

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I created a travis script (it's rather a hack and could need some
improvements) [1] to run repoman for overlays hosted on github.

This might be interesting for your personal and also project overlays.
It will run repoman on pull requests, too.

If you want to see the example output, take a look here [2].


Cheers,

Manuel


[1] https://github.com/mrueg/mrueg-overlay/blob/master/.travis.yml
[2] https://travis-ci.org/mrueg/mrueg-overlay/builds/25907022
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTf8HLXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcnQwP/03RK8fVHAF/RARc8FLhP1qv
lrjNeSXRkYeDF7NJJkFzicz6gLk9UZXyJgCFu8FDHXH/oTYNx5CpNYtWBJesDycc
nur7ymZlk6vleQNfsX6nazkwfD2X45mnkdY/EAe9rEt7rm7JPbzm6TEIGWydQ0pR
cLAeUOFcQ4mDBxahIpVlw7Z7LZlXlArwAH7wU00XavlOio/6UyVXDiewqh5zU/NJ
rOCwvpJA1OYHZjFm0/3xcCpSIexRlbhv3O3uWw3EqRvxuxNPj9MhjliP2A4VgPif
Th6zn5wUk0q1kbQSTir15YXC5gY9L/V59CX/MMbp+zWoju+UWeGl2IE/+PDXh1Qd
3wfWsspK4Z6FHFzPZuetT7PpnOP2bci6Y9A8FtDvN3/KrQQx73kBwgXMEb1KBblM
HWN6sxRZiYtKAH947lkfIDIDYBVvNOeIJSah/WNKjagxSyzMgVOXnPJRxKMXgZKJ
R0oFhFozB5+GhzVIaQYzAqwtPSLahMHlsZxZ9TrbhWPSjNHm3qCzpVsmGT9txXy9
hm0F8ncQdWtR7PGxbPp3TqaTynIEOXAUsV9xmVy+uSM6j3DWJCxaoQ5/KRdYzW8/
XQnfXesDR6LoogQaSffB/SrtXoPwuPeNAkhkP0y4T4EvlcNT8KUt5t4YJfmIRyz1
wAgSDVWd0eovhaRmUlv2
=qpOd
-END PGP SIGNATURE-

[gentoo-dev] Last rites: ruby.eclass and gems.eclass

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

07 May 2014; Manuel Rüger mr...@gentoo.org gems.eclass, ruby.eclass:
ruby.eclass and gems.eclass have been deprecated by ruby-ng.eclass and
ruby-fakegem.eclass. Removal in 30 days. See bug #479812.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTappOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcNHcP/j+A0A3k+5EATU5SLe/Go1OL
oQMbx1N0sPnsdf41I04xg6fcPJX9XRJOcCiM6tCg9/B6f3ZG0uI0PfQtVXW2wpOx
OdvQAs+Wx4cJgjxjKlrbvcOSAfToH0xr7yl/wJapfvJ+oeYHxqPUZFnRGXJcGCWe
7YMVGlZD+v9QcHpkfj1eQSNwmb3EvQzg6VYuWSuPcfShciMqvJNPB8s2qbmHizyF
frVAUgLHivgxyJT9XkcU9N3Hdm9+wVZCT0VJVSxr+pMyf+0SfBE+tOmmp1gz9Olv
vtAmxbl3cp5k33b6W/Pj6EaRohW8q7EG7MqcoILSTS79gkzdokEz+0a6PaiROQkx
IEZ8VXNihI0xDDb19rS676dJJfW2dZtod1KCS4HY5DC13SEaPn19IMHKjyyqsT7o
eu4JlA69eFQm8p8y0Q9SIsvTHd5Q0NtDR1yu/yEaGyh5ZK9ZHqMFEn4C3aegng9P
tHkLMi/JOokQDOOmvv9oPJvw5fCh7ZoAevDcWuTGLFzVouYbeSAveM4rgiOQNKCc
y1zxg3SIPo/efB2AqSstfQKEInq1uqGJXqapEseGwdubwS7E4Bi4Ctpj/8h+HnCV
EHWiy+KdTBSvJgpg7IIpW85cbBdOZAaroIrfR/g+/dFShI/eSnFT2nqajQCoH36f
/D78GI5caSyhyzUa1+8z
=pKUo
-END PGP SIGNATURE-

[gentoo-dev] Last rites: dev-ruby/fastthread

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


# Manuel Rüger mr...@gentoo.org (07 May 2014)
# Useful for removed ruby18, no-op in ruby19 and later.
# Masked for removal in 30 days.
dev-ruby/fastthread
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTaryfXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcnv0P/2n3E+FYvE8uExneBdk61Pxe
IELGuxGvtgzzwXWBfKh11XspY/+xKddarWTTi/iaZfBl888ECWxIdNEw/P9JiZ7J
awRWpTC1EcNBpSQagAkB9pmyq6qVGCdJi9mce00bwwKiwyYTkU664BRYX5iLumD4
bgVLCt4vw/C/kE0rYBRLgW1/QyAVsowxuPblkNjzlnwt8Dg+rlH39J7XzN0Sju8Y
KXWGiVjPpBMVEuG0NLRrt88iUs3Z8+6bx5iPA7tec20GEnm5kmLMGBJQau48sWtd
FHRIg2O+GZKXOqZdMKLdU/2A5Zr8Wt290IssVcLMcfwbVzsTDd1cKC5kJQqGE1rD
EerT0AyI7Rp2yQxkxHwNDdvHjA4p8d9aE46XP4EoQg+dP5d1soafBTrL9IZSzaK7
9Qc5PTpmPpBdxCdzZZe1IDSS0ShxUzEDM6dDFgr4LaEpVcZkg5i8MaQg941Jq0UB
w9K+VloSxRaqvVoXPIX03Vuydz2pqtrwdHapBxqwQrJkqkR1B4KQFQLth/ezaY9C
ZqDMQYUW1nucd7S69WsQFimjjZBqsXyLNDbt6ZrPkW8RxgQXxXqZjC/1SAVGtB+7
oVG/6LBPKLVamYXH1D6SpTKD1EuPkTdhKkd3cSE8AL+O9H19U2V4osScx5FoKGQd
G+yCDLEir+XvYs0oAXA0
=5ojP
-END PGP SIGNATURE-

[gentoo-dev] Last rites: dev-python/python-gnutls

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Manuel Rüger mr...@gentoo.org (28 Apr 2014)
# Fails to build with gnutls-3, on behalf of python herd
# See bug #446016
dev-python/python-gnutls
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTXYr2XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc7TEP/RbgarQwrfyKCVOIESMJNccl
KNs1TR27Re8r4epZwclXGg9tcU++wSGCLph9uHjrJfPv6cla9m5MwxXXpXnuMRHo
QiGxKP2vM1663m/+wz6TrUSUzLglp1lvGKXX+pEweKoY5sY2yWiWKEQXOq5KL6q4
iEQLLWX3tvxF8aoE+Qy1nggSHym2wJc8S27bdD8P8GSmoIdCiVTesp5FYKxfryrB
Yt9U3sdH3Qa2HGJkIkI1qdaUHTjjK+XAsI24iMd4iGN8CuDzkubiOid8e1gq1R14
ytmqt8IiXnJIz9MdwQMn7DE6NhSNY7asFuTuwed+oJQRdK5CiejUq2fYe0FoPibv
uMsvq9xGmXzPXjwqg0yOca56EkengH7DF45LE+S3xwToFgxOmqXOKS5XsqKJ36nI
1fsQbeZeDAXGPFrncRgiCW1HlG4ZFrEmqSrsDzqpiQlVOlWw+EnqOePN5RD1pnJy
zhUS6XZscbhOo/JjPLbr9BtwjWzQ+NggDbDG1wokhQocuyBASgB7WGP3Lc8w2NiA
BqM2crQm9n/D2yD2j2mgB8UsZ5Ox+CwhqZbq0rO5q91o0mD48xlfXyD2Xkzt4Y5R
dH4fXMTcHFtWnffPRFDMwcwojfIsEpCADP4wzCPjVMbZWC/Ipl2JxsjsmkoX+FHF
kvzBeFIf/xTzJZfUBtje
=N+7f
-END PGP SIGNATURE-

[gentoo-portage-dev] [PATCH] Add ruby18 to repoman warning for deprecated ruby target

[Manuel Rüger]

Hello,

please add this patch into portage, as ruby18 has been pmasked and
will be removed.

Cheers,
Manuel
From 1a63c1e9f03400e7d17ef1aa8572d7e584be8ef8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Manuel=20R=C3=BCger?= mr...@gentoo.org
Date: Tue, 18 Mar 2014 00:05:22 +0100
Subject: [PATCH] Add ruby18 to repoman warning for deprecated ruby target.

---
 bin/repoman | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bin/repoman b/bin/repoman
index 92b..1ecbda8 100755
--- a/bin/repoman
+++ b/bin/repoman
@@ -487,6 +487,7 @@ suspect_virtual = {
 
 ruby_deprecated = frozenset([
 	ruby_targets_ree18,
+	ruby_targets_ruby18,
 ])
 
 metadata_xml_encoding = 'UTF-8'
-- 
1.9.0




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-lang/ruby:1.8 and consumers

[Manuel Rüger]

A news item was also added for this mask.

# Manuel Rüger mr...@gentoo.org (16 Mar 2014)
# Ruby 1.8 has no longer been supported upstream since July 2013 and
# has known security issues (bug #492282). Ruby packages in general
# are no longer compatible with ruby 1.8. Removal is tracked in bug
# 434064.
#
# This mask also includes all packages still depending in ruby 1.8.
# Removal in 30 days
dev-lang/ruby:1.8
virtual/rubygems:ruby18
virtual/ruby-rdoc:ruby18
virtual/ruby-ssl:ruby18
virtual/ruby-threads:ruby18
app-misc/alexandria
dev-ruby/fastercsv
dev-ruby/oniguruma
dev-ruby/rand
dev-ruby/revolution
dev-ruby/ruby-taglib
dev-ruby/rubytorrent
dev-ruby/sary-ruby
dev-ruby/system_timer
app-text/migemo-0.40_p2
=dev-ruby/mecab-ruby-0.98-r1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item: Removal of Ruby MRI 1.8; Ruby MRI 1.9 and 2.0 now default

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/08/2014 02:56 PM, Alex Legler wrote:
 On 08.03.2014 14:52, Alex Legler wrote:
 
 Also, I doubt we're recommending 1.9 over 2.0 (or vice versa).
 
 
 scratch that, seems like we are (even though big users like rails 
 actively push users to 2.0; but that's probably not important
 here)
 

See: http://moving-innovations.com/~graaff/targets.svg

Currently most ebuilds work with Ruby 1.9. Ruby 2.0 has already gained
support, but most of these packages don't have a stable keyword.

Cheers,

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTG1BaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcFpMQALMptvzrEF1RS80cCXECG9P6
APTuB5/PCTUcy+wk8PnLkRb7c7B7nbfTEFyoWERlmTV9r6S3Ft1t5gtmO2mJ7U4F
dWb7uOPCU95w24Sbbf4cRczESTkoImcuNweXWzvz3Azbkjj3OgX3KYc9Po7i+gli
So9AQTePtbdxcx/Ep3nt53tF5Uz8t4tg++Fg0Zprl0qAITg436QuuXGFpb8K0GIG
YgK9Nn3LjYnkjiNcpvTeqM3tCO2r0SVKgUiq9VIiYSTvGXf55lHSbxFPQPHYGPF3
/V3XUptdt0PWB9VYdeISpyRm4pfwt+2BzSoRpWmMH/C9EDSEvBdOchdMJWMoegNa
U1yhalBsmWR7jG6eWDJNqyFlGmmFuCBWQyS/bNN/7hBLERrzhoFXBuQ9U6l1NSdL
GIpV8MuavfaOjgAI3l9IqTC23J9hN2yuP+SUssfAXriP1Q1VU6ofZsEFWYnTVKYp
h3QzcrU8UKmVIVnkN0WlsNBk3t79iCZ0MxhjEafS2pLAk04960pC/n/xExxxkWhD
Om2hBle11Sc5nszogTicFcAAaYb7u03m6TVuoEF9dPLWgsGI7Om4THk4Q8mYPvny
lDHRQMSQDI5UM++gJjfiCYCB8h4GMXw+f+EyHlsaALo7my5BiMlItrL9uOoYONNi
vRIGhlsjU3CKdIxLct6Y
=KXjh
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: News item: Removal of Ruby MRI 1.8; Ruby MRI 1.9 and 2.0 now default

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/08/2014 02:25 PM, Alex Xu wrote:
 On 08/03/14 05:37 AM, Tom Wijsman wrote:
 On Sat, 8 Mar 2014 01:46:52 + (UTC) Duncan
 1i5t5.dun...@cox.net wrote:
 
 0 1 2 3 4 
 012345678901234567890123456789012345678901234 Ruby MRI 1.8
 removal; 1.9 recommended default
 
 (The latter is GLEP 42's max 44 chars exactly, and accurately 
 represents the recommended eselect ruby setting.)
 
 $ x=Ruby MRI 1.8 removal; 1.9 recommended default ; echo ${#x} 
 45
 
 Since you have started with 0 instead of 1, you have one
 character more; thus we'll need to find another character to cut,
 since that doesn't seem possible I suggest we drop the word
 default instead.
 
 $ x=Ruby MRI 1.8 removal; 1.9 recommended ; echo ${#x} 37
 
 
 $ x=Ruby MRI 1.8 removal; 1.9 now recommended ; echo ${#x} 41
 


Thanks for your help!
New title: Ruby 1.8 removal; Ruby 1.9/2.0 default

Cheers,

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTG1E1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcSngP/3K3kFXlOB08bWgJrLBRj9u3
v/4AWLtAul+nVyCuDAtjMYQHEks9XqCQ5NIuLYYCAyXO+6MWVnPQ8biYfbZXt5dQ
JUSDpFpVY0KOAJWhPQJjAKv6vCPygp73Plv0s+bX9OeXUjp5/lRD21Y0pii0Fdw/
IHdJX7HeRfbiAV+naMyeEhIDRwABA4ex+I6n7KJ27L2JPEP/iykqCkG+qCmNKhce
NX15TpGYZJvSx1mkQBmQFfknNTza8fy4LB/ccwBAD4iIZXRgw1qTgb855z2bfRtl
lPtUouu689AWqRHlFDzUmvuKRgJHWLD81Bux+T5+9ve6K5jB2tUNLutsLkQJ9QrX
2AxarunEcvjrXh7DRdWAp5DjqykgspzlVN01y0NaJJVIDlp1U5fZd42qX4z5YXq+
xQTMQonNFDQ7q6d6gX+JInQt5RJDZJxFUIZ2I731vWFO6hHhF5VR5oN2IpA2pKor
SE26Kl9+WWqtyLAFHr204sZAmU38qWzhQ6cCF0nZCh4IZe2ciEr7chVLzbp6d7RZ
grCog4W4OyRVoH2kRqsTl6eiSeWMJ+fe6N7fJ08HidQwy9P5+KZ/I47rncYSbKRc
m2Wj+4nYmZPsMM+LFS+1CVl+VBCcBv3pDfx8g0JzE5HutJ6IUQ21jUTvQwqICznk
W3B62Kc7KTobEA1M9r4+
=Ewje
-END PGP SIGNATURE-

[gentoo-dev] News item: Removal of Ruby MRI 1.8; Ruby MRI 1.9 and 2.0 now default

[Manuel Rüger]

As we will remove Ruby 1.8 from tree and add Ruby 2.0 target to base
profile's RUBY_TARGETS variable, this will be the news item for the
upcoming changes.

Cheers,

Manuel
Title: Removal of Ruby MRI 1.8; Ruby MRI 1.9 and 2.0 now default
Author: Manuel Rüger mr...@gentoo.org
Content-Type: text/plain
Posted: 2014-03-07
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: dev-lang/ruby

Ruby MRI 1.8 has been retired by upstream in June 2013.[1]
We remove Ruby MRI 1.8 support from the tree now. In parallel Ruby MRI 2.0 
support will be activated in base profile's RUBY_TARGETS variable by default 
in conjunction with Ruby MRI 1.9.

If your currently eselected Ruby interpreter is ruby18, our recommendation is 
to change it to ruby19. At the moment Ruby MRI 1.9 delivers the best possible 
support of all Ruby interpreters in tree.

Check the current setting via:

eselect ruby show

Change the current setting to Ruby MRI 1.9 via:

eselect ruby set ruby19

[1] https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Manuel Rüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/17/2014 06:08 PM, gro...@gentoo.org wrote:
 On Fri, 17 Jan 2014, Tom Wijsman wrote:
 On Fri, 17 Jan 2014 16:31:54 +0100 Ulrich Mueller
 u...@gentoo.org wrote:
 On Fri, 17 Jan 2014, grozin  wrote:
 Maybe, a good solution is to introduce a special arch,
 noarch, for such packages (similar to what's done in the
 rpm world). Then, if a package is ~noarch, it is
 automatically considered ~arch for all arches. Similar for
 stable. The maintainer should be able to keyword ~noarch and
 to stabilize noarch. Comments?
 
 How would you handle dependencies in such a scenario? All
 dependencies must be keyworded or stable on all architectures,
 before the package can be keyworded or stabilised on noarch?
 
 Maybe we can let the package managers only perceive it as
 keyworded or stable if all of its dependencies are keyworded or
 stable on the architecture that the user runs. Then we can have
 repoman just ignore checking dependencies' keywords when we
 keyword or stabilize them.
 Very reasonable.
 
 Andrey
 


I think the idea itself is good, but we should not add this to
KEYWORDS directly, as it might cause some problems with older package
managers(?).

A new variable can be introduced, which will overwrite testing
keywords to stable keywords, if the var is set to stable and keeps
everything in KEYWORDS marked as testing otherwise.

If this var exists in an ebuild and there is a new stabilization bug,
the arch team can decide if they want to mark it stable for all
architectures (via setting the var to stable) or only for the
architecture they tested it for (if some dependencies are missing on
other architectures).
This practice ensures that at least one arch team member of any arch
tested it.

The use of the to-be-added variable could also be extended for
vulnerability fixing.
It's more important to users to deal with less vulnerabilities for a
long time than a working stable dependency tree. Because the latter
got easier with the autounmask feature in portage.

If the var is set by the maintainer to security-fix-$bugid and the
users add an option to their profile, it automatically sets the ebuild
to stable and prompts an info with the bugid.
Users who do not want to wait for stabilization or GLSA have a better
possibility to secure their system earlier.
The advantage in general is that quickly added fixes get a wider
testing. So stable users will also profit.


Cheers

Manuel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJS2cwvXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcpuwP/27np/ekt9AWHJz/OC7BpDz8
gxrE0iuocczV6m5/CejSY8GEdd26xQRdyloZ/7f74W1I5jRB/WPbHUKa0dnglZba
AG/WRJRYOao6537t5p9n6knH3Bj0wIcZl90Jox80HOXsvk/eBwZaliE+jcA+6Mat
Dcl0FVgl/b1WJZaa0aEt5st8nnW5TJ5ZTuWBG6e6shH94qAFcr8VWLOTtY1xqvHf
U1GHlynM4h+nX7BnDlhPxPf2l9XPBZNQFOAvWfvE341uZcSUpkQYfYzpo2TKdYop
oPL6hfMsHq5uggB0OvVaf4CiuCKhV3re7GVexKJE9Moigrb0v/nWCy5ApvR0Ww/N
7wozyGcWUKc/oHW3CHGAYr4wbFjjI9LjB5IVEjmEAGmJ5bq7/RViM+5slj/s9kBe
Vioti6i2vYVs4awm/HrMvremVUJ03Deh8uwVnOaggyrggRnwbxEsRxdsMCmYNkKN
2xAVvnSi2YEMSwBWvClRJwFvvrZzzsWd+t2Y/e/VqAFNvZn0H0lqZAP1+z540nzU
I7f2ym88jedwRJq41q6TgI9XaHlTFXLMcb9Hu19Xv/faUu5jHxg+ZvQtIwC/2YRy
6La1PGO9uk0wHOgixHe/bPXmZ2ArTHB6pAzgiLMpQxuahJhbGXiTmjM8qBc8IKD2
t0VP0WhLWZahQtQ21vrW
=UumH
-END PGP SIGNATURE-

Re: [gentoo-dev] Maintainer-needed on many of my packages

[Manuel Rüger]

On 12/29/2013 01:19 AM, Robin H. Johnson wrote:
 app-misc/ddccontrol
 app-misc/ddccontrol-db

I'd take these ones, if no one objects.

Cheers,

Manuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Manuel Rüger]

I already took over maintainership. If you want to help maintaining it,
feel free to ping me offlist and I'll add you, too.

Cheers,

Manuel

On 12/23/2013 05:37 PM, Manuel Rüger wrote: On 12/23/2013 04:40 PM,
Pacho Ramos wrote:
 Due tove lack of time:
 www-apps/ikiwiki



 I'll add myself if no one objects.

 Cheers,

 Manuel



On 12/25/2013 07:19 AM, Alice Ferrazzi wrote:
 i want to grab the following:
 
 www-apps/ikiwiki
 
 
 On Tue, Dec 24, 2013 at 3:11 AM, Pavlos Ratis daster...@gentoo.org
 mailto:daster...@gentoo.org wrote:
 
 I want to grab the following:
 
 dev-vcs/vcsh
 dev-vcs/mr
 app-admin/cronolog
 app-emulation/ganeti-instance-image
 
 If there isn't any objection, I'll add myself as maintainer.
 
 
 
 
 -- 
 
 
 --
 Gentoo,  If it moves, compile it!
 My_overlay: https://github.com/aliceinwire/overlay
 Mail: Alice Ferrazzi alice.ferra...@gmail.com
 mailto:alice.ferra...@gmail.com
 PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Manuel Rüger]

On 12/23/2013 04:40 PM, Pacho Ramos wrote:
 Due tove lack of time:
 www-apps/ikiwiki
 
 
 
I'll add myself if no one objects.

Cheers,

Manuel



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Package removal without proper last-riting

[Manuel Rüger]

Hi,

I recently noticed it twice, that it seems to be common practice to
remove a package without using the methods described in [1], but just
dropping it from cvs.

From my observations packages removed without last-rites could be
characterized by this:

- it was a dependency of another package
- this package dropped / incorporated the dependency
- no other packages depend on it
- there are possible forks or updates, but maintainer doesn't care^W^W
has no interest

This might work for the main tree, but it won't for overlays, that might
also depend on these packages (because they have a patched / older
version of your maintained package).

Please stop killing user experience or document this feature in [1].

Best regards,

Manuel

[1] http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rite: Further ruby-1.8 only packages

[Manuel Rüger]

# Manuel Rüger mr...@gentoo.org (27 Sep 2013)
# Mask further ruby-1.8 only packages
# Masked for removal in 30 days.
dev-ruby/heckle
dev-ruby/main
dev-ruby/rcov
dev-ruby/rqr
dev-ruby/ruby-svg



signature.asc
Description: OpenPGP digital signature