Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages

[Pacho Ramos]

El jue, 01-01-1970 a las 00:00 +, Ulrich Mueller escribió:
> > > > > > On Mon, 17 Jul 2023, Mike Gilbert wrote:
> 
> > On Mon, Jul 17, 2023 at 4:27 PM Sam James  wrote:
> > > > Haven't we been keeping these because we still need to decide
> > > > on a
> > > > policy about what to do with dead acct-*/* packages?
> > > 
> > > Right. https://bugs.gentoo.org/781881 is still open. Flow could
> > > ping
> > > the QA team and ask if it should be closed, given the opinion
> > > there
> > > seems to be that there's no need to keep them, but I think it's
> > > wrong
> > > to do this pre-empting a policy decision, given it essentially
> > > forces
> > > the "don't keep them" path.
> 
> > The bug has been open for several months without comment. If a
> > policy
> > were going to materialize, I think it would have happened by now.
> 
> > Forcing the issue by sending this last rites notice seems
> > acceptable
> > to me.
> 
> I'd say we remove the packages, because system user and group ids are
> a somewhat scarce resource.

I agree because of the same reasons 



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

Re: [gentoo-dev] [PATCH 1/3] autotools.eclass: Downgrade eqawarn for renaming configure.in

[Pacho Ramos]

El dom, 28-05-2023 a las 15:16 +0200, Ulrich Müller escribió:
> At this point, almost all upstreams will have switched to
> configure.ac.
> Therefore, configure.in is most likely an indication of an inactive
> upstream, and there is no useful way for the ebuild maintainer to
> silence the warning (other than the ebuild renaming the file).
> 
> Keep the message as einfo, so there is still an indication that the
> file
> was renamed.
> 
> Bug: https://bugs.gentoo.org/426262
> Signed-off-by: Ulrich Müller 
> ---
>  eclass/autotools.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
> index 91046b9f82f3..3a040b863eea 100644
> --- a/eclass/autotools.eclass
> +++ b/eclass/autotools.eclass
> @@ -400,7 +400,7 @@ eautoconf() {
> *)
> # Move configure file to the new
> location only on newer EAPIs to ensure
> # checks are done rather than
> retroactively breaking ebuilds.
> -   eqawarn "Moving configure.in to
> configure.ac (bug #426262)"
> +   einfo "Moving configure.in to
> configure.ac (bug #426262)"
> mv configure.{in,ac} || die
> ;;
> esac

LGTM

Thanks!


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

[gentoo-dev] Last rites: sys-power/dptfxtract

[Pacho Ramos]

# Pacho Ramos  (2023-02-27)
# No longer needed by thermald-2, discontinued by upstream
# Removal: 2023-03-29.  Bug #898164.
sys-power/dptfxtract



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

[gentoo-dev] desktop.eclass: allow 1024 as a size for icons

[Pacho Ramos]

Hello,

As discussed in https://bugs.gentoo.org/888635 , 1024x1024 icons are
starting to be deployed in some apps as they start to be used in MacOSX
environment. Some weeks ago I needed to skip their installation for
net-im/rocketchat-desktop-bin and I saw that net-analyzer/wireshark is
workarounding the problem by manually installing them without
desktop.eclass helpers.

I would then simply add 1024 to the list of allowed sizes too

Thanks

diff --git a/desktop.eclass~ b/desktop.eclass
index aa1b9ac..ea5c84c 100644
--- a/desktop.eclass~
+++ b/desktop.eclass
@@ -311,7 +311,7 @@ _iconins() {
size=${2}
fi
case ${size} in
-   16|22|24|32|36|48|64|72|96|128|192|256|512)
+  
16|22|24|32|36|48|64|72|96|128|192|256|512|1024)
size=${size}x${size};;
symbolic|scalable)
;;
@@ -369,7 +369,7 @@ _iconins() {
 #!!! must specify to install into /usr/share/icons/... !!!
 #size of the icon, like 48 or 48x48
 #supported icon sizes are:
-#16 22 24 32 36 48 64 72 96 128 192 256 512 scalable
+#16 22 24 32 36 48 64 72 96 128 192 256 512 1024 scalable
 #  -c, --context
 #defaults to "apps"
 #  -t, --theme



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

[gentoo-dev] profiles/targets/desktop: enable "sound" USE by default

[Pacho Ramos]

This morning I was surprised about a clanlib game consumer no having
sound, and I noticed sound USE flag wasn't enabled.

I think "sound" should be expected on most "desktop" systems.

Any thoughts on enabling it by default on these profiles?

Thanks


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

[gentoo-dev] Last rites: net-wireless/bluez-hcidump

[Pacho Ramos]

# Pacho Ramos  (2022-12-18)
# Dead for ages, still included and barely maintained in
bluez[deprecated].
# See bug #885459
# Removal: 2023-01-17.  Bug #885459.
net-wireless/bluez-hcidump



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

[gentoo-dev] Last rites: app-admin/abrt, app-admin/gnome-abrt, dev-libs/libreport, dev-libs/satyr

[Pacho Ramos]

# Pacho Ramos  (2022-09-18)
# ABRT environment keeps breaking more and more on non-Fedora systems.
# Removal: 2022-10-18.  Bugs #849305, #849092, #849095, #713858.
app-admin/abrt
app-admin/gnome-abrt
dev-libs/libreport
dev-libs/satyr



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

[gentoo-dev] Last rites: media-sound/pulseaudio-modules-bt

[Pacho Ramos]

# Pacho Ramos  (2022-09-18)
# Unmaintained for a long time and unneeded with current pulseaudio and
# pipewire versions.
# Removal: 2022-10-18.
media-sound/pulseaudio-modules-bt



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

Re: [gentoo-dev] [PATCH 1/5] ninja-utils.eclass: Support dev-util/samurai

[Pacho Ramos]

El lun, 09-05-2022 a las 13:50 +0200, Pacho Ramos escribió:
> El dom, 08-05-2022 a las 23:07 +, Sam James escribió:
> > From: orbea 
> > 
> > samurai is a ninja-compatible build tool written in C which
> > works with cmake, meson and other users of ninja.
> > 
> > It is feature-complete and supports most of the same options
> > as ninja.
> > 
> > Signed-off-by: orbea 
> > Signed-off-by: Sam James 
> > ---
> >  eclass/ninja-utils.eclass | 24 +++-
> >  1 file changed, 23 insertions(+), 1 deletion(-)
> > 
> > diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
> > index c5f34934192f..67f7a6b5e8a7 100644
> > --- a/eclass/ninja-utils.eclass
> > +++ b/eclass/ninja-utils.eclass
> > @@ -26,6 +26,15 @@ esac
> >  if [[ -z ${_NINJA_UTILS_ECLASS} ]]; then
> >  _NINJA_UTILS_ECLASS=1
> >  
> > +# @ECLASS_VARIABLE: NINJA
> > +# @PRE_INHERIT
> > +# @DEFAULT_UNSET
> > +# @DESCRIPTION:
> > +# Specify a compatible ninja implementation to be used by eninja.
> > +# At this point only "ninja" and "samu" are supported.
> > +# The default is set to "ninja".
> > +: ${NINJA:=ninja}
> > +
> >  # @ECLASS_VARIABLE: NINJAOPTS
> >  # @DEFAULT_UNSET
> >  # @DESCRIPTION:
> > @@ -35,6 +44,19 @@ _NINJA_UTILS_ECLASS=1
> >  
> >  inherit multiprocessing
> >  
> > +case "${NINJA}" in
> > +   ninja)
> > +   NINJA_DEPEND=">=dev-util/ninja-1.8.2"
> > +   ;;
> > +   samu)
> > +   NINJA_DEPEND="dev-util/samurai"
> > +   ;;
> > +   *)
> > +   eerror "Unknown value for \${NINJA}"
> > +   die "Value ${NINJA} is not supported"
> > +   ;;
> > +esac
> > +
> 
> Personally I would add "samurai" as value instead of the abbreviated "samu"
> form
> (that could come from other words than "samurai")... but has you wish :), it
> is
> only a cosmetic change anyway
> 
> Thanks
> 
> 
*as you wish 



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

Re: [gentoo-dev] [PATCH 1/5] ninja-utils.eclass: Support dev-util/samurai

[Pacho Ramos]

El dom, 08-05-2022 a las 23:07 +, Sam James escribió:
> From: orbea 
> 
> samurai is a ninja-compatible build tool written in C which
> works with cmake, meson and other users of ninja.
> 
> It is feature-complete and supports most of the same options
> as ninja.
> 
> Signed-off-by: orbea 
> Signed-off-by: Sam James 
> ---
>  eclass/ninja-utils.eclass | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
> index c5f34934192f..67f7a6b5e8a7 100644
> --- a/eclass/ninja-utils.eclass
> +++ b/eclass/ninja-utils.eclass
> @@ -26,6 +26,15 @@ esac
>  if [[ -z ${_NINJA_UTILS_ECLASS} ]]; then
>  _NINJA_UTILS_ECLASS=1
>  
> +# @ECLASS_VARIABLE: NINJA
> +# @PRE_INHERIT
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Specify a compatible ninja implementation to be used by eninja.
> +# At this point only "ninja" and "samu" are supported.
> +# The default is set to "ninja".
> +: ${NINJA:=ninja}
> +
>  # @ECLASS_VARIABLE: NINJAOPTS
>  # @DEFAULT_UNSET
>  # @DESCRIPTION:
> @@ -35,6 +44,19 @@ _NINJA_UTILS_ECLASS=1
>  
>  inherit multiprocessing
>  
> +case "${NINJA}" in
> +   ninja)
> +   NINJA_DEPEND=">=dev-util/ninja-1.8.2"
> +   ;;
> +   samu)
> +   NINJA_DEPEND="dev-util/samurai"
> +   ;;
> +   *)
> +   eerror "Unknown value for \${NINJA}"
> +   die "Value ${NINJA} is not supported"
> +   ;;
> +esac
> +

Personally I would add "samurai" as value instead of the abbreviated "samu" form
(that could come from other words than "samurai")... but has you wish :), it is
only a cosmetic change anyway

Thanks




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

Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Document the DOC_CONTENTS variable

[Pacho Ramos]

El sáb, 01-01-2022 a las 12:04 +0100, Ulrich Müller escribió:
> This fixes a spurious "UnusedInherits" warning from pkgcheck.
> 
> Signed-off-by: Ulrich Müller 
> ---
>  eclass/readme.gentoo-r1.eclass | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
> index 3ad36fac2588..0d302179127b 100644
> --- a/eclass/readme.gentoo-r1.eclass
> +++ b/eclass/readme.gentoo-r1.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2021 Gentoo Authors
> +# Copyright 1999-2022 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: readme.gentoo-r1.eclass
> @@ -25,6 +25,11 @@ case ${EAPI} in
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
>  esac
>  
> +# @ECLASS-VARIABLE: DOC_CONTENTS
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# The information that is used to create the README.gentoo file.
> +
>  # @ECLASS-VARIABLE: DISABLE_AUTOFORMATTING
>  # @DEFAULT_UNSET
>  # @DESCRIPTION:

LGTM

Thanks!


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

Re: [gentoo-dev] USE-flag gnome-keyring isn't accurate anymore

[Pacho Ramos]

El jue, 23-12-2021 a las 17:46 -0500, Matt Turner escribió:
> On Thu, Dec 23, 2021 at 4:36 PM tastytea  wrote:
> > I think “secret” may be too generic and “libsecret” is not ideal in case
> > an implemention comes along that is named differently. How about
> > “secret-service”?
> 
> I think this is a good idea.
> 

And "keyring"? I am not sure if users not familiar with "libsecret" will
understand what "secret*" means in this context 


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

Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item

[Pacho Ramos]

El jue, 25-11-2021 a las 09:20 -0500, Mike Gilbert escribió
[...]
> I don't like the phrase "forcefully downgraded" here. This implies
> > > that something happened without the user's consent. emerge would have
> > > informed them of the downgrade before it happened. I would suggest
> > > removing the word "forcefully" from these paragraphs.
> > 
> > If you do a normal world upgrade, this is the default portage behavior,
> > not? I.e. package manager will downgrade if you don't stop. And
> > especially on servers, people tend to use cronjobs/scripts to do that...
> 
> Something happening by default is not the same as forcing it to happen.
> 
> Using a cron job or other blind automation to do package upgrades on
> any production system is a bad idea. We certainly do not recommend
> that to people, nor force them to do it.
> 
> 

As a side note, maybe ebuild should add sanity checks (like those from glibc) to
prevent downgrades, otherwise people could still accidentally hit the issue

Thanks


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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Pacho Ramos]

El jue, 11-11-2021 a las 12:48 +0100, Ulrich Mueller escribió:
> > > > > > On Thu, 11 Nov 2021, Florian Schmaus wrote:
> 
> > > We could:
> > > - Open some part of the range between 500 and 1000. For example,
> > > 500..799, which would leave 200 IDs for dynamic allocation.
> 
> > +1, since I am not aware of any significant downsides doing so.
> 
> > Could you elaborate why the range 500-799 only leaves us with 200 IDs?
> 
> We still need some range for dynamic allocation. Currently that is
> 500..999, and would be reduced to 800..999. That seems to be on the low
> side already.
> 
> In any case, 300 additional IDs may not be future proof at the rate
> we're currently allocating them. So I wonder if we shouldn't move to
> above 6 immediately, or alternatively, give up the whole concept.
> 
> Ulrich

Personally I would move to >6 and keep the 300 additional IDs for the case
some software really really needs them 


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

Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

[Pacho Ramos]

El mié, 03-11-2021 a las 21:15 -0500, John Helmert III escribió:
> On Thu, Nov 04, 2021 at 12:09:28AM +, Sam James wrote:
> > On 4 Nov 2021, at 00:02, Sam James  wrote:
> > > > On 3 Nov 2021, at 23:53, Aaron Bauman  wrote:
> > > > Is that where the policy belongs?
> > > > If so, shouldn't the council update it based on their decisions?
> > > > "patches are welcome" doesn't fit every scenario.
> > > Got to agree here. If there's a gap in the documentation,
> > > let's file a bug -- irrespective of if someone is going to give
> > > a patch.
> > > Just commenting this on the ML means it'll get lost
> > > and we'll forget about it...
> > 
> > Filed https://bugs.gentoo.org/821553. Please
> > feel free to clarify it.
> 
> Thank you! Many of us apparently have differing interpretations of the
> policy (and it's somewhat hidden), so a clear policy in an obvious
> place will be a huge improvement!


I haven't tried yet as, fortunately, I have been able to deal with the conflicts
most of the times but, I was wondering if one workaround would be to simply try
to use emerge-webrsync --revert= option.

That way, people could try to upgrade their old systems going from the oldest
tree to, for example, the tree from August of this year. Later they could update
to a newer snapshot and follow until the end 


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

[gentoo-dev] Re: [PATCH v2 2/2] readme.gentoo-r1.eclass: Standardize EAPI guard

[Pacho Ramos]

El mar, 17-08-2021 a las 06:51 +0200, Ulrich Müller escribió:
> Signed-off-by: Ulrich Müller 
> ---
>  eclass/readme.gentoo-r1.eclass | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
> index e47e1ac20af6..3ad36fac2588 100644
> --- a/eclass/readme.gentoo-r1.eclass
> +++ b/eclass/readme.gentoo-r1.eclass
> @@ -20,15 +20,9 @@
>  if [[ -z ${_README_GENTOO_ECLASS} ]]; then
>  _README_GENTOO_ECLASS=1
>  
> -case "${EAPI:-0}" in
> -   0|1|2|3|4|5)
> -   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> -   ;;
> -   6|7|8)
> -   ;;
> -   *)
> -   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> -   ;;
> +case ${EAPI} in
> +   6|7|8) ;;
> +   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
>  esac
>  
>  # @ECLASS-VARIABLE: DISABLE_AUTOFORMATTING

LGTM

Thanks a lot!


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

[gentoo-dev] Package up for grabs: sys-boot/woeusb

[Pacho Ramos]

No longer interested on it, pending a major version bump after upstream
splitting:
https://github.com/slacka/WoeUSB/issues/209

Thanks a lot for taking it


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

Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

[Pacho Ramos]

El lun, 08-02-2021 a las 12:19 +0100, Michał Górny escribió:
> Hi,
> 
> FYI the developers of dev-python/cryptography decided that Rust is going
> to be mandatory for 1.5+ versions.  It's unlikely that they're going to
> provide LTS support or security fixes for the old versions.
> 
> Since cryptography is a very important package in the Python ecosystem,
> and it is an indirect dependency of Portage, this means that we will
> probably have to entirely drop support for architectures that are not
> supported by Rust.
> 
> According to upstream platform support information [1], this probably
> means (eventually) entirely removing the following architectures:
> - alpha (stable)
> - hppa (stable)
> - ia64 (stable)
> - m68k (exp)
> - s390 (except for s390x, exp)
> 
> Furthermore, the Gentoo Rust packages are missing support
> for the following platforms, apparently supported upstream:
> - mips (exp)
> - ppc (32) (stable)
> - sparc (stable)
> - s390x (exp)
> - riscv (stable)
> 
> Apparently it's non-trivial to bootstrap Rust on these platforms,
> so it's unclear when Gentoo is going to start providing Rust on them.
> 
> I've raised a protest on the cryptography bug tracker [2] but apparently
> upstream considers Rust's 'memory safety' more important than ability to
> actually use the package.
> 
> Honestly, I don't think it likely that Rust will gain support for these
> platforms.  This involves a lot of work, starting with writing a new
> LLVM backend and getting it accepted (getting new code into LLVM is very
> hard unless you're doing that on behalf one of the big companies).  You
> can imagine how much effort that involves compared to rewriting the new
> code from Cryptography into C.
> 
> If we can't convince upstream, I'm afraid we'll either have to drop
> these architectures entirely or fork Cryptography.
> 
> 
> [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html
> [2] https://github.com/pyca/cryptography/issues/5771
> 

It will also affect non-SSE2 x86 setups as upstream is neither providing
prebuilt package for them :/

https://bugs.gentoo.org/741708




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

Re: [gentoo-dev] Re: sys-power/bbswitch up for grabs

[Pacho Ramos]

El jue, 14-01-2021 a las 15:15 +0700, Vadim A. Misbakh-Soloviov escribió:
> В письме от суббота, 26 декабря 2020 г. 20:22:33 +07 пользователь Piotr 
> Karbowski написал:
> > Hi,
> > 
> > I've been maintaining sys-power/bbswitch in the recent times, however, I
> > no longer have any hardware where I can even test it. If anyone sees it
> > fit, feel free to grab it and join other maintainers there. I just
> > dropped myself out of metadata.xml.
> > 
> > Open bugs:
> > - https://bugs.gentoo.org/761370
> > - https://bugs.gentoo.org/613338
> > 
> > -- Piotr.
> 
> Actually, I've also almost no Optimus hardware ATM. Maybe, I'll drop myself 
> from metadata too
> 

I joined :)


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

Re: [gentoo-dev] [PATCH] depend.apache.eclass: support EAPI-7

[Pacho Ramos]

El mar, 03-11-2020 a las 17:25 +0100, Marek Szuba escribió:
> Signed-off-by: Marek Szuba 
> ---
>  eclass/depend.apache.eclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass
> index 79bfdcc493f..5aa55254268 100644
> --- a/eclass/depend.apache.eclass
> +++ b/eclass/depend.apache.eclass
> @@ -1,10 +1,10 @@
> -# Copyright 1999-2012 Gentoo Foundation
> +# Copyright 1999-2020 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: depend.apache.eclass
>  # @MAINTAINER:
>  # apache-d...@gentoo.org
> -# @SUPPORTED_EAPIS: 0 2 3 4 5 6
> +# @SUPPORTED_EAPIS: 0 2 3 4 5 6 7
>  # @BLURB: Functions to allow ebuilds to depend on apache
>  # @DESCRIPTION:
>  # This eclass handles depending on apache in a sane way and provides
> information
> @@ -44,7 +44,7 @@ case ${EAPI:-0} in
>   0|2|3|4|5)
>   inherit multilib
>   ;;
> - 6)
> + 6|7)
>   ;;
>   *)
>   die "EAPI=${EAPI} is not supported by depend.apache.eclass"

If I remember correctly, some important bugs were pending and affecting to
eapi6... then, I guess they would also affect eapi7
https://bugs.gentoo.org/616612


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

Re: [gentoo-portage-dev] Speeding up Tree Verification

[Pacho Ramos]

El mar, 30-06-2020 a las 08:20 +0200, Fabian Groffen escribió:
> Hi,
> 
> On 29-06-2020 21:13:43 -0500, Sid Spry wrote:
> > Hello,
> > 
> > I have some runnable pseudocode outlining a faster tree verification
> > algorithm.
> > Before I create patches I'd like to see if there is any guidance on making
> > the
> > changes as unobtrusive as possible. If the radical change in algorithm is
> > acceptable I can work on adding the changes.
> > 
> > Instead of composing any kind of structured data out of the portage tree my
> > algorithm just lists all files and then optionally batches them out to
> > threads.
> > There is a noticeable speedup by eliding the tree traversal operations which
> > can be seen when running the algorithm with a single thread and comparing it
> > to
> > the current algorithm in gemato (which should still be discussed here?).
> 
> I remember something that gemato used to use multiple threads, but
> because it totally saturated disk-IO, it was brought back to a single
> thread.  People were complaining about unusable systems.
> 
> In any case, can you share your performance results?  What speedup did
> you see, on warm and hot FS caches?  Which type of disk do you use?
> 
> You could compare against qmanifest, which uses OpenMP-based
> paralllelism while verifying the tree.  On SSDs this does help.
> 
> Thanks,
> Fabian

I am talking only based on my own experience but, at least on my case, there are
noticeable differences between I/O schedulers. That is something that maybe
could affect that tests... with latest kernels we only have noop, deadline
(default) and bfq... in my case bfq works far better for keeping the system
responsible (on both, rotational and SSDs). But you can test different
combinations to see the one that fits better for you.



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

Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

[Pacho Ramos]

El sáb, 06-06-2020 a las 15:09 -0400, Aaron Bauman escribió:
> On Sat, Jun 06, 2020 at 02:50:31PM -0400, Aaron Bauman wrote:
> > All, the graphics project has now been disbanded.
> > 
> > All packages have been reassigned to maintainer-needed. Bugs will be
> > reassigned soon.
> > 
> > Here are a list of the packages that are now up for grabs:
> > 
> > dev-cpp/pngpp
> 
> To expound on this, the graphics project has a quite a few bugs assigned
> to them (169). A few packages have co-maintainers, but these are still
> reflected in the metadata as required.
> 
> If anyone else has time to address the bugs or wants to take the package
> over please do.
> 
> If you hit a package with a co-maintainer then my apologies.
> 

I think this is the list of completely unmaintained packages now (indeed most of
them, around 100) :)

dev-cpp/pngpp
media-gfx/apng2gif
media-gfx/apngasm
media-gfx/apngdis
media-gfx/apngopt
media-gfx/autopano-sift-C
media-gfx/cellwriter
media-gfx/chafa
media-gfx/cptutils
media-gfx/darktable
media-gfx/dcraw
media-gfx/duhdraw
media-gfx/enblend
media-gfx/exact-image
media-gfx/exif
media-gfx/fim
media-gfx/fr0st
media-gfx/gif2apng
media-gfx/gif2png
media-gfx/gifsicle
media-gfx/gimageview
media-gfx/gmic
media-gfx/gnofract4d
media-gfx/graphicsmagick
media-gfx/grub-splashes
media-gfx/gtkimageview
media-gfx/hugin
media-gfx/icon-slicer
media-gfx/igal
media-gfx/imagemagick
media-gfx/jhead
media-gfx/jigl
media-gfx/jpeginfo
media-gfx/jpegoptim
media-gfx/jpegpixi
media-gfx/libimagequant
media-gfx/luminance-hdr
media-gfx/mandelbulber
media-gfx/metapixel
media-gfx/mscgen
media-gfx/nvidia-cg-toolkit
media-gfx/openclipart
media-gfx/panini
media-gfx/pdf2svg
media-gfx/png2ico
media-gfx/pngcheck
media-gfx/pngcrush
media-gfx/pngquant
media-gfx/pngrewrite
media-gfx/povtree
media-gfx/pqiv
media-gfx/pqstego
media-gfx/qiv
media-gfx/qvv
media-gfx/raw-thumbnailer
media-gfx/rotoscope
media-gfx/scantailor-advanced
media-gfx/scour
media-gfx/sfftobmp
media-gfx/sxiv
media-gfx/tintii
media-gfx/tuxpaint-stamps
media-gfx/tuxpaint
media-gfx/ufraw
media-gfx/uniconvertor
media-gfx/wkhtmltopdf
media-gfx/xli
media-gfx/xloadimage
media-gfx/xzgv
media-libs/cimg
media-libs/esdl
media-libs/flickcurl
media-libs/gd
media-libs/giblib
media-libs/giflib
media-libs/imlib
media-libs/jbigkit
media-libs/jpeg
media-libs/lensfun
media-libs/libexif-gtk
media-libs/libexif
media-libs/libfpx
media-libs/libheif
media-libs/libicns
media-libs/libjpeg-turbo
media-libs/libmng
media-libs/libpano13
media-libs/libpgf
media-libs/libpqstego
media-libs/libraw
media-libs/netpbm
media-libs/opencolorio
media-libs/openimageio
media-libs/openjpeg
media-libs/pnglite
media-libs/stimg
media-libs/tiff
media-libs/urt
virtual/imagemagick-tools
virtual/jpeg-compat
virtual/jpeg
x11-misc/gromit
x11-misc/shutter


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

Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

[Pacho Ramos]

El sáb, 06-06-2020 a las 14:50 -0400, Aaron Bauman escribió:
> All, the graphics project has now been disbanded.
> 
> All packages have been reassigned to maintainer-needed. Bugs will be
> reassigned soon.
> 
> Here are a list of the packages that are now up for grabs:
> 
[...]

I have seen that many of them already have maintainers or co-maintainers, maybe
listing only those that are going to maintainer-needed would be more useful to
catch packages needing attention

Thanks


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

Re: [gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag

[Pacho Ramos]

El jue, 02-04-2020 a las 16:28 +0200, Pacho Ramos escribió:
> Hello,
> 
> I was reviewing about how to enable globally on my system the usage of
> libappindicator and I realized that we have multiple names for that in the
> tree.
> "ayatana" is the only global one, while other packages are using "indicator",
> "libindicate", "appindicator"...
> 
> Personally I would merge all them in only one, and I wonder if maybe
> "indicator"
> or "appindicator" would be more meaningful for most users than "ayatana", what
> do you think?
> 
> Thanks

Personally I would opt for global "appindicator" as it seems to be more widely
used and I think it is a bit more self-explanatory :/


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

[gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag

[Pacho Ramos]

Hello,

I was reviewing about how to enable globally on my system the usage of
libappindicator and I realized that we have multiple names for that in the tree.
"ayatana" is the only global one, while other packages are using "indicator",
"libindicate", "appindicator"...

Personally I would merge all them in only one, and I wonder if maybe "indicator"
or "appindicator" would be more meaningful for most users than "ayatana", what
do you think?

Thanks


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

Re: [gentoo-dev] Last rites: games-misc/OilWar

[Pacho Ramos]

El sáb, 21-03-2020 a las 22:47 +0100, Jonas Stein escribió:
> profiles: Last rite games-misc/OilWar
> 
> Package masked for removal. Broken SRC_URI,
> Bug: https://bugs.gentoo.org/458662
> 
> --
> Best regards,
> Jonas Stein
> 

As far as I remember, if the only issue with the package is that upstream is
dead, we can simply point to https://wiki.gentoo.org/wiki/No_homepage and rely
on our mirrors for the source files (as the package is GPL-2 and has no mirror
restriction)


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

Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

[Pacho Ramos]

El sáb, 21-03-2020 a las 09:01 -0400, Mike Gilbert escribió:
> On Sat, Mar 21, 2020 at 6:43 AM Mart Raudsepp  wrote:
> > Ühel kenal päeval, L, 21.03.2020 kell 11:16, kirjutas Pacho Ramos:
> > > I agree, I see that also Debian is applying it unconditionally even
> > > when running
> > > systemd
> > 
> > But I assume it would be a problem with USE=systemd + USE=-user-session
> > dbus, so how about instead of this profile business, we then just go
> > with:
> > 
> > * Revbump bluez to drop IUSE=user-session, unconditionally apply the
> > patch and change the dbus dep in systemd conditional to
> > > =sys-apps/dbus-1.6:=[user-session(+)]
> > * Fix bluez USE=systemd handling in above revbump as well: --enable-
> > systemd should always be passed, not controlled by a USE=systemd,
> > because all it appears to do is decide whether to install systemd
> > service files, and that should be always done per the small files
> > policy.
> > 
> > * Revbump dbus, dropping user-session IUSE and unconditionally passing
> > --enable-user-session
> 
> I think we should probably move it behind USE=systemd. It should
> probably be that way already, but I missed it when adding the
> user-session flag to the dbus ebuild.
> 
> There is a quite a bit of conditionally compiled code in dbus-daemon
> that gets disabled if --disable-systemd is passed to configure. I
> would guess that dbus.service will not function properly if this code
> is not enabled.
> 
> Since we are dropping user-session from IUSE, the following should suffice:
> 
> $(use_enable systemd user-session)
> 
> > * After some time (dbus revision with IUSE=user-session has been gone
> > for a while), remove all of the IUSE=systemd handling from bluez, as
> > the user-session matching enforcement isn't needed anymore (and the
> > configure systemd conditional has been nuked per above)
> > * At that point the package.use entries can be removed altogether as
> > well, instead of migrating to systemd target profile.
> 
> Agreed on the rest of the plan.

Yes, we can try in that way


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

Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

[Pacho Ramos]

El jue, 19-03-2020 a las 10:35 -0400, Mike Gilbert escribió:
> On Thu, Mar 19, 2020 at 9:41 AM Mart Raudsepp  wrote:
> > Ühel kenal päeval, K, 18.03.2020 kell 16:43, kirjutas Mike Gilbert:
> > > Seems good to me in principle, but I'm not sure it is something we
> > > > should do until we haven't promoted this into a global USE flag.
> > > 
> > > An alternative would be to add entries in package.use.
> > 
> > Yeah, that'd be what it is now, just done in systemd profile, not most
> > of the separate systemd profiles.
> > 
> > > > With the disclaimer of not knowing anything about dbus[user-
> > > > session] on
> > > > a non-systemd system - maybe it's just time to make user-session
> > > > unconditionally enabled on dbus (and then bluez) instead?
> > > > All it seems to do (on a very quick look) is install some extra
> > > > systemd
> > > > files - can't they just be always installed (by always passing --
> > > > enable-user-session) and call it a day?
> > > 
> > > It looks like user-session has no effect if systemd is not in use.
> > > 
> > > On systems running systemd, having the units installed automatically
> > > enables the systemd user bus, and the only way to disable it is to
> > > mask the units. Having the user bus enabled generally prevents
> > > display
> > > managers and startx from starting individual session buses, since
> > > they
> > > will use the user bus instead. That's probably fine, but I wanted to
> > > note it.
> > 
> > So how about we try to just always enable this instead in dbus and
> > bluez? Anyone got any objections, provided the below can be handled?
> > 
> > I peeked at bluez, and there USE=user-session exists to apply a patch
> > to unbreak things when user-session is disabled. Unfortunately it seems
> > to be needed there for non-systemd systems as well. I think we should
> > be able to figure things out to work in all situations there, or make
> > it be applied for USE=-systemd only (that's already the case there,
> > just it is not applied for USE="systemd -user-session" right now).
> 
> I think we can apply
> 0001-Allow-using-obexd-without-systemd-in-the-user-session-r2.patch
> unconditionally.
> 
> The patched unit should work just fine with systemd, provided the user
> bus is available.
> 

I agree, I see that also Debian is applying it unconditionally even when running
systemd


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

Re: [gentoo-dev] [PATCH news] 2020-02-06-python-2-7-eol: news item for py2.7 EOL

[Pacho Ramos]

El mié, 05-02-2020 a las 22:20 +0100, Michał Górny escribió:
> [...]
> +If you are still using Python 2 for your projects, we strongly recommend
> +you to migrate away.  For the time being, it is preferable to use
> +dev-python/virtualenv or a similar solution rather than ebuilds,
> +to install the dependencies for your projects locally.

Is there any link that could provide some guidance about the usage of
pip+virtualenv?

I could only find this
https://wiki.gentoo.org/wiki/Pip

relying on https://wiki.archlinux.org/index.php/Python/Virtual_environment for
virtualenv information.

In my case I am used to pip (as regular user of course), but not with
virtualenv... then, maybe pointing people to some instructions about how to
properly use virtualenv+pip in Gentoo would be useful 

Thanks


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

Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: sci-astronomy/celestia

[Pacho Ramos]

El sáb, 25-01-2020 a las 22:11 +0100, Lars Wendler escribió:
> On Wed, 22 Jan 2020 22:48:22 +0100 Pacho Ramos wrote:
> 
> > El mié, 22-01-2020 a las 10:18 +0100, Lars Wendler escribió:
> > > On Wed, 22 Jan 2020 00:56:48 +0100 David Seifert wrote:
> > > 
> > > > # David Seifert  (2020-01-21)
> > > > # All released versions depend on EOL gtkglext, no revdeps.
> > > > # Bug #644334, #694834. Removal in 30 days.
> > > > sci-astronomy/celestia
> > > 
> > > I've adjusted the mask to not cover the live ebuild. I am still
> > > actively maintaining it and the live ebuild already dropped gtkglext
> > > dependency. Once a new release was rolled I will add that to Gentoo.
> > > The old releases can go. They're way too old and even don't run
> > > anymore with recent nvidia display drivers.
> > > 
> > > Lars
> > > 
> > 
> > Why not provide a git snapshot? At least in Mageia they are relying in
> > one snapshot from the end of Dec 2019 
> > 
> > Thanks
> 
> Hi Pacho,
> 
> once I recover from being sick I can do that.
> 
> Cheers
> Lars
> 

Thanks a lot :)
Take care


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

Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: sci-astronomy/celestia

[Pacho Ramos]

El mié, 22-01-2020 a las 10:18 +0100, Lars Wendler escribió:
> On Wed, 22 Jan 2020 00:56:48 +0100 David Seifert wrote:
> 
> > # David Seifert  (2020-01-21)
> > # All released versions depend on EOL gtkglext, no revdeps.
> > # Bug #644334, #694834. Removal in 30 days.
> > sci-astronomy/celestia
> 
> I've adjusted the mask to not cover the live ebuild. I am still
> actively maintaining it and the live ebuild already dropped gtkglext
> dependency. Once a new release was rolled I will add that to Gentoo.
> The old releases can go. They're way too old and even don't run
> anymore with recent nvidia display drivers.
> 
> Lars
> 

Why not provide a git snapshot? At least in Mageia they are relying in one
snapshot from the end of Dec 2019 

Thanks


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

Re: [gentoo-portage-dev] [PATCH] repoman: add --include-profiles=PROFILES

[Pacho Ramos]

El mar, 19-11-2019 a las 00:21 +, Sergei Trofimovich escribió:
> repoman slows down ~linearly with amount of profiles being scanned.
> In case of amd64 we have 28 stable profiles.
> 
> To speed up processing and fit into time budged of various CIs we can
> split the work across different processes that handle different profiles.
> 
> Example benchmark on ::haskell overlay:
> $ ./repoman full --include-arches=amd64
> ~65 minutes
> $ ./repoman full --include-profiles=default/linux/amd64/17.0
> ~4 minutes
> This allows for a crude sharding of work across processes and allows for
> cheap tree-wide scans for early failures.
> 

Just for knowing (as I guess there is a technical issue preventing that), why
repoman is not trying to check one profile per core in parallel by default by
itself?

Thanks a lot for the info :)


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

[gentoo-dev] net-print/cndrvcups* up for grabs

[Pacho Ramos]

Hello

I almost lost access to the unique printer that was relying on this driver.
Also, even if the current latest version was still working there, it will need a
major update to newer cnRdrvcups driver sooner or later
https://aur.archlinux.org/packages/cnrdrvcups-lb/
https://www.canon-europe.com/support/products/imagerunner/imagerunner-1730i.html?type=drivers=en=linux

Hence, the following packages are up for grabs now
net-print/cndrvcups-common-lb
net-print/cndrvcups-lb

Thanks


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

Re: [gentoo-dev] [PATCH] use.desc: Introduce global USE=magic

[Pacho Ramos]

El dom, 11-08-2019 a las 13:21 +0200, Michał Górny escribió:
> USE=magic is currently used consistently by 12 packages:
> 
> app-arch/engrampa[magic] Enable filetype auto-detection via
>   sys-apps/file
> app-editors/nano[magic] Add magic file support (sys-apps/file) to
>   automatically detect appropriate syntax highlighting
> app-misc/vifm[magic] Use libmagic to determine mimetypes
> app-misc/worker[magic] Add magic file support from sys-apps/file to
>   automatically detect file types
> app-text/zathura[magic] Use libmagic to determine mimetypes
> media-gfx/qiv[magic] Use libmagic to determine mimetypes
> media-libs/libextractor[magic] Enable magic support using sys-apps/file
> media-sound/moc[magic] Use libmagic to determine mimetypes
> net-misc/gerbera[magic] Use libmagic to determine file types
> net-p2p/mldonkey[magic] enable use of libmagic
> sci-geosciences/viking[magic] Use libmagic to determine mimetypes
> www-servers/pshs[magic] Enable automatic detection of Content-Type using
>   libmagic (sys-apps/file)

It seems it should also cover, if possible, this to packages that use an
alternative name:

dev-python/jira:filemagic - Include filemagic support (for identifying uploaded
filetypes)
dev-vcs/git-annex:magicmime - Use libmagic to determine file MIME types



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

Re: [gentoo-dev] [PATCH v2 6/9] acct-{group,user}.eclass: WIP eclasses to maintain users/groups

[Pacho Ramos]

El mié, 05-06-2019 a las 11:12 +0200, Michał Górny escribió:
> [...]
> +# Then you add appropriate dependency to your package.  The dependency
> +# type(s) should be:
> +# - DEPEND (+ RDEPEND) if the group is already needed at build time,
> +# - RDEPEND if it is needed at install time (e.g. you 'fowners' files
> +#   in pkg_preinst),
> +# - PDEPEND if it is only needed at runtime.

Maybe is a stupid question but, why is PDEPEND preferred over RDEPEND for
packages needing the group only at runtime? 

If I don't misremember, PDEPEND was meant to be used to avoid circular deps
issues, while using RDEPEND otherwise

Thanks :)


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

Re: [gentoo-dev] How to deal with defunct projects (whose purpose makes sense)?

[Pacho Ramos]

El jue, 28-03-2019 a las 15:53 +0100, Michał Górny escribió:
> Hello,
> 
> In context of the recent plan of disbanding the Samba team, I'd like to
> ask for better ideas on how to deal with projects that technically make
> sense but are currently dead/defunct.  This means that either they have
> no members, all their members are inactive or simply don't want to work
> on the specific project anymore.
> 
> Of course, the first step is to look for new project members.  However,
> let's assume we've already done that and unsuccessfully.  What should
> happen next?
> 
> So far I've been leaning towards disbanding the project and moving
> packages to maintainer-needed.  This has the advantage of clearly
> indicating that those packages are unmaintained, with all the common
> implications of that.
> 
> However, it also has been pointed out that this frequently 'ungroups'
> packages while being maintained by a single project makes sense for
> them.  I don't really have a strong opinion on this -- especially that
> sometimes this actually helped people decide to take at least some of
> the packages.  On the other hand, Ada is an example of project that has
> been recreated after being disbanded.
> 
> Do you have any suggestions how we could effectively achieve the effect
> similar to 'maintainer-needed' without disbanding projects?
> 

Personally I would keep moving them to maintainer-needed. If some packages
really need to be bumped in sync, we can add a comment to the affected ebuilds
to remember it for any developer taking the package or going to fix some issue
for it.

About recreating the project after, it's ok for me as soon as the new project
has active people for it.

Regards


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

[gentoo-dev] Lastrites: x11-libs/gksu, x11-libs/libgksu, dev-java/ant-nodeps, dev-java/ant-trax, app-admin/localepurge, net-p2p/ppcoind, media-libs/libptp2, sci-libs/spqr...

[Pacho Ramos]

# Pacho Ramos  (11 Nov 2018)
# Dead for years (#425156) with security issues (#534540). Removal in a
# month.
x11-libs/gksu
x11-libs/libgksu

# Pacho Ramos  (11 Nov 2018)
# Both are part of ant-core for years (#466558). Removal in a month.
dev-java/ant-nodeps
dev-java/ant-trax

# Pacho Ramos  (11 Nov 2018)
# Unmaintained for years, buggy (#183273, #491010, #605544). You can rely on
# INSTALL_MASK to skip unwanted locales and install only foo locale:
# INSTALL_MASK="/usr/share/locale -/usr/share/locale/foo"
# Removal in a month.
app-admin/localepurge

# Pacho Ramos  (11 Nov 2018)
# Unmaintained, really old version in the tree with someone needs to get
# bumped (#622572). Removal in a month.
net-p2p/ppcoind

# Pacho Ramos  (11 Nov 2018)
# Our current version is broken for ages (#622722), no maintained, needs to
# be bumped, no reverse deps in the tree. Removal in a month.
media-libs/libptp2

# Pacho Ramos  (11 Nov 2018)
# Completely broken for a long time and uninstallable (#492484, #585516,
# #586582, #627094, #654548). 
sci-libs/spqr
dev-lang/julia
sci-libs/suitesparse

# Pacho Ramos  (11 Nov 2018)
# Dead for years, last package depending on old musicbrainz:3 (#629392).
# Removal in a month.
media-video/gnome-mplayer
www-plugins/gecko-mediaplayer

# Pacho Ramos  (11 Nov 2018)
# Upstream dead for years and marked EOL (#629676, #665850). Removal in a
# month.
dev-db/mysql-proxy

# Pacho Ramos  (11 Nov 2018)
# Unmaintained, fails to build, nothing requires it anymore (#630400).
# Removal in a month.
app-forensics/libbfio

# Pacho Ramos  (11 Nov 2018)
# Needs someone to finally take care of it, bump it and let it be
# installable again (#635476, #645740). Removal in a month.
net-analyzer/nessus-bin

# Pacho Ramos  (11 Nov 2018)
# Pending version bump (#648380), doesn't build (#637350). Removal in a
# month.
sys-apps/likwid

# Pacho Ramos  (11 Nov 2018)
# Doesn't build for a long time (#638096). Removal in a month.
games-action/rafkill

# Pacho Ramos  (11 Nov 2018)
# Dead for a long time, failing tests (#638376), nothing requires it
# anymore. Removal in a month.
dev-python/flask-testing

# Pacho Ramos  (11 Nov 2018)
# Doesn't build for a long time (#638710), nothing requires it. Removal in a
# month.
app-emulation/vpcs

# Pacho Ramos  (11 Nov 2018)
# Fails to build with current glibc (#638840). Removal in a month.
sys-devel/heirloom-devtools

# Pacho Ramos  (11 Nov 2018)
# Fails to build for a long time (#639844). Removal in a month.
dev-embedded/scratchbox2

# Pacho Ramos  (11 Nov 2018)
# Fails to build with current gcc (#640926), file collisions (#630668), no
# reverse deps. Removal in a month.
media-video/sswf

# Pacho Ramos  (11 Nov 2018)
# Replaced by libunibreak and no reverse deps (#640974). Removal in a month.
dev-libs/liblinebreak

# Pacho Ramos  (11 Nov 2018)
# Fails at runtime (#645690). Removal in a month.
dev-lang/gnu-smalltalk

# Pacho Ramos  (11 Nov 2018)
# Replaced by dev-db/percona-toolkit, cannot be fetched (#645984). Removal
# in a month.
dev-db/maatkit

# Pacho Ramos  (11 Nov 2018)
# Unmaintained and buggy (#648204). Removal in a month.
mail-filter/razor

# Pacho Ramos  (11 Nov 2018)
# Unmaintained, upstream dead, fails to build (#650084). Removal in a month.
sys-power/suspend

# Pacho Ramos  (11 Nov 2018)
# Merged into >=app-portage/gentoolkit-0.4 (#659412). Removal in a month.
app-portage/gentoolkit-dev

# Pacho Ramos  (11 Nov 2018)
# Broken since python 3.6 (#659414), buggy (#640372, #607666). Removal in a
# month.
app-portage/gs-pypi

# Pacho Ramos  (11 Nov 2018)
# Fails at runtime (#661746). Removal in a month.
games-roguelike/mangband

# Pacho Ramos  (11 Nov 2018)
# Nobody is taking care of them, use the ones provided by the maintained
# sys-kernel/linux-firmware package (#661884). Removal in a month.
net-dialup/ueagle-atm
net-dialup/ueagle4-atm

# Pacho Ramos  (11 Nov 2018)
# Fails to build (#662000), not compatible with kernel-4, use kernel driver
rtsx_pci
# instead. Removal in a month.
sys-block/rts_pstor

# Pacho Ramos  (11 Nov 2018)
# Fails to run (#662180). Removal in a month.
app-text/chm2pdf

# Pacho Ramos  (11 Nov 2018)
# Unmaintained, security issues (#630796, #663164). Removal in a month.
dev-db/couchdb

# Pacho Ramos  (11 Nov 2018)
# Unkeyworded since 2008, non-installable (#664680). Removal in a month.
sys-fs/devfsd

# Pacho Ramos  (11 Nov 2018)
# Orphan, no reverse deps, dead since 2003 (#665046, #521242). Removal in a
# month.
app-text/clara

# Pacho Ramos  (11 Nov 2018)
# Merged into >=media-tv/mythtv-29, bug #665924. Removal in a month.
media-plugins/mythplugins

# Pacho Ramos  (11 Nov 2018)
# No reverse deps, obsoleted in 2016 (#666130). Removal in a month.
dev-python/jenkins-webapi

# Pacho Ramos  (11 Nov 2018)
# Build issues (#666166), upstream dead for years (#619624). Removal in a
# month.
media-plugins/vdr-image
media-plugins/vdr-picselshow

# Pacho Ramos  (11 Nov 2018)
# Dead for years, no reverse deps (#665046). Removal in a month.
app-tex

Re: [gentoo-dev] Add GOBIN to ENV_UNSET in make.defaults

[Pacho Ramos]

El sáb, 20-10-2018 a las 18:59 -0700, Zac Medico escribió:
> On 10/20/2018 04:21 AM, Pacho Ramos wrote:
> > It seems that random values in GOBIN can affect the building of some
> > packages:
> > https://bugs.gentoo.org/631776
> > https://bugs.gentoo.org/636506
> > https://bugs.gentoo.org/638572
> > 
> > I would then append it to ENV_UNSET in make.defaults to get that variable
> > unset
> > without needing to do the same for every ebuild that could be affected by
> > this
> > 
> > Any issues against this?
> 
> Seems reasonable, since the only purpose of GOBIN is to override the
> directory where 'go install' will install a command. If we unset it
> unconditionally, it means that the location will predictably default to
> GOPATH/bin, which is exactly what we want.
> 
> We could handle it in the golang-build_src_install function, but that
> wouldn't cover things that call 'go install' via a script or Makefile.
> 
> > Thanks
> > 

Done: 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c06caedd7c6bb91be0b8e963eb2
cb98e74448f67


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

[gentoo-dev] Lastrites: dev-java/ant-nodeps, dev-java/ant-trax, dev-python/pyramid, dev-libs/libstrl, dev-util/difffilter, app-crypt/tinyca...

[Pacho Ramos]

# Pacho Ramos  (04 Nov 2018)
# Both are part of ant-core for years (#466558). Removal in a month.
dev-java/ant-nodeps
dev-java/ant-trax

# Pacho Ramos  (04 Nov 2018)
# Unmaintained, needs someone to take care of bumping and maintaining it
# (#509518). Removal in a month.
dev-python/pyramid

# Pacho Ramos  (04 Nov 2018)
# Fails to build (#538174), upstream dead for ages. Removal in a month.
dev-libs/libstrl
dev-util/difffilter

# Pacho Ramos  (04 Nov 2018)
# Upstream dead, multiple unresolved bugs (#540622). Removal in a month.
app-crypt/tinyca

# Pacho Ramos  (04 Nov 2018)
# gitorious was closed (#544812), nothing needs it in the tree and we only
# provide a live ebuild. Removal in a month.
app-benchmarks/os-autoinst

# Pacho Ramos  (04 Nov 2018)
# Pending version bumps (with security fixes) for a long time (#550188,
# #544568, #227993). Removal in a month.
www-apps/moinmoin

# Pacho Ramos  (04 Nov 2018)
# Nobody willing to update and maintain this for years (#556306, #554488).
# Removal in a month.
net-proxy/squidclamav
net-proxy/c-icap

# Pacho Ramos  (04 Nov 2018)
# Outdated, doesn't respect CC, installs files in /usr/local (#565894,
# #664370). Removal in a month.
www-client/dooble

# Pacho Ramos  (04 Nov 2018)
# Outdated, move to media-gfx/slic3r or other online alternatives (#570324).
# Removal in a month.
media-gfx/replicatorg

# Pacho Ramos  (04 Nov 2018)
# Build issues (#587866), outdated, nothing needs it in the tree. Removal in
# a month.
dev-libs/libsolv

# Pacho Ramos  (04 Nov 2018)
# Build issues (#590316, #603300), no reverse deps, needs a major version
# bump. Removal in a month.
dev-lua/lua-openssl

# Pacho Ramos  (04 Nov 2018)
# Upstream dead for ages, crashes (#637286), build issues (#592580).
# Migration to Google fork or other alternative will be needed. Removal in a
# month.
net-misc/tlsdate

# Pacho Ramos  (04 Nov 2018)
# Hard to bump (#480160), uses get_libdir at global scope (#593400). Removal
# in a month.
net-analyzer/w3af

# Pacho Ramos  (04 Nov 2018)
# pkg_postinst calls pkg_config (#596648), upstream dead for ages. Removal
# in a month.
sys-auth/bioapi
sys-auth/tfm-fingerprint
sys-auth/pam_bioapi

# Pacho Ramos  (04 Nov 2018)
# Dead for ages, not needed anymore (#596988). Removal in a month.
sys-power/upower-pm-utils

# Pacho Ramos  (04 Nov 2018)
# Broken and outdated (#445476, #448934, #599580). Removal in a month.
media-plugins/mediastreamer-silk

# Pacho Ramos  (04 Nov 2018)
# Fails to build (#601886), dead for a long time. Removal in a month.
media-gfx/gimmage

# Pacho Ramos  (04 Nov 2018)
# Fringe format, nothing really uses it, upstream disappeared, not really
# working for some time (#602938). Removal in a month.
media-libs/schroedinger


# Pacho Ramos  (04 Nov 2018)
# Needs someone to maintain it and bump to a snapshot not relying on
# gstreamer:0.10 (#610434, #560254). Removal in a month.
app-accessibility/pocketsphinx

# Pacho Ramos  (04 Nov 2018)
# Fails to build, hard to bump (#608908). Removal in a month.
net-nntp/inn

# Pacho Ramos  (04 Nov 2018)
# Dead since 2005, nobody else still ships it, it creates cruft dirs in /
# (#565592). Removal in a month.
app-admin/syslogread


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

[gentoo-dev] Lastrites: sys-cluster/cman and co.

[Pacho Ramos]

# Pacho Ramos  (04 Nov 2018)
# Upstream dead for many years and nobody taking care of them, bug #443842,
# bug #618050. Removal in a month.
sys-cluster/cman
sys-cluster/ccs
sys-cluster/rgmanager
sys-cluster/rgmanager-agents
sys-cluster/libdlm
sys-cluster/fence-agents
sys-cluster/libccs
sys-cluster/libccs-perl
sys-cluster/libcman
sys-cluster/libfence
sys-cluster/liblogthread


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

[gentoo-dev] Lastrites: mail-filter/assp, www-apps/lxr, app-misc/iguanaIR, net-analyzer/nagvis, media-plugins/alsaequal...

[Pacho Ramos]

# Pacho Ramos  (01 Nov 2018)
# Outdated, security issues (#629442), dead since 2014 (#405527).
# Removal in a month.
mail-filter/assp

# Pacho Ramos  (01 Nov 2018)
# Outdated, needs to be bumped to latest release to fix multiple security
# bugs (#444368). Removal in a month.
www-apps/lxr

# Pacho Ramos  (01 Nov 2018)
# Needs to be bumped (#475330), build issues (#521094), install files in
# /dev (#452248), ignores CFLAGS (#452244). Removal in a month.
app-misc/iguanaIR

# Pacho Ramos  (01 Nov 2018)
# Needs a major version bump to a version that is security audited
# (#477742). Removal in a month.
net-analyzer/nagvis

# Pacho Ramos  (01 Nov 2018)
# Buggy (#499298), upstream is dead for a long time, maybe a switch to one
# of the existing forks would be needed, abi_x86_32 doesn't work (#524498).
# Removal in a month.
media-plugins/alsaequal

# Pacho Ramos  (01 Nov 2018)
# Unmaintained, installs files in runtime dirs (#520626), requires old
# libosip. Removal in a month.
net-misc/siproxd

# Pacho Ramos  (01 Nov 2018)
# Needs a major version bump to work with recent db versions (#529966).
# Removal in a month.
net-proxy/c-icap-modules

# Pacho Ramos  (01 Nov 2018)
# 2.90 slot of VTE is deprecated for a long time in favor of 2.91, no
# reverse deps (#538140). Removal in a month.
=x11-libs/vte-0.36.5

# Pacho Ramos  (01 Nov 2018)
# All this packages are broken and need major version bumps to fix them. See
# bug #504114, #486510, #510550, #511096, #517260, #551784, #616490, #
net-voip/linphone
net-libs/libeXosip
net-libs/libosip


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

[gentoo-dev] Lastrites: media-gfx/splashutils

[Pacho Ramos]

# Pacho Ramos  (21 Oct 2018)
# Lots of pending bugs for years, this needs a dedicated maintainer that
# fixes them: bug #354157, #354639, #398075, #398077, #417375, #499654,
# #539358, #591682, #625798, #639912, #662316, #664270...
# Removal in a month.
media-gfx/splashutils
media-gfx/bootsplash-themes
media-gfx/splash-themes-gentoo
media-gfx/splash-themes-livecd
media-gfx/splash-themes-livedvd

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

[gentoo-dev] Add GOBIN to ENV_UNSET in make.defaults

[Pacho Ramos]

It seems that random values in GOBIN can affect the building of some packages:
https://bugs.gentoo.org/631776
https://bugs.gentoo.org/636506
https://bugs.gentoo.org/638572

I would then append it to ENV_UNSET in make.defaults to get that variable unset
without needing to do the same for every ebuild that could be affected by this

Any issues against this?

Thanks

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

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-admin/sysrqd
app-antivirus/skyldav
app-misc/blink1
app-misc/digitemp
dev-db/sqldeveloper
dev-libs/cyberjack
dev-util/sel
net-dns/dnscap
net-im/mcabber
net-libs/loudmouth
net-misc/connect
net-misc/gwhois
sys-apps/dstat
sys-auth/ykneo-ccid-tools
sys-auth/yubikey-personalization-gui
sys-power/sispmctl

[gentoo-dev] Lastrites: net-misc/whatportis

[Pacho Ramos]

# Pacho Ramos  (28 Jun 2018)
# Doesn't work at all (#645388). Removal in a month
net-misc/whatportis

[gentoo-dev] Lastrites: dev-python/pyrtf

[Pacho Ramos]

# Pacho Ramos  (28 Jun 2018)
# Doesn't work, dead since 2005, bug #658984. Removal in a month.
dev-python/pyrtf

[gentoo-dev] Lastrites: app-misc/jira-cli

[Pacho Ramos]

# Pacho Ramos  (28 Jun 2018)
# Cannot be imported, bug #659410. Removal in a month.
app-misc/jira-cli

Re: [gentoo-dev] [PATCH 02/10] gnome2.eclass: move icon handling code to xdg.eclass

[Pacho Ramos]

El mar, 26-06-2018 a las 20:27 -0500, Marty E. Plummer escribió:
> Package-Manager: Portage-2.3.40, Repoman-2.3.9
> ---
>  eclass/gnome2.eclass |  9 +
gnome2.eclass would also need to fix this regression in eapi6 (https://bugs.gent
oo.org/613364) and to deprecate ltprune.eclass usage (https://bugs.gentoo.org/65
8638)

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

[Pacho Ramos]

El dom, 17-06-2018 a las 19:47 -0500, Marty E. Plummer escribió:
> Use ${EROOT%/} whereever possible, as most of the directories and files
> used in conjunction with it have a leading /; add missing leading /
> where apropriate. Put sys-apps/sed into BDEPEND if EAPI 7, as it need to
> be executable on CBUILD.
> 
> Signed-off-by: Marty E. Plummer 
> Package-Manager: Portage-2.3.40, Repoman-2.3.9
> ---
>  eclass/gnome2-utils.eclass | 43 +++---
>  1 file changed, 22 insertions(+), 21 deletions(-)
> 

We would need to handle:
https://bugs.gentoo.org/615144#c12

to not need to workaround it in gimp ebuild (or any other using their customized
"DEPRECATED" macros) forever

I have also just seen this bug about needing to use EROOT in some tools:
https://bugs.gentoo.org/611030

Re: [gentoo-dev] Lastrites: games-arcade/xevil, x11-plugins/wmlaptop, dev-java/servletapi, dev-java/sun-jacc-api...

[Pacho Ramos]

El dom, 17-06-2018 a las 16:14 +0300, Mart Raudsepp escribió:
> Ühel kenal päeval, P, 17.06.2018 kell 14:24, kirjutas Pacho Ramos:
> > # Pacho Ramos  (17 Jun 2018)
> > # Needs someone to maintain this package and bump it to newer
> > versions
> > # stopping to rely on dead gstreamer:0.10 (#438972). Removal in a
> > month.
> > media-video/aravis
> 
> lu_zero bumped this to 0.5.10 with gstreamer:1.0 usage 2 weeks ago..
> I don't know why he didn't check and update bugs.
> 
> 
> Mart

Just unmasked

[gentoo-dev] Lastrites: games-arcade/xevil, x11-plugins/wmlaptop, dev-java/servletapi, dev-java/sun-jacc-api...

[Pacho Ramos]

# Pacho Ramos  (17 Jun 2018)
# Doesn't work on amd64, upstream dead for ages, bug #254510
# Removal in a month.
games-arcade/xevil

# Pacho Ramos  (17 Jun 2018)
# Doesn't work (#348124), dead since 2004. Removal in a month.
x11-plugins/wmlaptop

# Pacho Ramos  (17 Jun 2018)
# Package obsolete since many years ago (#398689). Removal in a month.
dev-java/servletapi
dev-java/sun-jacc-api

# Pacho Ramos  (17 Jun 2018)
# Needs a major version bump to stop relying on old versions of other libs
# (#421427). Removal in a month.
dev-java/easyneurons

# Pacho Ramos  (17 Jun 2018)
# Needs someone to maintain this package and bump it to newer versions
# stopping to rely on dead gstreamer:0.10 (#438972). Removal in a month.
media-video/aravis

# Pacho Ramos  (17 Jun 2018)
# Fails to run because it requires a bundled lib as unmaintained as this
# package by upstream (#472752). Removal in a month.
net-misc/nemesis

# Pacho Ramos  (17 Jun 2018)
# Upstream dead for ages, relies on dead gstreamer:0.10 (#552528). Removal
# in a month.
x11-misc/winswitch

# Pacho Ramos  (17 Jun 2018)
# Obsolete package not needed for a long time, bug #559994. Removal in a
# month.
dev-java/jdom-jaxen
=dev-java/jdom-1.0-r4

# Pacho Ramos  (17 Jun 2018)
# Fails to build, nothing requires it (#561366, #579600, #618936). Removal
# in a month.
net-misc/openvpn-auth-ldap

# Pacho Ramos  (17 Jun 2018)
# Supposedly working with wxGTK:3.0 but with bugs that upstream never fixed,
# this would be the last package still needing old wxGTK:2.8 to workaround
# this bugs (#597194). Removal in a month except if someone figures out
# about how to solve this bugs.
net-p2p/amule

# Pacho Ramos  (17 Jun 2018)
# Upstream dead for a long time, bug #606194. Removal in a month.
dev-libs/DirectFB

# Pacho Ramos  (17 Jun 2018)
# Not usable anymore after server shutdown (#608806). Removal in a month.
games-fps/postal2mp-demo

# Pacho Ramos  (17 Jun 2018)
# Segfaults at start (#612322). Removal in a month.
games-arcade/snake3d

# Pacho Ramos  (17 Jun 2018)
# tests fail with python >= 3.4 (#620082), nothing requires this package,
# removal in a month.
dev-python/eliot

# Pacho Ramos  (17 Jun 2018)
# Not compatible with recent python versions (#624668), needs a major
# version bump. Removal in a month.
dev-python/django-two-factor-auth

# Pacho Ramos  (17 Jun 2018)
# Fails to build (#624688). Removal in a month.
sci-physics/hoomd-blue

# Pacho Ramos  (17 Jun 2018)
# Upstream dead, relies on obsolete gstreamer:0.10. Please use alternatives
# (like soundconverter) instead (#629182). Removal in a month.
media-sound/gnac

# Pacho Ramos  (17 Jun 2018)
# Fails to run (#630576). Removal in a month.
games-simulation/dangerdeep

# Pacho Ramos  (17 Jun 2018)
# frogr is a good replacement for this old package still relying on dead
# gnome2 python bindings (#640046). Removal in a month.
media-gfx/postr

# Pacho Ramos  (17 Jun 2018)
# Fails to fetch (#640572). Removal in a month.
games-puzzle/triptych-demo

# Pacho Ramos  (17 Jun 2018)
# Fails to fetch (#640584). Removal in a month.
games-strategy/gorky17-demo

# Pacho Ramos  (17 Jun 2018)
# Dead since 2013, not compatible with latest profiles (#642568). Removal in
# a month
net-vpn/miredo

# Pacho Ramos  (17 Jun 2018)
# Fails to build (#642996). Removal in a month.
games-engines/gargoyle

# Pacho Ramos  (17 Jun 2018)
# Fails to compile (#648430), crashes from time to time (#222065). Removal
# in a month.
app-misc/wyrd

# Pacho Ramos  (17 Jun 2018)
# Not compatible with recent perl, not needed by anything in the tree
# (#648582). Removal in a month.
app-doc/mkdoxy 

# Pacho Ramos  (17 Jun 2018)
# Not compatible with recent PHP, upstream dead for ages (#650870, #650934)
#, removal in a month.
www-apps/gnopaste
www-apps/openwebstats

# Pacho Ramos  (17 Jun 2018)
# Upstream dead, security vulnerable (#650936). Removal in a month.
www-apps/phprojekt

# Pacho Ramos  (17 Jun 2018)
# Doesn't run, cannot bump it (#651146). Removal in a month.
games-emulation/hatari

# Pacho Ramos  (17 Jun 2018)
# Doesn't work even with current PHP versions, upstream dead (#651148),
# removal in a month.
www-apps/mypictures

# Pacho Ramos  (17 Jun 2018)
# Doesn't work with PHP7, dead upstream (#651184, #651194), removal in a month.
www-apps/phpmp
www-apps/polarblog

# Pacho Ramos  (17 Jun 2018)
# Multiple bugs (#424383, #554944), upstream dead (#651340). Removal in a
# month.
net-irc/ircservices

# Pacho Ramos  (17 Jun 2018)
# Dead since 2002, orphan, nothing requires it (#651344). Removal in a
# month.
app-text/rhyme

# Pacho Ramos  (17 Jun 2018)
# Dead lib not used by anything in the tree (#652186). Removal in a month.
net-libs/libwhisker

# Pacho Ramos  (17 Jun 2018)
# Obsolete package for the old documentation system (#653168). Removal in a
# month.
app-text/gentoo-guide-xml-dtd

# Pacho Ramos  (17 Jun 2018)
# Dead for ages, nothing requires it, needs klibc (that is also completely
# unmaintained in our side) (#653390). Removal in a month.
sys-b

Re: [gentoo-dev] Current status with openssl-1.1

[Pacho Ramos]

El sáb, 09-06-2018 a las 10:22 +0200, Lars Wendler escribió:
> 
> [...[

> some point.
> 
> So, basically openssl is the last big showstopper for openssl-1.1 to
> get out of p.mask. There are some inofficial patches floating around in
> the WWW but each one of them has some issues and they all are not
> really small in size.
> Last time I checked, the most complete (but still to some degree
> broken) patch had 2800+ LOC and was 80K in size. This is definitely
> nothing I want to maintain as downstream, left aside the fact that
> openssh should not be messed with lightly regarding security
> implications.

Why don't try to use RedHat/Fedora patch for openssl-1.1 compat? It seems they
are taking care of maintaining that patch on their side

> 
> My biggest concern right now is that openssh might still block
> openssl-1.1.1 once that got released. openssl-1.1.1 provides TLSv1.3
> which is something we should provide to our users as soon as possible
> and is also targeted as next LTS release.
> 
> 
> 
> [1] https://bugs.gentoo.org/592438
> [2] https://bugs.gentoo.org/592578
> 

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

[Pacho Ramos]

El vie, 27-04-2018 a las 00:48 -0700, Zac Medico escribió:
> On 04/26/2018 11:34 PM, Kent Fredric wrote:
> > On Thu, 26 Apr 2018 13:35:15 -0700
> > Zac Medico  wrote:
> > 
> > > emerge --depclean, resulting in an unbootable system. Just say-in.
> > 
> > And depclean being very verbose doesn't do many favours here either.
> > 
> > ( I regularly do >500 package depcleans and spotting things that aren't
> > meant to be
> >  culled amongst that list is a bit of a challenge )> 
> 
> At least for system packages, it will show a warning like the one shown
> here:
> 
>https://bugs.gentoo.org/642484#c0
> 
> Hopefully that message helps those that are paying enough attention.
> What can we do for those that overlook the warning message, other than
> give them some rescue instructions for making their system boot again?

Have you think in changing a bit the behavior of depclean to *not* depclean
system packages and ask administrator to do something like "emerge -a 
--depclean 
--force" to force the depclean of that packages?

That could help to prevent that mistakes I think

Thanks

Re: [gentoo-dev] Project:Lisp without members

[Pacho Ramos]

El mié, 21-03-2018 a las 10:51 +0200, Mart Raudsepp escribió:
> Ühel kenal päeval, L, 10.03.2018 kell 13:26, kirjutas Pacho Ramos:
> > From now Project:Lisp has no members... that doesn't seem an issue as
> > it
> > contains multiple subprojects that maintain relevant packages... but,
> > for the
> > case anyone wants to join the main project...
> > https://wiki.gentoo.org/wiki/Project:Lisp
> 
> This is a valid setup of projects to my knowledge. Please correct me if
> I'm wrong. Don't undertake parent projects if they have subprojects
> with active members please. In other words, please don't undertake a
> project if it has active subprojects, if that was your mails intention
> here.
> https://wiki.gentoo.org/wiki/Project:Lisp even lists subprojects and
> their members as part of lisp project. Though it seems to have gotten a
> direct member now too to prevent the implicit undertaking intention
> (which I think is unnecessary).
> 
> 
There were no "undertaking intention" for that parent project as the mail states
showing no warning about removing it and even suggesting that "it doesn't seem
an issue"... the intention was merely to inform people for the case someone
wanted to joing the Project

[gentoo-dev] Lastrites: net-dns/hesiod, games-arcade/monkey-bubble, app-shells/scsh-install-lib, dev-db/mysql-udf-infusion...

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Unresolved security issues (#606652), tests fail (#628622, #337249).
# Removal in a month.
net-dns/hesiod

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Depends on gstreamer:0.10 and many more dead libs (#629174), upstream dead
# for ages (#634490). Removal in a month.
games-arcade/monkey-bubble

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Fails to build (#629622, #614576, #627408). Removal in a month.
app-shells/scsh-install-lib

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Upstream dead, not compatible with MariaDB (#629902). Removal in a month.
dev-db/mysql-udf-infusion

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Doesn't build (#630252). Removal in a month.
dev-python/visual

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Version bump pending for a long time, depends in QT4 (#630476). Removal in
# a month.
x11-misc/treeline

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Security vulnerable (#630954, #635548). Removal in a month. 
media-sound/mp3gain
media-sound/aacgain

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Security vulnerable (#631602). Removal in a month.
net-proxy/httpush

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Security vulnerable (#631720), dead since 2008, uses doman with compressed
# man pages (#619952). Removal in a month.
mail-filter/p3scan

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Doesn't build (#634116), use games-action/dxx-rebirth instead. Removal in
# a month.
games-action/d2x-rebirth

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Fails at runtime (#634258). Removal in a month.
net-irc/savirc

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Fails to build (#634662), version bump long time pending (#596162).
# Removal in a month.
games-emulation/sdlmame

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Multiple vulnerabilities (#635598). Removal in a month.
www-apps/b2evolution
 
# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Superseeded by adwaita-icon-theme for years, also having both installed at
# the same time causes some apps to use old icons over new ones (#638142).
# Removal in a month.
x11-themes/gnome-icon-theme

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Completely dead and unmaintained for years, multiple alternatives in the
# tree (#638812). Removal in a month.
media-gfx/pornview

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Not installable (#639130), version bump long time pending (#489156),
# restricts userpriv (#516578). Removal in a month.
mail-filter/qmail-scanner

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Fail to fetch (#640544, #640596, #640602). Removal in a month.
media-video/vcdgear
net-misc/yangcli-pro

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Outdated and useless (#642158). Removal in a month.
app-i18n/man-pages-ro

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Forces the usage of obsolete dev-python/mysql-python (#643502). Dead since
# 2013. Removal in a month.
app-backup/holland-lib-mysql
app-backup/holland-backup-mysqldump
app-backup/holland-backup-mysql-meta
app-backup/holland-backup-mysql-lvm
app-backup/holland-backup-mysqlhotcopy

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Forces downgrade of mock (#643506). Removal in a month.
dev-python/django-social-auth

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Requires old dev-python/oauth2client (#643534), tests fail (#527608).
# Removal in a month.
net-misc/gsutil

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Requires old psycopg (#643614). Removal in a month.
dev-python/adodb-py

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Requires old whoosh (#643690). Removal in a month.
dev-python/flask-whooshalchemy

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Requires old redis-py and gevent (#643692). Removal in a month.
dev-python/pyzor

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Requires old leveldb, live ebuild, dead since 2013 (#644310). Removal in a
# month.
net-p2p/datacoin-hp

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Dead since 2011, relies on dead libraries (#644322, #644326, #644330, #644332
# #644340, #647600, #647608, #647698, #647700, #648998). Removal in a month.
dev-util/alleyoop
gnome-extra/gnome-color-chooser
media-sound/neutrino
media-video/camorama
www-misc/gurlchecker
games-board/gnome-mastermind
media-sound/quark
app-office/gtimelog
x11-libs/libdesktop-agnostic
x11-misc/dockmanager
games-arcade/monster-masher

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Relies on dead QT4 (#644422), build issues (#629728). Removal in a month.
media-video/videocut

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Depends on dead QT4 (#644480). Removal in a month.
sci-electronics/plcedit

# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Tests fail, package has no reverse deps an

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-arch/rpm
app-benchmarks/os-autoinst
dev-util/hxtools
dev-util/obs-service-cpanspec
dev-util/obs-service-download_files
dev-util/obs-service-download_src_package
dev-util/obs-service-download_url
dev-util/obs-service-extract_file
dev-util/obs-service-format_spec_file
dev-util/obs-service-generator_driver_update_disk
dev-util/obs-service-github_tarballs
dev-util/obs-service-git_tarballs
dev-util/obs-service-meta
dev-util/obs-service-rearchive
dev-util/obs-service-recompress
dev-util/obs-service-set_version
dev-util/obs-service-source_validator
dev-util/obs-service-tar_scm
dev-util/obs-service-update_source
dev-util/obs-service-verify_file
dev-util/osc
dev-util/spec-cleaner
dev-util/suse-build

[gentoo-dev] Lastrites: net-libs/netembryo, net-misc/netkit-rwall, sci-electronics/balsa, media-tv/me-tv, sci-biology/beast-mcmc, sys-power/phc-k8...

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Tests need network, nothing requires this old lib anymore and upstream is
# dead for a long time (#335233). Removal in a month.
net-libs/netembryo

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Fails to build (#371401, #642676). Removal in a month.
net-misc/netkit-rwall

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Incomplete and unclear LICENSE, missing files in SRC_URI (#472602).
# Removal in a month.
sci-electronics/balsa

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Upstream dead for a long time, requires obsolete gstreamer and other old
# libs (#629192), buggy (#490344). Removal in a month.
media-tv/me-tv

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Doesn't build for a long time (#514432). Removal in a month.
sci-biology/beast-mcmc

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Fails to build (#514632, #585606, #588710). Removal in a month.
sys-power/phc-k8

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Fails to build for a long time (#515734, 649840). Removal in a month.
sys-fs/gfs2-utils

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Dead driver and with many incompatibilities with current kernels (#517250,
# #523356, #551834, #646106). Removal in a month. Possible alternative
# #device/driver: https://bugs.gentoo.org/517250#c5
net-wireless/broadcom-sta 

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Not buildable for a long time (#531586), pending many version bumps.
# Removal in a month.
media-sound/mup

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Many other ident daemons in the tree over this completely dead and
# unmaintained (since 2003) implementation (#535868). Removal in a month.
net-misc/linux-identd

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Major version bump pending (#540322), current version in the tree is
# completely broken in several ways (#471428, #598260, #621784, #638364).
# Removal in a month.
sys-cluster/gearmand
dev-php/pecl-gearman

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Not buildable and ends up needing old guile-1.8 (#547186, #617802), major
# version bump pending (#515888). Removal in a month.
media-sound/denemo

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Hard to bump (#547418), build issues (#600308). Removal in a month.
app-forensics/libewf
app-forensics/rdd

# Pacho Ramos <pa...@gentoo.org> (13 Mar 2018)
# Many pending version bumps (#574874), doesn't run (#587112), doesn't use
# python eclasses (#613892), needs obsolete libs (#640888). Removal in a
# month.
net-p2p/tribler

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
net-irc/anope
net-irc/ircservices
net-irc/psybnc
net-wireless/hostapd

Re: [gentoo-dev] Project:SuSE without members

[Pacho Ramos]

El dom, 11-03-2018 a las 11:32 +0100, Andreas Sturmlechner escribió:
> On Samstag, 10. März 2018 14:20:45 CET Pacho Ramos wrote:
> > From now Project:SuSE has no members anymore, they maintain this packages
> > (that will go to maintainer-needed in a week if Project is still without
> > members at that time)
> 
> Just in case this is the list you use for dropping to maintainer needed as 
> well - at least
> 
> > app-backup/kfoldersync
> > app-text/diction
> 
> are false positives, and probably several others. Your 'suse' grep matches 
> packages with opensuse URLs or words like 'misused' in description text.
> 
> Regards
> 

Ah, yes, this is the list then
app-arch/rpm
app-benchmarks/os-autoinst
dev-util/hxtools
dev-util/icemon
dev-util/obs-service-cpanspec
dev-util/obs-service-download_files
dev-util/obs-service-download_src_package
dev-util/obs-service-download_url
dev-util/obs-service-extract_file
dev-util/obs-service-format_spec_file
dev-util/obs-service-generator_driver_update_disk
dev-util/obs-service-github_tarballs
dev-util/obs-service-git_tarballs
dev-util/obs-service-meta
dev-util/obs-service-rearchive
dev-util/obs-service-recompress
dev-util/obs-service-set_version
dev-util/obs-service-source_validator
dev-util/obs-service-tar_scm
dev-util/obs-service-update_source
dev-util/obs-service-verify_file
dev-util/osc
dev-util/quilt
dev-util/spec-cleaner
dev-util/suse-build
media-fonts/fifth-leg
sys-devel/icecream

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
dev-embedded/mcu8051ide

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
x11-misc/kbdd
x11-themes/comix-xcursors

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-text/pspdftool
app-admin/supernova
dev-python/args
dev-python/attrdict
dev-python/behave
dev-python/clint
dev-python/dockerpty
dev-python/doublex-expects
dev-python/doublex
dev-python/expects
dev-python/ghp-import
dev-python/linecache2
dev-python/livereload
dev-python/mamba
dev-python/mando
dev-python/mkdocs-bootstrap
dev-python/mkdocs
dev-python/monotonic
dev-python/mypy
dev-python/nose2
dev-python/os-client-config
dev-python/paramunittest
dev-python/parse
dev-python/parse-type
dev-python/pycallgraph
dev-python/pyhamcrest
dev-python/pytest-raisesregexp
dev-python/python-termstyle
dev-python/radon
dev-python/sphinxcontrib-cheeseshop
dev-python/sphinxcontrib-newsfeed
dev-python/sphinxcontrib-spelling
dev-python/stormpath
dev-python/texttable
dev-python/torment
dev-python/traceback2
dev-python/typing

[gentoo-dev] Project:Lisp without members

[Pacho Ramos]

>From now Project:Lisp has no members... that doesn't seem an issue as it
contains multiple subprojects that maintain relevant packages... but, for the
case anyone wants to join the main project...
https://wiki.gentoo.org/wiki/Project:Lisp

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
dev-lang/gnu-smalltalk
x11-misc/fluxter
x11-themes/commonbox-styles-extra
x11-themes/commonbox-styles
x11-themes/fluxbox-styles-fluxmod
x11-wm/fluxbox

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-text/pspdftool
sys-power/acpid
x11-libs/libyui-gtk
x11-libs/libyui
x11-libs/libyui-ncurses
x11-libs/libyui-qt

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-portage/repo-commit
dev-libs/libstrl
net-irc/unrealircd

[gentoo-dev] Project:SuSE without members

[Pacho Ramos]

>From now Project:SuSE has no members anymore, they maintain this packages (that
will go to maintainer-needed in a week if Project is still without members at
that time)
Thanks
app-arch/rpm
app-backup/kfoldersync
app-backup/snapper
app-benchmarks/os-autoinst
app-text/diction
dev-lang/inform
dev-python/pyinsane
dev-util/hxtools
dev-util/icemon
dev-util/obs-service-cpanspec
dev-util/obs-service-download_files
dev-util/obs-service-download_src_package
dev-util/obs-service-download_url
dev-util/obs-service-extract_file
dev-util/obs-service-format_spec_file
dev-util/obs-service-generator_driver_update_disk
dev-util/obs-service-github_tarballs
dev-util/obs-service-git_tarballs
dev-util/obs-service-meta
dev-util/obs-service-rearchive
dev-util/obs-service-recompress
dev-util/obs-service-set_version
dev-util/obs-service-source_validator
dev-util/obs-service-tar_scm
dev-util/obs-service-update_source
dev-util/obs-service-verify_file
dev-util/osc
dev-util/quilt
dev-util/spec-cleaner
dev-util/suse-build
media-fonts/fifth-leg
sys-devel/icecream

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-editors/xmlcopyeditor
app-pda/barry
dev-libs/chmlib
dev-util/ftjam
net-p2p/nicotine+

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-crypt/kali-archive-keyring
net-wireless/orinoco-fwutils
x11-terms/tilda

[gentoo-dev] Lastrites: media-plugins/npapi-vlc, sci-chemistry/platon, sys-fs/ocfs2-tools, net-nds/ypserv, net-nds/ypbind...

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Nobody bothered to bump it for ages, NPAPI is phased out (#468772).
# Removal in a month.
media-plugins/npapi-vlc

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Fails to fetch (#597424). Removal in a month.
sci-chemistry/platon

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Multiple build issues (#423471, #529772, #558206, #574910, #603304,
# #638602), problems with init.d scripts (#390231), major version bump
# #pending to be done (#610744). Removal in a month.
sys-fs/ocfs2-tools

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Fails to build, a major version bump is needed but it's hard to bump
# (#626050, #626052). Removal in a month.
net-nds/ypserv
net-nds/ypbind

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Unmaintained, no server still usable for this software (#626676). Removal
# in a month.
app-text/antixls

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Upstream is died, no server still usable for this (#626770). Removal in a
# month.
games-arcade/bloboats

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Upstream dead, not compatible with latest mariadb, nothing requires this
# in the tree (#628526, #629470, #629552, #629712, #629978, #630002,
# #630098, #630650). Removal in a month.
dev-db/lib_mysqludf_fPROJ4
dev-db/lib_mysqludf_preg
dev-db/lib_mysqludf_ta
dev-db/lib_mysqludf_stat
dev-db/lib_mysqludf_str
dev-db/lib_mysqludf_udf
dev-db/lib_mysqludf_sys
dev-db/lib_mysqludf_json

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Not properly mirrored, 14 years old and not really useful this days
# (#629328). Removal in a month.
x11-themes/lush

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Fails multilib-strict check (#628836). Nothing requires it. Removal in a
# month.
dev-libs/dclog

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Tries to install at pkg_postinst phase (#628804). Removal in a month.
app-misc/misterhouse

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Configure hangs (#628726), a major version bump is needed (#510050).
# Removal in a month.
app-forensics/autopsy

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Multiple security issues, init scripts need a major rework (#629416,
# #629412, #631068, #623806). Removal in a month.
net-im/jabberd2
net-im/mu-conference

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Not compatible with current libmowgli, no reverse deps (#630030). Removal
# in a month.
dev-libs/libmcs

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Upstream dead, QT4 consumer (#630550). Removal in a month.
x11-libs/qwtplot3d

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# No reverse deps, fails to build (#630866). Removal in a month.
dev-libs/libmowgli-glib

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Deprecated tools replace by dev-python/awscli (#633374). Removal in a
# month.
app-admin/aws-as-tools
app-admin/aws-cw-tools
app-admin/aws-iam-tools
app-admin/aws-rds-tools

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Relies on obsolete code.google, nothing uses it at present time (#633984).
# Removal in a month.
net-misc/slimrat

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Upstream dead, fails to fetch (#586504, #640546, #636466). Removal in a
# month.
games-emulation/xe

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Fails to build (#637612). Removal in a month.
net-vpn/htun

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Unmaintained, fails to build (#638628). Removal in a month.
media-sound/nted

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Fails to build (#638634). Removal in a month.
sys-apps/raidutils

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Tries to download and compile other tools, build fails then (#639060).
# Removal in a month.
dev-lang/fsharp

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Dead since 2007, fails to build (#639510). Removal in a month.
net-irc/ultimate

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Relies on dead gnome2 python bindings, seems dead since 2009 (#640028),
# removal in a month.
sys-power/phctool

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Upstream stopped its development as recent Gnome versions don't need it,
# it relies on gnome2 python bindings and many other dead libs (#640032).
# Removal in a month.
app-misc/specto

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Upstream dead, relies on gnome2 python bindings and other dead libs
# (#640070). Removal in a month.
x11-plugins/thinkhdaps

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Cannot be installed (#640414). Removal in a month.
net-misc/asterisk-rate_engine

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Dead for ages and replaced by app-admin/procinfo-ng (#641016). Removal in
# a month.
app-admin/procinfo

# Pacho Ramos <pa...@gentoo.org> (04 Jan 2018)
# Upstream dead, fails to b

Re: [gentoo-dev] [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.

[Pacho Ramos]

El mié, 03-01-2018 a las 17:13 +0100, Ulrich Müller escribió:
> Split off functions preserve_old_lib and preserve_old_lib_notify from
> eutils.eclass into a dedicated preserve-libs.eclass. These functions
> are rarely used and are independent of the rest of eutils, therefore
> moving them into their own eclass will help clarifying eclass
> inheritance in ebuilds.
> 
> For backwards compatibility, eutils inherits the new eclass in
> existing EAPIs.
> ---
>  eclass/eutils.eclass| 65 ++-
>  eclass/preserve-libs.eclass | 74
> +
>  2 files changed, 76 insertions(+), 63 deletions(-)
>  create mode 100644 eclass/preserve-libs.eclass
> 
> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> index 7d4193e76b51..91d329e99c9e 100644
> --- a/eclass/eutils.eclass
> +++ b/eclass/eutils.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2017 Gentoo Foundation
> +# Copyright 1999-2018 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: eutils.eclass
> @@ -20,7 +20,7 @@ _EUTILS_ECLASS=1
>  # implicitly inherited (now split) eclasses
>  case ${EAPI:-0} in
>  0|1|2|3|4|5|6)
> - inherit desktop epatch estack ltprune multilib toolchain-funcs
> + inherit desktop epatch estack ltprune multilib preserve-libs
> toolchain-funcs
>   ;;
>  esac
>  
> @@ -172,67 +172,6 @@ _eutils_eprefix_init() {
>   has "${EAPI:-0}" 0 1 2 && : ${ED:=${D}} ${EPREFIX:=}
> ${EROOT:=${ROOT}}
>  }
>  
> -# @FUNCTION: preserve_old_lib
> -# @USAGE:  [more libs]
> -# @DESCRIPTION:
> -# These functions are useful when a lib in your package changes ABI SONAME.
> -# An example might be from libogg.so.0 to libogg.so.1.  Removing libogg.so.0
> -# would break packages that link against it.  Most people get around this
> -# by using the portage SLOT mechanism, but that is not always a relevant
> -# solution, so instead you can call this from pkg_preinst.  See also the
> -# preserve_old_lib_notify function.
> -preserve_old_lib() {
> - _eutils_eprefix_init
> - if [[ ${EBUILD_PHASE} != "preinst" ]] ; then
> - eerror "preserve_old_lib() must be called from pkg_preinst()
> only"
> - die "Invalid preserve_old_lib() usage"
> - fi
> - [[ -z $1 ]] && die "Usage: preserve_old_lib 
> [more libraries to preserve]"
> -
> - # let portage worry about it
> - has preserve-libs ${FEATURES} && return 0
> -
> - local lib dir
> - for lib in "$@" ; do
> - [[ -e ${EROOT}/${lib} ]] || continue
> - dir=${lib%/*}
> - dodir ${dir} || die "dodir ${dir} failed"
> - cp "${EROOT}"/${lib} "${ED}"/${lib} || die "cp ${lib} failed"
> - touch "${ED}"/${lib}
> - done
> -}
> -
> -# @FUNCTION: preserve_old_lib_notify
> -# @USAGE:  [more libs]
> -# @DESCRIPTION:
> -# Spit helpful messages about the libraries preserved by preserve_old_lib.
> -preserve_old_lib_notify() {
> - if [[ ${EBUILD_PHASE} != "postinst" ]] ; then
> - eerror "preserve_old_lib_notify() must be called from
> pkg_postinst() only"
> - die "Invalid preserve_old_lib_notify() usage"
> - fi
> -
> - # let portage worry about it
> - has preserve-libs ${FEATURES} && return 0
> -
> - _eutils_eprefix_init
> -
> - local lib notice=0
> - for lib in "$@" ; do
> - [[ -e ${EROOT}/${lib} ]] || continue
> - if [[ ${notice} -eq 0 ]] ; then
> - notice=1
> - ewarn "Old versions of installed libraries were
> detected on your system."
> - ewarn "In order to avoid breaking packages that
> depend on these old libs,"
> - ewarn "the libraries are not being removed.  You need
> to run revdep-rebuild"
> - ewarn "in order to remove these old dependencies.  If
> you do not have this"
> - ewarn "helper program, simply emerge the 'gentoolkit'
> package."
> - ewarn
> - fi
> - ewarn "  # revdep-rebuild --library '${lib}' && rm '${lib}'"
> - done
> -}
> -
>  # @FUNCTION: built_with_use
>  # @USAGE: [--hidden] [--missing ] [-a|-o]   flags>
>  # @DESCRIPTION:
> diff --git a/eclass/preserve-libs.eclass b/eclass/preserve-libs.eclass
> new file mode 100644
> index ..548c6411fcf0
> --- /dev/null
> +++ b/eclass/preserve-libs.eclass
> @@ -0,0 +1,74 @@
> +# Copyright 1999-2018 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: preserve-libs.eclass
> +# @MAINTAINER:
> +# base-sys...@gentoo.org
> +# @BLURB: preserve libraries after SONAME changes
> +
> +if [[ -z ${_PRESERVE_LIBS_ECLASS} ]]; then
> +_PRESERVE_LIBS_ECLASS=1
> +
> +# @FUNCTION: preserve_old_lib
> +# @USAGE:  [more libs]
> +# @DESCRIPTION:
> +# These functions are useful when a lib in your package changes ABI SONAME.
> +# An example might 

Re: [gentoo-dev] [PATCH] skel.ebuild: Update comments for inherit, SLOT, KEYWORDS.

[Pacho Ramos]

El dom, 31-12-2017 a las 12:12 -0600, William Hubbs escribió:
> On Sun, Dec 31, 2017 at 06:44:39PM +0100, Michał Górny wrote:
> > W dniu nie, 31.12.2017 o godzinie 14∶31 +0100, użytkownik Ulrich Müller
> > napisał:
> > > epatch() is provided by epatch.eclass now. Also comment the inherit
> > > line, since not every ebuild will use it.
> > > 
> > > Empty SLOT doesn't disable slots, but is outright illegal in all EAPIs.
> > > Similar for KEYWORDS="*", which isn't "deprecated" but invalid.
> > > ---
> > >  skel.ebuild | 9 -
> > >  1 file changed, 4 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/skel.ebuild b/skel.ebuild
> > > index 7ac9dfb7d6d8..4c19b1de4cb8 100644
> > > --- a/skel.ebuild
> > > +++ b/skel.ebuild
> > > @@ -13,9 +13,9 @@
> > >  EAPI=6
> > >  
> > >  # inherit lists eclasses to inherit functions from. For example, an
> > > ebuild
> > > -# that needs the epatch function from eutils.eclass won't work without
> > > the
> > > +# that needs the epatch function from epatch.eclass won't work without
> > > the
> > >  # following line:
> > > -inherit eutils
> > > +#inherit epatch
> > 
> > Well, given that it's EAPI 6 and we do not want to encourage people to
> > use epatch there, I would prefer if we replaced that example with
> > something else. But it's just a wishful thinking here.
> 
> +1, but I'm not going to suggest what to replace it with.
> 
> William

Why not eapply (and drop inherit then)? :/

[gentoo-dev] Lastrites: media-libs/libdvb, sys-cluster/drbd, dev-lang/blassic, app-text/nfoview, dev-python/ssh, media-gfx/aqsis...

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Dead since 2005, nothing requires it, installs object files in
# /usr/share/doc (#451792). Removal in a month.
media-libs/libdvb

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# This was replaced by sys-cluster/drbd-utils (#590872), reverse deps were
# already migrated to it, doesn't build with latest glibc (#616510). Removal
# in a month.
sys-cluster/drbd

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Fails to build (#595706), nothing requires it. Removal in a month.
dev-lang/blassic

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Fails at runtime (#614314). Removal in a month.
app-text/nfoview

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Needs to be migrated to pycryptodome, this was merged into paramiko
# (#611616). Removal in a month.
dev-python/ssh
dev-python/starcluster

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Fails with recent boost (#617060, #598702). Removal in a month.
media-gfx/aqsis

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# A major version bump is needed (#412447), fails with multilib-strict
# (#613542), not compatible with newer imagemagick (#619514), cannot be
# downloaded (#635566). Removal in a month.
media-libs/vips
media-gfx/nip2

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Multiple build failures and bugs (#634316), fails with recent lua
# (#434242), init script is buggy (#496724), bash completion files installed
# wrongly (#526280), fails with newer botan (#537572). Removal in a month.
dev-vcs/monotone

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Fails to build (#622110), upstream dead for years. Removal in a month.
app-misc/tasque

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Needs a major version bump and relies on lots of dead libs (#624160).
# Removal in a month.
x11-terms/terminator

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Requires dead gnome2 python bindings (#629180) and old gstreamer, also all
# zeitgeist stack has important bugs and upstream is gone (#629180#c2):
# zeitgeist-explorer doesn't start (#622084), activity-log-manager fails to
# build (#625140), 
gnome-extra/gnome-activity-journal
gnome-extra/zeitgeist-explorer
gnome-extra/activity-log-manager
gnome-extra/zeitgeist

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Dead for ages, relies on old gnome2 python bindings (#640036). Removal in
# a month.
gnome-extra/cameramonitor

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Upstream gone, relies on old gnome2 python bindings (#640042). Removal in
# a month.
media-gfx/gnome-specimen

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Upstream dead for ages, relies on old gnome2 python bindings (#640050).
# Removal in a month.
net-misc/polly

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Upstream gone, relies on old gnome2 python bindings (#640052). Removal in
# a month.
sys-apps/pyrenamer

# Pacho Ramos <pa...@gentoo.org> (28 Dec 2017)
# Upstream dead since 2006, relies on old gnome2 python bindings and many
# other dead libs (#640068). Removal in a month.
media-sound/ifp-gnome

[gentoo-dev] Lastrites: compiz and related packages

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Remove all Compiz related packages: they all need major work/bumps to fix
# lots of pending issues and they need a dedicated maintainer (bug #339622
# and many others). Removal in a month.
x11-wm/compiz
x11-apps/fusion-icon
x11-libs/compizconfig-backend-gconf
x11-libs/libcompizconfig
dev-python/compizconfig-python
x11-misc/ccsm
x11-misc/simple-ccsm
x11-plugins/compiz-plugins-extra
x11-plugins/compiz-plugins-main
x11-plugins/compiz-plugins-unsupported
x11-wm/compiz-fusion
x11-wm/emerald
x11-themes/emerald-themes
x11-libs/compiz-bcop

[gentoo-dev] Lastrites: dev-java/jikes, net-misc/netkit-rusers, net-print/xerox-drivers, dev-dotnet/gnome-sharp...

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Dead for ages, not needed, for java 1.5 (#638036). Removal in a month.
dev-java/jikes

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Dead for ages, requires glibc with rpc (#371391). Removal in a month.
net-misc/netkit-rusers

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Out ebuild is completely obsolete (#381073), download manually PPD is
# preferred, current tarballs cannot be downloaded even (#635146). Removal
# in a month.
net-print/xerox-drivers

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Dead and broken for a long time (#427876), nothing requires this. Removal
# in a month.
dev-dotnet/gnome-sharp

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Dead and broken for a long time (#428354, #562772, #624956, #558120,
# #585222, #585548, #605706, #612368), nothing requires this. Removal
# in a month.
# Mikhail Pukhlikov <cyn...@gentoo.org> (20 Jul 2017)
# Old mono/dotnet packages (used on GNOME2 stack)
# also some deprecated forks used for monodevelop
# awhile they are very unstable they will live in dotnet overlay
gnome-extra/docky
dev-dotnet/gnome-desktop-sharp
dev-dotnet/gtksourceview-sharp
dev-dotnet/rsvg-sharp
dev-dotnet/vte-sharp
dev-dotnet/wnck-sharp
dev-dotnet/xdt-for-monodevelop
dev-dotnet/nuget
dev-dotnet/referenceassemblies-pcl

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Dead for ages, rely on deprecated/dead libs (#447466). Removal in a month.
dev-vcs/bzr-gtk
dev-vcs/bzr-explorer

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Completely broken for years (#514400, #596078, #598609, #640096, #641428).
# Removal in a month.
dev-cpp/pficommon

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Dead for a long time, failing tests (#526900), nothing requires it.
# Removal in a month.
net-misc/ytalk

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Upstream dead, SRC_URI dead, nothing requires it (#533812). Removal in a
# month.
media-video/replex

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Not compatible with mono-4 (#557588, #562546, #569252, #581920, #585860,
#596652),
# nothing requires them. Removal in a month.
dev-dotnet/xsp
dev-dotnet/nini
dev-lang/mono-basic
dev-util/jay

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# python files installed in wrong path (#580328), relies on qt4 and cannot
# be bumped (#585328), fails with gcc6 (#630332), fails to build (#641514).
# Removal in a month.
sci-visualization/qtiplot

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Dead upstream for a long time, relies on dead gnome-icon-theme and has
# some crashes (#602144). Removal in a month.
app-doc/podbrowser

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# Dead upstream for a long time, relies on dead gnome-icon-theme and nothing
# requires it (#602146). Removal in a month.
games-emulation/gxmame

# Pacho Ramos <pa...@gentoo.org> (27 Dec 2017)
# All Ekiga set is dead and broken for years, it relies on obsolete
# dead/libs that are also old and broken and upstream looks to not release
# newer ekiga ever. To keep this please go ahead and take care of it *and
# all the dependencies it also needs*. See bugs #626176, #460458, #589276,
# #638122, #641990, #633670, #624578, #600398, #627868.
# Removal in a month.
net-libs/ptlib
net-libs/opal
net-voip/openmcu
net-voip/ekiga

Re: [gentoo-dev] RFC: news item for the 17.0 profiles

[Pacho Ramos]

El mar, 10-10-2017 a las 00:23 +0200, Toralf Förster escribió:
> On 10/09/2017 11:40 PM, Pacho Ramos wrote:
> > Could anyone with enough knowledge finally give a look to the patched vapier
> 
> s/patched/patches/
> 
> or ? :-)
> 

Yes :)

Re: [gentoo-dev] RFC: news item for the 17.0 profiles

[Pacho Ramos]

El lun, 09-10-2017 a las 22:58 +0200, Andreas K. Huettel escribió:
> =
> Title: New 17.0 profiles in the Gentoo repository
> Author: Andreas K. Hüttel 
> Posted: xxx
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: >=sys-devel/gcc-6.4.0
> 
> We have just added a new set of profiles with release version 17.0
> to the Gentoo repository. These bring two changes:
> 1) The default C++ language version for applications is now C++14.
>This change is mostly relevant to Gentoo developers. It also
>means, however, that compilers earlier than GCC 6 are masked 
>and not supported for use as a system compiler anymore. Feel 
>free to unmask them if you need them for specific applications.
> 2) Where supported, GCC will now build position-independent
>executables (PIE) by default. This improves the overall
>security fingerprint. The switch from non-PIE to PIE binaries,
>however, requires some steps by users, as detailed below.
> 
> Please consider switching from your current 13.0 profile to the
> corresponding 17.0 profile soon after GCC-6.4.0 has been 
> stabilized on your architecture. The 13.0 profiles will be deprecated 
> and removed in the near future.
> 
> Switching involves the following steps: 
> If not already done,
> * Use gcc-config to select gcc-6.4.0 or later as system compiler
> * Re-source /etc/profile:
> . /etc/profile
> * Re-emerge libtool

Could anyone with enough knowledge finally give a look to the patched vapier
provided in https://bugs.gentoo.org/88596 but never got committed?

Thanks!

Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

[Pacho Ramos]

El mié, 26-07-2017 a las 13:46 +, Lucas Ramage escribió:
> I am not yet an official developer but I am interested in assisting in
> maintaining this.
> 

Then, please take a look on:
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers

In summary, you will need to open a bug asking proxy-maint to set you as
maintainer and, for fixing bugs, usually sending github PR is the preferred
method

Thanks

[gentoo-dev] Lastrites: dev-lang/gnat-gcc, x11-apps/spotlighter, dev-scheme/stalin...

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# Severely broken with lots of unresolved bugs, outdated, needs a dedicated
# maintainer (#402157). Removal in a month.
dev-lang/gnat-gcc
virtual/gnat

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# Upstream dead, cannot be bumped, buggy (#468128). Removal in a month.
x11-apps/spotlighter

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# Fails to build (#542108), relies on dead DirectFB. Removal in a month.
dev-libs/DFB++

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# Upstream dead, vulnerable (#569980), removal in a month.
dev-scheme/stalin

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# Orphan, severely outdated and vulnerable to security issues (#585940).
# Removal in a month.
sys-apps/pacman

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# One of the last consumers of old udisks:0, upstream dead for ages
# (#601358). Removal in a month.
x11-misc/tinymount

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# EOL, severely broken, impossible to bump (#624966). Removal in a month.
sci-geosciences/googleearth

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# Dead for ages, not usable at present time (#625596). Removal in a month.
app-mobilephone/linuxsms

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# Upstream dead, last consumer of obsolete cegui version (#625604). Removal
# in a month.
games-arcade/smc

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# Dead for a long time, relies on also dead DirectFB lib (#625608). Removal
# in a month.
media-gfx/DFBPoint

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# Upstream dead, relies on also dead DirectFB lib (#625610). Removal in a
# month.
media-video/dfbsee

# Pacho Ramos <pa...@gentoo.org> (26 Jul 2017)
# Upstream dead, relies on also dead DirectFB lib (#625612). Removal in a
# month.
net-misc/directvnc

[gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

[Pacho Ramos]

sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions where having
important bugs that were fixed in 0.9.x, but 0.9 is also plenty of issues. Then,
either this is adopted by someone able to handle all that issues or we will need
to finally treeclean (and drop its support for dependant packages)

Thanks

[gentoo-dev] sys-kernel/openvz-sources needs a dedicated maintainer

[Pacho Ramos]

Currently is maintained needed, and going ahead and bumping it when we notice
how outdated and vulnerable to security issues is not enough. This needs a
dedicated maintainer taking care of bumping when needed. Hence, feel free to get
it if you want to still keep it alive.

Thanks

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 23:10 +1000, Michael Palimaka escribió:
> On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote:
> > First, the assumption in our processes seems to be that many or
> > important bugs will be due to architecture-specific differences, and I
> > wonder if that assumption really holds up. Do arch testers for a smaller
> > arch often find problems that were not noticed on one of the larger
> > arches? With the languages and tools that we have today, it seems like
> > for many of our packages, bugs due to architectural differences
> > represent a minority of the problems we found. In this case, the whole
> > idea of per-arch stabilization does not really make sense, and doing
> > away with that idea could drastically shortcut our process.
> 
> This would be really interesting to know.

Anyway, I think it depends on the arch you are running. I remember to have seen
specific issues for ia64, hppa, ppc64 or arm. But, for example, I agree that,
*at present time*, I don't remember to have seen a package failing on x86 and
not on amd64 for example (well, I now remember a past systemd upstream runtime
bug that was catched in testing period ;)). 

Then, I guess it depends on each arch. For example, for x86 it could be probably
done if things work on amd64 :/. Between ppc and ppc64 I don't know. For the
others, I don't think that we can extrapolate between amd64 and ia64 for example
(I remember important runtime issues to be catched only affecting ia64 for
example).

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 22:59 +1000, Michael Palimaka escribió:
> On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> > 2. Q: How to make arch testing faster and easier?
> > 
> >    A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> > required" will be automatically tested and keyworded.
> > 
> > [handwave] automated tinderbox setup would help a lot
> > to now upfront what fails to built, fails tests.
> 
> I've had similar thoughts about this and have already been working on
> some tooling for this.
> 
> We would need to establish exactly what criteria must be met for an
> automated test to be considered as successful.
> 
> Here's a sample report that my tool produces:
> https://dev.gentoo.org/~kensington/tinderbox/sys-apps/dbus/dbus-1.6.18-r1/df01
> 7e14-bd68-47e2-9738-554e7ba1cf10.html
> 
> In this case, would it be enough that it builds and tests pass? What
> about the QA issues?

Personally, I don't feel QA issues as major enough to block a stabilization,
usually they won't cause major issues for stable users and, if they do, for sure
they shouldn't be only QA issues :/

>  Do we need someone to review them to determine if
> they should block stabilisation, or if they're even a regression or not?
> 

Regarding general regressions, that is probably the harder point to handle
automatically. In the past, the scripts in arch-tools.git were avoiding to open
automated stable bug reports for packages having opened bugs (excluding
enhancement and QA bug reports), but that approach is not too good as, for
example, having a bug report asking for a version bump but tagged as "normal"
and not "enhancement" will lead to the bug not being opened :S

Then, I am unsure about if that part can be done automatically :/

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 15:19 +0200, Michał Górny escribió:
> On wto, 2017-07-25 at 14:15 +0200, Pacho Ramos wrote:
> > El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> > > Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos <pa...@gentoo.org>
> > > napisał(a):
> > > > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> > > > > On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
> > > > > > 
> > > > > > I hold a perhaps radical view: I would like to simply remove
> > > > 
> > > > stable.
> > > > > > 
> > > > > > [snip]
> > > > > > 
> > > > > > I consider dev time a precious resource.
> > > > > 
> > > > > If we were to drop stable I would have to start maintaining my own
> > > > > stable lists to determine what would be ready to into production for
> > > > 
> > > > my
> > > > > company. In production "works most of the time" and "good enough"
> > > > > simply aren't good enough.
> > > > > 
> > > > > I estimate that would at least equal the amount of time I'm currently
> > > > > spending on Gentoo work, and consequently my contributions to Gentoo
> > > > > would dwindle to a halt. Most likely I would start looking at other
> > > > > solutions altogether.
> > > > > 
> > > > > > More troubleshooting and fixing "hard" problems, less routine work.
> > > > > 
> > > > > Except that some of that routine work is actually what I enjoy doing
> > > > 
> > > > in
> > > > > Gentoo. I already get plenty of the other two in my day job.
> > > > > 
> > > > > Hans
> > > > 
> > > > If stable goes away I will simply switch to other distribution and
> > > > retire
> > > 
> > > What's the "over my dead commit access" spirit? 
> > > 
> > 
> > Jumping from trying to maintain stable tree to arches dead for ages to drop
> > all
> > stable trees looks to me like a joke promoted by people that has never
> > handled
> > any stabilization request and saw on them how running a pure "testing"
> > system is
> > impossible on many conditions. It seems that some people think that if it
> > fits
> > ok for them, it will fit for all others like we were all using Gentoo for
> > doing
> > the same.
> > 
> 
> I'm sorry, that was supposed to be 'where', not 'what' (stupid
> autocompletion!). I simply meant to say that you should have said 'over
> my dead commit access' there ;-).
> 
> 

Ah, no problem. I am also sorry for my quick response to the thread but,
seriously, when I read the suggestion I was like =O

Best regards!

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos <pa...@gentoo.org> napisał(a):
> > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> > > On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
> > > > 
> > > > I hold a perhaps radical view: I would like to simply remove
> > 
> > stable.
> > > > 
> > > > [snip]
> > > > 
> > > > I consider dev time a precious resource.
> > > 
> > > If we were to drop stable I would have to start maintaining my own
> > > stable lists to determine what would be ready to into production for
> > 
> > my
> > > company. In production "works most of the time" and "good enough"
> > > simply aren't good enough.
> > > 
> > > I estimate that would at least equal the amount of time I'm currently
> > > spending on Gentoo work, and consequently my contributions to Gentoo
> > > would dwindle to a halt. Most likely I would start looking at other
> > > solutions altogether.
> > > 
> > > > More troubleshooting and fixing "hard" problems, less routine work.
> > > 
> > > Except that some of that routine work is actually what I enjoy doing
> > 
> > in
> > > Gentoo. I already get plenty of the other two in my day job.
> > > 
> > > Hans
> > 
> > If stable goes away I will simply switch to other distribution and
> > retire
> 
> What's the "over my dead commit access" spirit? 
> 

Jumping from trying to maintain stable tree to arches dead for ages to drop all
stable trees looks to me like a joke promoted by people that has never handled
any stabilization request and saw on them how running a pure "testing" system is
impossible on many conditions. It seems that some people think that if it fits
ok for them, it will fit for all others like we were all using Gentoo for doing
the same.

I could of course deal with things in my personal computer like, for example,
needing to run gcc-6 (current testing) and having tons of packages failing to
build, or run python-3.6 with only a few subset of packages, or running latest
ffmpeg with random packages going to fail with it, or many other issues that
anyone doing some stabilization work would have noticed. But, of course, I
cannot pretend that all the people using Gentoo systems for working or doing
something productive and that for now rely on me for maintaining or helping them
with the issues that could arise, will now be also forced to run systems that
are likely going to break in different and new ways every time they pretend to
update.

I am also really surprised to see how we can jump from some people that were
fighting in the past against we running automatic scripts that already existed
to fill stabilization bug reports and CC arches after timeouts, to a new
situation of "oh, testing tree is good enough for all the people". We will jump
for some people asking for things like doing deeper tests runs for packages
going to stable (at a level that was really unfeasible on a large scale) to a
situation in that nothing (even no compile test) will be checked at all.

Additionally, this will also cause new issues between people that were used to
run "testing" in the way they are running it now and they pushing to unmask
things faster and, others used to "stable", pushing to keep more things hard
masked until they are fixed. It's not the first time that we see that, for
example, a new glibc version is unmasked when maintainer feels it's ready to
allow people to catch the bugs before it going to be stable. If we have no
stable tree, that couldn't be done as we couldn't use "testing" for the purpose
of "lets unmask X package it give it more visibility and let people catch the
bugs". Then, either we keep breaking "testing" even knowing there is no stable,
or we will start getting lots of packages in package.mask leading to new issues
(like those packages having less visibility and fights between people thinking
that a mid breakage is ok and others that not).

Then, in my case it will be as simply as, if Gentoo becomes testing only, I
won't be able to use it for anything productive, only for "playing" with it...
and then, I won't see much sense on staying while I will need to use a different
distribution de facto for the work and any computer that is not the laptop I use
for committing and doing Gentoo dev work.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
> > 
> > I hold a perhaps radical view: I would like to simply remove stable.
> > 
> > [snip]
> > 
> > I consider dev time a precious resource.
> 
> If we were to drop stable I would have to start maintaining my own
> stable lists to determine what would be ready to into production for my
> company. In production "works most of the time" and "good enough"
> simply aren't good enough.
> 
> I estimate that would at least equal the amount of time I'm currently
> spending on Gentoo work, and consequently my contributions to Gentoo
> would dwindle to a halt. Most likely I would start looking at other
> solutions altogether.
> 
> > More troubleshooting and fixing "hard" problems, less routine work.
> 
> Except that some of that routine work is actually what I enjoy doing in
> Gentoo. I already get plenty of the other two in my day job.
> 
> Hans

If stable goes away I will simply switch to other distribution and retire

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El lun, 24-07-2017 a las 22:22 +0100, Sergei Trofimovich escribió:
> 4. Q: How to push more packages into STABLE?
> 
>    A: File automatic STABLEREQ bugs more aggressively if no known bugs
>   exist for a package version. The rough workflow is the following:
> 
>   - Grab a list of candidates for stabilization (will need
>     additional tooling)
>   - File STABLEREQ against maintainer only first.
>   - Maintainer will have a 2-week timeout to either proceed with
>     request:
>     - add "runtime testing required fields", CC relevant arches to
>   start stabilization
>     - or set blocking bugs against STABLEREQ to stop stabilization
>   - After 2-week timeout tooling automatically CCes arches and
>     stabilization happens (ideally with minimal manual work)
>   - Profit!

I think the tools for this were already developed... but they were relying on
some of us remembering to run them from time to time :/
https://gitweb.gentoo.org/proj/arch-tools.git/tree/file-stabilization-bugs.py
https://gitweb.gentoo.org/proj/arch-tools.git/tree/maintainer-timeout.py
https://gitweb.gentoo.org/proj/arch-tools.git/tree/stabilization-candidates.py

Thanks specially for sharing https://wiki.gentoo.org/wiki/Package_testing#Tools
link, it summarizes all the process really well :O

Also, it seems that tatt- is able to do most of the work... then only thing
that maybe has no official script to get it, for example, what would be the best
way of getting the list of bug numbers that are pending to handle?

For example, if I go to the list manually and pick 10 random bugs, it's ok to
run tatt and copy every bug number but, if the arch queue has 300 pending
bugs. Do we have a way to simply get a plain text with all the bug numbers from
bugzilla interface? Having links per arch pointing to that list of bugs with
arches CCed and sanity-check=+ would be probably helpful ;)

Thanks

[gentoo-dev] Lastrites: app-mobilephone/esms, sci-chemistry/icm, dev-python/south...

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Not usable, dead since 2003, removal in a month (#24706)
app-mobilephone/esms

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Proprietary software, fetch restricted, not actively maintained, needs to
# be updated, with multiple QA issues, bug #622414. Removal in a month.
sci-chemistry/icm
# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Doesn't work with >=openvpn-2.3, removal in a month (#470696).
net-vpn/kvpnc

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Doesn't work with any django version in the tree, tests fail, removal in a
# month (#482498).
dev-python/south

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# No reverse deps, doesn't build, bug #569068. Removal in a month.
net-misc/jumpgate

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Lots of unresolved bugs, not compatible with QT 5.7 either, bug #574672.
# Removal in a month.
net-p2p/bitcoinxtd
net-p2p/bitcoinxt-qt

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Our package is completely outdated and needs a major version bump (and
# pkgmove). Bug #541410. Removal in a month.
dev-util/febootstrap

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Buggy, doesn't compile for a long time, bug #575772. Removal in a month.
dev-python/python-sipsimple
net-voip/blink

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Doesn't compile, one of the last consumers of obsolete gnet library
# (#579400). Removal in a month.
net-irc/loqui

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Doesn't compile (#579948). Removal in a month.
net-nntp/leafnode

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Doesn't compile, upstream dead, removal in a month (#584296).
dev-util/mutrace

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# QA issues, upstreams dead, multiple alternatives, bug #587284 and bug
# #587288. Removal in a month.
sys-libs/libacpi
sys-power/yacpi

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# games-engines/renpy cannot be used with its only reverse dep in the tree
# as-is, it needs a major version bump and build fixing too, bug #587872.
# Removal in a month.
games-engines/renpy

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Doesn't build for a long time, bug #587942
sci-mathematics/cado-nfs

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Doesn't build (#592992), dead since 2011 and nothing needs it in the tree.
# Removal in a month.
dev-libs/mozldap

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Not compatible with gcc6 (#594390), also removed from other distributions
# due it being unmaintained and buggy. Removal in a month.
net-analyzer/nepenthes

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Upstream inactive, not buildable with gcc6, not needed by anything in the
# tree (#594668). Removal in a month.
app-text/mbtpdfasm

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# No reverse deps, not buildable with gcc6 (#595396). Removal in a month.
media-libs/embree

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Not compatible with QT 5.7, bug #595452. Removal in a month.
net-p2p/litecoin-qt

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Not buildable (#596602), no reverse deps, removal in a month.
app-pda/fusepod

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Not buildable for a long time (#597040). Removal in a month.
dev-util/lorax

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Security issues (#600524), upstream dead, removal in a month.
dev-db/recutils

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Multiple unresolved bugs (#600680), need major version bumps and a
# maintainer, removal in a month.
dev-libs/libRocket
games-fps/warsow

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Fails to build, no reverse deps (#600768). Removal in a month.
app-editors/mp

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Needs obsolete splitted dev-dotnet/gnome-sharp (#600960). Removal in a
# month.
media-video/gnome-subtitles

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Development stopped 4 years ago, relies on dead vte:2.90 and upstream
# refused to even try to migrate it (#601350). Also security issues
# (#611290). Removal in a month.
x11-terms/evilvte

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Not compatible with gcc6, nothing needs this in the tree (#603900).
# Removal in a month.
dev-libs/qcodeedit

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Not compatible with gperf-3.1 (#604816). Removal in a month.
app-misc/flasm

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Upstream is dead, lots of unresolved bug reports (#606154), it needs a
# real maintainer taking care about fixing this. Removal in a month.
sys-apps/v86d

# Pacho Ramos <pa...@gentoo.org> (14 Jul 2017)
# Doesn't build anymore (#607482). Removal in a month.
net-irc/irssi-xmpp

# Pacho Ramos <pa...@gentoo.org

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Pacho Ramos]

El mié, 12-07-2017 a las 12:38 -0400, William L. Thomson Jr. escribió:
> On Wed, 12 Jul 2017 17:23:43 +0100
> "M. J. Everitt"  wrote:
> 
> > On 12/07/17 17:07, Gordon Pettey wrote:
> > > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> > > > wrote:
> > > That is my point. That message is always there. The chance that
> > > it is ignored is very high.
> > > 
> > > 
> > > Stop signs on the road are also always there. If you get arrested
> > > for ignoring it, it is not because the stop signs are always there,
> > > it is because you ignored it. Don't ignore the warning.  
> > 
> > Can't help but think of "special snowflake" here 
> 
> More like saying something to me because it is me, despite that I
> literally pointed that out to others. In a situation that actually
> matters. This should be said to others not me. But everyone feels ilke
> they need to comment something to me, that applies to another, but not
> said to that other.
> 
> Again
> https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b2
> 4
> 
> Really funny stuff
> 
> --

After re-reading all the thread again:
https://lists.gt.net/gentoo/dev/327773/?page=1;mh=-1;

I think there is no point in continuing replying forever to this thread as I
think all the technical issues has now being, at least, clarified and forwarded
to the right people. As I have understood most of them belong to Portage team
and now that the bug reports with the concrete suggestions were filled, they
will be able to deal with them (either working on implementing the desired
changes or either declining to do that if they have other opinions based on the
way portage is supposed to be used by us). 

Then, can we please switch to different and more productive things to do? :)

Thanks a lot!

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Pacho Ramos]

El mié, 12-07-2017 a las 09:13 -0500, William Hubbs escribió:
> On Wed, Jul 12, 2017 at 02:30:34PM +0200, Kristian Fiskerstrand wrote:
> > On 07/12/2017 01:59 PM, Michael Palimaka wrote:
> > > If it's not a stable candidate then why do you use this as an example
> > > against build testing-based stabilisations? If there are known issues it
> > > should never reach the arch teams in the first place.
> > 
> > This might be the crux of things, as long as automatic stabilization is
> > not triggered by some set of rules (e.g 30 days in ~arch) , and still
> > requires manual trigger by, preferably, the maintainer there is likely
> > no issue.
> 
> This doesn't make sense. If I have to trigger automatic stabilization, it
> isn't automatic any more.
> 
> I think with an appropriate set of rules automatic stabilization would
> be fine. For example:
> 
> - foo-2.0 has been in ~arch for 30 days
> - there are no open bugs against foo-2.0
> - an older version of foo is stable
> - all of the dependencies of foo-2.0 are stable
> 
> If those conditions are met, in theory there shouldn't be any problem
> with stabilizing foo-2.0.
> 
> If foo-2.0 is not a stabilization candidate, there probably should be an
> open bug in bugzilla stating why it isn't.
> 
> Thanks,
> 
> William
> 

Also please note that, when we were filling that automatic bug reports, there
were still an additional 60 days timeout (I think it was 60 days.. but I don't
remember if even 90 days) to allow maintainers to react. Only if nothing was
noted in relevant bug reports, arches were CCed automatically by the script 

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Pacho Ramos]

El lun, 10-07-2017 a las 11:55 -0500, William Hubbs escribió:
> On Mon, Jul 10, 2017 at 01:04:10PM +0200, Pacho Ramos wrote:
> > Hello
> > 
> > Looking to the list of packages still not supporting python 3.5:
> > https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
> > 
> > and considering that we should even start testing python 3.6, I think it
> > would
> > be nice if we could make portage to warn when PYTHON_COMPAT value is not
> > updated. It's really frustrating to still see new ebuilds being added with
> > obsolete values for PYTHON_COMPAT and relying on a few people looking to
> > update
> > this. This is also causing huge delays to migrate to newer python versions
> > and I
> > think it's responsibility of the maintainer to ensure his/her package is
> > supported on newer versions or, at least, have a bug and ping upstream for
> > the
> > cases they need further fixing.
> > 
> > Of course, this wouldn't be a fatal check preventing you from committing a
> > package with outdated PYTHON_COMPAT, it would be a warning to remind you to
> > update it as soon as possible.
> > 
> > Any issues on trying to go further into implementing this warning? 
> 
> What about the situation where a package is not compatible with newer
> versions of python so does not need a PYTHON_COMPAT change?
> 
> I don't think you can assume PYTHON_COMPAT is outdated for a package
> just because it doesn't have the latest versions of python
> listed. The only time you can know for sure that it is outdated is if it
> lists a version of python that no longer exists in the tree.
> 
> William
> 

Maybe we could handle it like other warnings: ignore it but ensure we have a bug
report to track the issue (I have seen cases of a comment being added showing
that a package wasn't ready for python 3.5 but no bug reference listed :/). 

It looks to me like the same we do for parallel build warnings

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Pacho Ramos]

El lun, 10-07-2017 a las 13:12 +0200, Kristian Fiskerstrand escribió:
> On 07/10/2017 01:04 PM, Pacho Ramos wrote:
> > Any issues on trying to go further into implementing this warning? 
> 
> Not an issue per se, but it should be pointed out that python 3.5 only
> has a testing visibility, so this at the very least requires maintainers
> to potentially have a separate testing chroot/VM to test when adding the
> compat.
> 

Yes, but it's similar as the cases when we need to fix our packages to work with
a newer library they depend on. In this case it would be even easier as we can
have multiple python versions and switch to the newer one for testing while
going back to the stable one (if preferred) later.

[gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Pacho Ramos]

Hello

Looking to the list of packages still not supporting python 3.5:
https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt

and considering that we should even start testing python 3.6, I think it would
be nice if we could make portage to warn when PYTHON_COMPAT value is not
updated. It's really frustrating to still see new ebuilds being added with
obsolete values for PYTHON_COMPAT and relying on a few people looking to update
this. This is also causing huge delays to migrate to newer python versions and I
think it's responsibility of the maintainer to ensure his/her package is
supported on newer versions or, at least, have a bug and ping upstream for the
cases they need further fixing.

Of course, this wouldn't be a fatal check preventing you from committing a
package with outdated PYTHON_COMPAT, it would be a warning to remind you to
update it as soon as possible.

Any issues on trying to go further into implementing this warning? 

Thanks a lot

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
dev-ml/fort
media-libs/embree
x11-wm/i3

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
dev-lua/messagepack
dev-python/doit
net-news/rssguard
eclass/l10n.eclass

[gentoo-dev] Lastrites: 4 packages incompatible with ffmpeg-3

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (17 Jun 2017)
# Not compatible with ffmpeg-3 (#602786), other bug reports and NPAPI
# plugins support in main browsers is dying. Removal in a month.
www-plugins/gnash

# Pacho Ramos <pa...@gentoo.org> (17 Jun 2017)
# Not compatible with ffmpeg-3 (#591946), neither builds without ffmpeg
# support (#607492) and NPAPI plugins are dying. Removal in a month.
www-plugins/lightspark

# Pacho Ramos <pa...@gentoo.org> (17 Jun 2017)
# Not compatible with ffmpeg-3 (#589806) and needs vulnerable qtwebkit:4
# (#620740). Removal in a month.
net-voip/homer

# Pacho Ramos <pa...@gentoo.org> (17 Jun 2017)
# Dead for ages, relies on google-code for fetching, not compatible with
# ffmpeg-3 neither with latest imagemagick (#575988). Removal in a month.
media-sound/gejengel

[gentoo-dev] Lastrites: dev-libs/radlib, net-voip/gnugk, sci-electronics/ghdl...

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (14 Jun 2017)
# Fails to build, nothing needs it in the tree, bug #557450. Removal in a
# month.
dev-libs/radlib

# Pacho Ramos <pa...@gentoo.org> (14 Jun 2017)
# Relies on lots of dead old gnome libs, relies also on berlios.de and it is
# dead for more than 8 years, bug #537708. Removal in a month.
app-office/rubrica

# Pacho Ramos <pa...@gentoo.org> (14 Jun 2017)
# Deprecated in favor of media-fonts/dejavu since many years ago, see bug
# #282754. Removal in a month.
media-fonts/ttf-bitstream-vera

# Pacho Ramos <pa...@gentoo.org> (14 Jun 2017)
# Not needed by anything in the tree, requires an obsolete texinfo version
# and is also the last consumer of gnat-gcc, bug #620982. Removal in a
# month.
sci-electronics/ghdl

# Pacho Ramos <pa...@gentoo.org> (14 Jun 2017)
# Not needed by anything in the tree, unmaintained and waiting for a major
# version bump if someone wants to take care of it, bug #474738. Removal in
# a month.
net-voip/gnugk

# Pacho Ramos <pa...@gentoo.org> (14 Jun 2017)
# All consumers of this newer versions never got ported, if finally we need
# to readd a even newer version of this packages with an hypothetical newer
# Ekiga, we will need to work on new ebuilds anyway, bug #474740. Removal in
# a month.
#
# Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> (25 Jun 2013)
# Mask new ptlib/opal for breakage, tracked in bug #474742
# Lars Wendler <polynomia...@gentoo.org> (29 Apr 2014)
# Adjusted mask so newer versions get covered as well.
>=net-libs/ptlib-2.12.0
>=net-libs/opal-3.12.0

# Pacho Ramos <pa...@gentoo.org> (14 Jun 2017)
# Not needed by anything in the tree, dead since 2006 and also needing our
# rpm package that is buggy and unmaintained, bug # 620986. Removal in a
# month.
app-emulation/domi

# Pacho Ramos <pa...@gentoo.org> (14 Jun 2017)
# Needs someone with the hardware to test how to install it (and its
# configuration files) properly. Dead since 2007, bug #493898. Removal in a
# month.
dev-lang/nqc

Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist

[Pacho Ramos]

El lun, 05-06-2017 a las 13:42 -0400, Michael Orlitzky escribió:
> On 06/05/2017 07:06 AM, Kent Fredric wrote:
> > On Mon, 05 Jun 2017 09:11:27 +0200
> > Hans de Graaff  wrote:
> > 
> > > # Hans de Graaff  (05 Jun 2017)
> > > # Bundles obsolete and vulnerable webkit version.
> > > # Upstream has stopped development and recommends using
> > > # headless mode in >=www-client/chromium-59.
> > > # Masked for removal in 30 days. Bug #589994.
> > > www-client/phantomjs
> > 
> > Can phantomjs be simply masked for a longer period until the development
> > world has had an opportunity to catch up?
> > 
> 
> The real reason for the mask is that it bundles an ancient version of
> qtwebkit with a ton of known security vulnerabilities. Hans was
> attempting to fix it, but now that upstream is dead, it will remain
> insecure forever.
> 

Also, current stable version cannot be built with stable gcc, and latest version
also have lots of unresolved bugs (some building bugs) apart of the security
issues affecting all versions

[gentoo-dev] Lastrites: x11-misc/rednotebook

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (02 Jun 2017)
# Relies on obsolete and vulnerable webkit-gtk version and bundles some libs
# (#597532). Removal in a month.
x11-misc/rednotebook

[gentoo-dev] Lastrites: x11-misc/outwiker and www-client/xombrero

[Pacho Ramos]

# Pacho Ramos <pa...@gentoo.org> (02 Jun 2017)
# This package needs a maintainer to take care of updating this to a working
# version not requiring obsolete wxwidgets and webkit versions (#584170).
# Removal in a month.
x11-misc/outwiker

# Pacho Ramos <pa...@gentoo.org> (02 Jun 2017)
# Still relies on old and vulnerable webkit-gtk versions, bug #608626.
# Removal in a month.
www-client/xombrero