[gentoo-dev] Last rites: media-gfx/videorbits

2021-02-25 Thread David Seifert
# David Seifert  (2021-02-25)
# Last release in 2006, no other distro carries this anymore,
# blocks sci-libs/fftw:2.1 removal, no revdeps.
# Removal on 2021-03-27.  Bug #731038, #772812.
media-gfx/videorbits


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


[gentoo-dev] Last rites: sys-auth/authenticator

2021-02-25 Thread David Seifert
# David Seifert  (2021-02-25)
# Unmaintained, python 3.7 only, relies on wrong libgd, which isn't
# packaged.  Removal on 2021-03-27.  Bug #683358, #696476, #741936.
sys-auth/authenticator


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


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

2021-02-21 Thread David Seifert
# David Seifert  (2021-02-21)
# Drive-by addition, never maintained by maintainer, tests failing,
# missing dependencies, python3.7 only, no reverse dependencies.
# Removal on 2021-03-23.  Bug #738004, #751316, #766989.
dev-python/moviepy


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


[gentoo-dev] Last rites: app-crypt/sign

2021-01-24 Thread David Seifert
# Jakov Smolic  (2021-01-24)
# Last release in 2004. Fails to build with gcc-10 and openssl-1.1.
# Removal on 2021-02-23.  Bugs #707004, #677170, #562724
app-crypt/sign


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


Re: [gentoo-dev] [PATCH 1/1]: distutils-r1.eclass: make distutils_enable_sphinx compatible with DISTUTILS_SINGLE_IMPL

2021-01-16 Thread David Seifert
On Sat, 2021-01-16 at 14:49 +0100, Andrew Ammerlaan wrote:
> See my previous email for the rational behind these changes. This
> closes https://bugs.gentoo.org/704520 and the PR is here:
> https://github.com/gentoo/gentoo/pull/19078
> This eclass is maintained by @mgorny, so I would like to hear his
> thoughts on these changes in particular.
> Best regards,
>  Andrew
>  
> From 9645afdcd4efa7702b538e70bcf2fc4fec93c245 Mon Sep 17 00:00:00 2001
> From: Andrew Ammerlaan 
> Date: Sat, 16 Jan 2021 14:27:00 +0100
> Subject: [PATCH] eclass/distutils-r1: fix distutils_enable_sphinx with
>  DISTUTILS_SINGLE_IMPL
> 
> python-single-r1 does not have the python_gen_any_dep function
> use the python_gen_cond_dep instead
> 
> Closes: https://bugs.gentoo.org/704520
> 
> Signed-off-by: Andrew Ammerlaan 
> ---
>  eclass/distutils-r1.eclass | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 5ffc91be479cb..e2c1e1e403a76 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -329,9 +329,15 @@ distutils_enable_sphinx() {
>   die "${FUNCNAME}: do not pass --no-autodoc if
> external plugins are used"
>   fi
>   if [[ ${autodoc} ]]; then
> - deps="$(python_gen_any_dep "
> - dev-python/sphinx[\${PYTHON_USEDEP}]
> - ${deps}")"
> + if [[ ${DISTUTILS_SINGLE_IMPL} ]]; then
> + deps="$(python_gen_cond_dep "
> + dev-python/sphinx[\${PYTHON_USEDEP}]
> + ${deps}")"
> + else
> + deps="$(python_gen_any_dep "
> + dev-python/sphinx[\${PYTHON_USEDEP}]
> + ${deps}")"
> + fi
>  
>   python_check_deps() {
>   use doc || return 0
>  

Please always send s plaintext email.




Re: [gentoo-dev] [PATCH 2/2] xorg-2.eclass: Remove XORG_STATIC

2021-01-09 Thread David Seifert
On Fri, 2021-01-08 at 23:16 -0500, Matt Turner wrote:
> Statically linking X libraries into your program is an extremely bad
> idea.
> 
> Signed-off-by: Matt Turner 
> ---
>  eclass/xorg-2.eclass | 23 +--
>  1 file changed, 1 insertion(+), 22 deletions(-)
> 
> diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
> index f3b282e1a11..f9a18b8ec26 100644
> --- a/eclass/xorg-2.eclass
> +++ b/eclass/xorg-2.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2020 Gentoo Authors
> +# Copyright 1999-2021 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: xorg-2.eclass
> @@ -168,27 +168,6 @@ fi
>  # If we're a driver package, then enable DRIVER case
>  [[ ${PN} == xf86-video-* || ${PN} == xf86-input-* ]] && DRIVER="yes"
>  
> -# @ECLASS-VARIABLE: XORG_STATIC
> -# @DESCRIPTION:
> -# Enables static-libs useflag. Set to no, if your package gets:
> -#
> -# QA: configure: WARNING: unrecognized options: --disable-static
> -: ${XORG_STATIC:="yes"}
> -
> -# Add static-libs useflag where useful.
> -if [[ ${XORG_STATIC} == yes \
> -   && ${FONT} != yes \
> -   && ${CATEGORY} != app-doc \
> -   && ${CATEGORY} != x11-apps \
> -   && ${CATEGORY} != x11-drivers \
> -   && ${CATEGORY} != media-fonts \
> -   && ${PN} != util-macros \
> -   && ${PN} != xbitmaps \
> -   && ${PN} != xorg-cf-files \
> -   && ${PN/xcursor} = ${PN} ]]; then
> -   IUSE+=" static-libs"
> -fi
> -
>  DEPEND+=" virtual/pkgconfig"
>  
>  # @ECLASS-VARIABLE: XORG_DRI

+1 LGTM.




Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-04 Thread David Seifert
On Mon, 2021-01-04 at 10:24 -0500, Michael Orlitzky wrote:
> I understand that creating an overlay with acct-user overrides will
> not 
> be for everyone, so I have no problem with adding an escape hatch. I
> do 
> think it should be off by default though, and that missing future 
> ::gentoo changes will not be a problem unless some other error has
> been 
> committed first.

This is what we agree on. We need an escape hatch, and it needs to be
off by default. Any sysadmin overriding it gets to keep the pieces, but
they need to have that option.





[gentoo-dev] Last rites: sci-physics/cernlib and revdeps

2021-01-02 Thread David Seifert
# Jakov Smolic  (2021-01-02)
# sci-physics/cernlib fails to build with gcc-10, last release in 2006,
# multiple open bugs, all revdeps also broken and declared EOL upstream.
# Removal in 30 days, bug #763183
sci-physics/cernlib
sci-physics/cernlib-montecarlo
sci-physics/paw


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


[gentoo-dev] Last rites: net-dialup/diald

2021-01-02 Thread David Seifert
# Jakov Smolic  (2021-01-02)
# Fails to build with gcc-10, no maintainer, upstream gone,
# multiple open bugs.
# Removal in 30 days, bug #677322, bug #707200, bug #716012
net-dialup/diald


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


Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

2020-12-31 Thread David Seifert
On Thu, 2020-12-31 at 02:50 +, Peter Stuge wrote:
> Michał Górny wrote:
> > > > I think the three main ways forward from here would be to
> > > > either:
> > > > 
> > > > 1. Keep LibreSSL for indefinite time (possibly masked)
> > > > 2. Eventually move LibreSSL to libressl overlay.
> > > > 3. Eventually remove LibreSSL.
> > > 
> > > 4. A libressl or libressl-libtls ebuild installs only libtls.
> > 
> > dev-libs/libretls already does that.
> 
> dev-libs/libretls doesn't install a libressl libtls.
> 
> This thread is obviously about how the libressl implementation remains
> in use.
> 
> It's clear now that you want to hinder that in Gentoo at any cost to
> the community, but that's not useful, so please take a step back
> unless
> you are actually going to be constructive.
> 
> My proposition 4. (which I suggested already earlier - you shouldn't
> have ignored it) is obviously not about having any libtls provider in
> the tree, but to model reality accurately and ensure that libretls is
> the primary and prefered libtls provider, since it is literally the
> libtls upstream.
> 
> It is important to me that you can choose dev-libs/libretls instead of
> having any libretls code on your systems, but I reject you forcing
> that
> choice of yours on everyone else.
> 
> 
> //Peter
> 

Patches welcome.




Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread David Seifert
On Tue, 2020-12-29 at 22:41 +, Peter Stuge wrote:
> Michał Górny wrote:
> > > I would be happier if some other developers were able and willing
> > > to
> > > participate actively in the LibreSSL project.
> > 
> > But why would they do that?  What I'm really missing in all the
> > replies
> > is a single reason why LibreSSL would be better for anyone.
> 
> Maybe because it is so well-known that monoculture is harmful per se,
> which is why the commitment to choice in Gentoo is very valuable.
> 
> Further, LibreSSL comes out of the OpenBSD project, which has a good
> reputation on code quality.

Like strong-arming 99% of the users of OpenSSH because they were
unwilling to port to the OpenSSL 1.1 API, fully well knowing that most
of the OpenSSH consuming world doesn't actually use libressl? How is
explicitly tying OpenSSH to libressl not a form of monoculture?

If you want to provide an alternative, you have to subsume the API, not
make it superficially compatible, only to find out that the you need to
mask out a ton of stuff with macros. Case in point: Have you tried using
the official libjpeg package instead of libjpeg-turbo? Go ahead, give it
a try. "Monoculture"s are mostly a coincidence, not some sinister
conspiracy. Implementation-diversity-but-API-compatibility is mostly a
pipe dream, as libav, imagemagick, libjpeg have shown.




Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread David Seifert
On Tue, 2020-12-29 at 13:21 +, Peter Stuge wrote:
> Michał Górny wrote:
> > > 2.  Install them into different prefixes (eg /usr/lib/openssl +
> > > /usr/lib/libressl and have the linker link to a specific version,
> > > /usr/include/{openssl,libressl} too).
> > 
> > For the record, this is something I've been wondering about for a
> > long
> > time.  However, there are two problems with that: a small one
> > and a huge one.
> > 
> > The small problem is that this requires a lot of additional
> > downstream
> > work.  I mean, you have to explicitly support the choice in ebuilds,
> > and this means making things even harder for newcomers.
> 
> pkg-config/pkgconf and .pc files can help with this part, taking care
> of all abstraction if/when downstream uses a libressl.pc.

As we have learned from the ncurses[tinfo] debacle, 80% of build systems
don't use the .pc files, and just guess "-lssl" flags and a bunch of
include dirs. Hence, this boils down to patching a mountain of build
systems again, which while being the ultimately correct way, is a pipe
dream.

> > The big problem is that (unless I'm mistaken) we won't be able to
> > load
> > LibreSSL and OpenSSL to the same executable.  So we'd actually have
> > to
> > enforce that the whole link chain links to the same SSL provider,
> > and effectively land pretty close to where we are now.
> 
> I'd suggest investigating whether symbol versioning could help with
> this,
> or if the only way forward would indeed be to require some symbol
> mangling/rewriting.

While this sounds like a theoretical solution, it isn't tractable
because
1. We're inventing our own ABI that is incompatible with everyone else's
2. We'd have to maintain a huge swamp of downstream patches
3. ABI can still break even with perfect symbol versioning




[gentoo-dev] Re: [RFC] Discontinuing LibreSSL support?

2020-12-28 Thread David Seifert
On Mon, 2020-12-28 at 09:56 +0100, Michał Górny wrote:
> Hello, developers and Gentoo LibreSSL team.
> 
> TL;DR: is there really a point in continuing the never-ending always-
> regressing struggle towards supporting LibreSSL in Gentoo?
> 
> 
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL.  Similarly how we
> ended up deciding that fighting for libav was unpractical and the vast
> majority of users are using ffmpeg (because they didn't really have
> a choice), today it seems that LibreSSL is suffering the same fate.
> 
> LibreSSL users, does LibreSSL today have any benefit over OpenSSL?
> To be honest, I don't think so.  In 2014, it might have represented
> a new quality.  But today, OpenSSL is alive and kicking, and LibreSSL
> finds it hard to keep up.
> 
> The vast majority of software is not tested against LibreSSL.  While
> patches are usually trivial and we have people that submit them,
> I find many of them short-sighted.  Just look at [1].  Sure, it fixes
> the build today but it disabled the feature for all foreseeable
> future.
> How likely is it that somebody will submit another patch reenabling it
> with a future LibreSSL version?
> 
> While normally I strongly prefer submitting such patches upstream,
> that
> makes things even worse.  I mean, I wouldn't be surprised if there
> were
> dozens of packages today that are crippled with LibreSSL just because
> somebody fixed the build in the past and never revisited the problem.
> 
> This somewhat resembles running in circles.  Packages kept being
> broken
> with LibreSSL because rarely anyone is using it.  And rarely anyone is
> using LibreSSL because the apparent benefit (or lack thereof) does not
> justify the constant breakage (plus invisible regressions).
> 
> All this considered, provided that nobody is able to find a good
> reason
> to use LibreSSL, I would like to propose that we stop patching
> packages, discontinue support for it and last rite it.
> 
> 
> [1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892
> 

As someone who joined the LibreSSL project back in the days, I second
this. The ROI given the breakages involved and, in many cases,
downstream patch carrying just doesn't seem like a positive tradeoff.
The idea was noble, but let's be honest: After 6 years, there's no end
in sight, and we seem to be going nowhere.




[gentoo-dev] Last rites: sci-libs/xkaapi

2020-12-11 Thread David Seifert
# Aisha Tammy  (2020-12-11)
# last update upstream in 2017, does not build.
# OpenMP is a better alternative.
# Bug #717692, #741594
# Removal in 30 days.
sci-libs/xkaapi


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


[gentoo-dev] Last rites: dev-lang/cilk

2020-12-11 Thread David Seifert
# David Seifert  (2020-12-11)
# Last MIT release in 2007, declared EOL by Intel in 2017.
# Build and test failures, abandoned parallelism paradigm,
# no revdeps. If you're really still using this, switch to
# OpenMP. Bug #572130, #643590, Removal in 30 days.
dev-lang/cilk


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


[gentoo-dev] Last rites: app-text/cook

2020-11-28 Thread David Seifert
# David Seifert  (2020-11-28)
# Last release in 2002, multiple open bugs, no maintainer, no revdeps.
# Bug #709512, #713300, #729518, Removal in 30 days.
app-text/cook


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


Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread David Seifert
On Thu, 2020-11-26 at 17:45 -0500, Michael Orlitzky wrote:
> On 11/26/20 5:37 PM, Peter Stuge wrote:
> > Georgy Yakovlev wrote:
> > > I'll be switching default tmpfiles provider to sys-apps/systemd-
> > > tmpfiles
> > > by the end of the week by updating virtual/tmpfiles ebuild.
> > 
> > Michael Orlitzky wrote:
> > > Corollary: the tmpfiles.d specification can only be implemented
> > > (safely)
> > > on Linux after all.
> > 
> > So should virtual/tmpfiles differentiate based on system?
> > 
> 
> There's no scenario where opentmpfiles is preferable.
> 
> systemd-tmpfiles with the fs.protected_hardlinks=1 sysctl is secure on
> Linux. On other kernels, you're out of luck -- none of the options are
> secure. Securing the service manager on other kernels would require
> dropping tmpfiles entirely, and major changes to OpenRC.
> 

...which is mostly a theoretical exercise, because we only support Linux
anyways.




[gentoo-dev] Last rites: games-emulation/fakenes

2020-11-22 Thread David Seifert
# David Seifert  (2020-11-22)
# Upstream abandoned since 2012, tons of QA issues and
# build bugs, esoteric NIH build system. Bug #293567, #670954,
# #697444, #699320, #708058, #746230, Removal in 30 days.
games-emulation/fakenes


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


Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages & projects up for grabs due to jer's retirement

2020-11-03 Thread David Seifert
On Tue, 2020-11-03 at 22:48 +0100, Michał Górny wrote:
> On Tue, 2020-11-03 at 22:32 +0100, Michał Górny wrote:
> > Hi.
> > 
> > The following projects have no members right now:
> > 
> > https://wiki.gentoo.org/wiki/Project:Debian_Tools
> > 
> > Additionally, the following packages are looking for a new
> > maintainer:
> > [...]
> 
> Of course, missed an eclass:
> 
> nvidia-drivers.eclass
> 

I'll take nvidia




[gentoo-dev] Last rites: fdo-mime.eclass

2020-11-03 Thread David Seifert
# @DEAD
# No consumers left. Removal in 30 days.


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


[gentoo-dev] Last rites: split lapack packages

2020-10-31 Thread David Seifert
# Aisha Tammy  (2020-10-31)
# Redundant historical packages now being provided
# together by sci-libs/lapack
# Removal in 14 days. Bug #746962.
sci-libs/blas-reference
sci-libs/cblas-reference
sci-libs/lapack-reference


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


[gentoo-dev] Last rites: sci-electronics/alliance

2020-10-24 Thread David Seifert
# David Seifert  (2020-10-24)
# EAPI 4, broken since 2012, upstream disappeared, multiple QA issues,
# build system is completely broken. Removal in 30 days,
# Bug #625118, #725438, #746029.
sci-electronics/alliance


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


[gentoo-dev] Last rites: sys-power/nvram-wakeup

2020-10-24 Thread David Seifert
# David Seifert  (2020-10-24)
# EAPI 4, multiple QA issues, performs dangerous pointer-to-int
# casts, can trash your computer, last release over 10 years ago.
# Removal in 30 days. Bug #124755, #713472, #726020, #740912, #742434.
sys-power/nvram-wakeup


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


[gentoo-dev] Last rites: sys-cluster/mvapich2

2020-10-24 Thread David Seifert
# David Seifert  (2020-10-24)
# EAPI 4, doesn't build, outdated, ebuild has multiple QA issues.
# Removal in 30 days. Bug #463188, #531104, #613116, #740926.
sys-cluster/mvapich2


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


[gentoo-dev] Last rites: sys-cluster/maui

2020-10-24 Thread David Seifert
# David Seifert  (2020-10-24)
# EAPI 4, fetch restricted, download link disappeared, fails to build.
# Removal in 30 days. Bug #365713, #405277, #405437, #414793, #415699,
# #422799, #479288, #740928.
sys-cluster/maui


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


[gentoo-dev] Last rites: dev-dotnet/{gio-sharp,ikvm-bin,log4net}

2020-10-24 Thread David Seifert
# David Seifert  (2020-10-24)
# EAPI 4, abandoned upstream, fails to build, security vulnerabilities.
# .NET is practically abandoned in Gentoo and needs a complete reboot.
# Removal in 30 days. Bug #681194, #722256, #740986, #740988, #740990.
dev-dotnet/gio-sharp
dev-dotnet/ikvm-bin
dev-dotnet/log4net


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


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

2020-10-21 Thread David Seifert
# David Seifert  (2020-10-21)
# No releases in over 3 years, no more revdeps in tree
# upstream mostly unresponsive to requests for proper
# tarballs. Removed from Fedora and Ubuntu already.
# Bug #708700, Removal in 30 days.
dev-python/PythonQt


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


Re: [gentoo-dev] [PATCH 3/3] lua-utils.eclass: Add lua_get_static_lib()

2020-10-12 Thread David Seifert
On Mon, 2020-10-12 at 17:57 +0200, Marek Szuba wrote:
> On 2020-10-12 17:39, David Seifert wrote:
> 
> > When is passing static libs ever useful for Lua?
> 
> No idea - but both Lua and LuaJIT install them, if conditionally on 
> USE=static-libs in the latter case.
> 

Then please don't provide this helper function. Consumers should just
use lua_get_shared_lib(). We similarly don't provide getters for
libpythonX.Y.a either, for the same reason.




Re: [gentoo-dev] [PATCH 3/3] lua-utils.eclass: Add lua_get_static_lib()

2020-10-12 Thread David Seifert
On Mon, 2020-10-12 at 16:05 +0200, Marek Szuba wrote:
> For build systems which must be pointed directly to the relevant
> files,
> e.g. CMake.
> 
> Signed-off-by: Marek Szuba 
> ---
>  eclass/lua-utils.eclass | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 100be14cb08..922f72b80d6 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -329,6 +329,11 @@ _lua_export() {
>   export LUA_SHARED_LIB="${val}".so
>   debug-print "${FUNCNAME}:
> LUA_SHARED_LIB = ${LUA_SHARED_LIB}"
>   ;;
> + LUA_STATIC_LIB)
> + local val=$(_lua_get_library_file
> ${impl})
> + export LUA_STATIC_LIB="${val}".a
> + debug-print "${FUNCNAME}:
> LUA_STATIC_LIB = ${LUA_STATIC_LIB}"
> + ;;
>   LUA_VERSION)
>   local val
>  
> @@ -443,6 +448,25 @@ lua_get_shared_lib() {
>   echo "${LUA_SHARED_LIB}"
>  }
>  
> +# @FUNCTION: lua_get_static_lib
> +# @USAGE: []
> +# @DESCRIPTION:
> +# Obtain and print the expected name, with path, of the main static
> library
> +# of the given Lua implementation. If no implementation is provided,
> +# ${ELUA} will be used.
> +#
> +# Note that it is up to the ebuild maintainer to ensure Lua actually
> +# provides a static library.
> +#
> +# Please note that this function requires Lua and pkg-config
> installed,
> +# and therefore proper build-time dependencies need be added to the
> ebuild.
> +lua_get_static_lib() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + _lua_export "${@}" LUA_STATIC_LIB
> + echo "${LUA_STATIC_LIB}"
> +}
> +
>  # @FUNCTION: lua_get_version
>  # @USAGE: []
>  # @DESCRIPTION:

When is passing static libs ever useful for Lua?




[gentoo-dev] Last rites: dev-dotnet/mono-addins and media-gfx/pinta

2020-10-03 Thread David Seifert
# David Seifert  (2020-10-03)
# Broken for over 2 years, declared EOL by upstream,
# the only revdep is media-gfx/pinta, which is also
# broken. Bug #612592, #644232, #659436, #688722,
# Removal in 30 days.
dev-dotnet/mono-addins
media-gfx/pinta


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


Re: [gentoo-dev] Last rites: app-leechcraft/*, virtual/leechcraft-*

2020-09-22 Thread David Seifert
On Tue, 2020-09-22 at 07:51 -0500, Georg Rudoy wrote:
> The PR ( https://github.com/gentoo/gentoo/pull/15938 ) contains
> non-live snapshot ebuilds. Although, indeed, it's been last updated a
> few months ago.
> 
> What's ultimately blocking there is splitting the commit adding those
> ebuilds into multiple commits, one per package, while keeping the tree
> consistent. I admit I hadn't had (and most likely won't have in the
> foreseeable future) the resources to do these
> consistent-per-package-commits — doing this (effectively a toposort,
> counting in the dependencies between ebuilds) by hand is painful, and
> there's no good automation I'm aware of that'll do that for me. On the
> other hand,
> 1. I know at least some other multipackage groups don't always do
> per-package updates and instead commit everything in one fell swoop
> (like qt, for instance).
> 2. I think I've been told on #gentoo-proxy-dev that if this indeed
> proves to be a burdensome thing, adding all the ebuilds in one commit
> is feasible. But it's indeed been a while ago, keeping track of time
> is hard.
> 
> If (2) is correct, I'm more than happy to fix whatever other issues
> are pointed out in the PR.
> 
> But, of course, all this is ultimately up to you folks. I'm just a
> proxy.
> 
> вт, 22 сент. 2020 г. в 07:12, Joonas Niilola :
> 
> > I'd also like to point out something regarding "- packages
> > only"; It
> > may be buildable one day for users, and broken the next. And some of
> > the
> > deps may be unbuildable, it's really random and up to state of
> > upstream
> > instead of state of ::gentoo repo. This was the case with leechcraft
> > for
> > example, check bug #693328. You should always have a keyworded
> > static
> > version available.
> > 
> > -- juippis
> > 
> > On 9/22/20 2:23 PM, Michał Górny wrote:
> > > # Michał Górny  (2020-09-22)
> > > # Poorly maintained suite of NIH packages.  Only live ebuilds left
> > > # for over a year.  This really belongs in an overlay.  Some of
> > > them
> > > # depend on deprecated dev-qt/qtwebkit (#684672).
> > > # Removal in 14 days.  Bug #693328.
> > > app-leechcraft/laretz
> 
> --
>   Georg Rudoy
> 

No, the original point really stands. The energy we have invested in
EAPI bumping and what not is in no relation to the actual gain. The ROI
on leechcraft has been negative, and not just by a small bit. The back
and forth has been tiring, and the last-ditch efforts always come in at
the last minute. This time it's going for sure.




[gentoo-dev] Last rites: sys-block/rts5229

2020-09-19 Thread David Seifert
# David Seifert  (2020-09-20)
# EAPI 4, last release in 2012, sandbox violations and
# full of bugs. Mainlined since 3.14, Removal in 30 days.
# Bug #679502, #701406, #701408, #742116.
sys-block/rts5229


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


[gentoo-dev] Last rites: sci-mathematics/axiom

2020-09-19 Thread David Seifert
# David Seifert  (2020-09-19)
# EAPI 4, last release in 2008, upstream pretty much dead,
# tons of bugs, broken since at least 2016, lots of weird
# dead/alive/redead forks all over the internet. Use
# sci-mathematics/fricas as spiritual successor fork.
# Removal in 30 days.  Bug #326575, #514762, #532498,
# #574956, #581250, #586402, #587878, #740966.
sci-mathematics/axiom


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


[gentoo-dev] Last rites: sci-chemistry/ortep3

2020-09-16 Thread David Seifert
# David Seifert  (2020-09-16)
# EAPI 4, last release in 2001, the Fortran source code
# is terrible and has buffer overflows.
# Removal in 30 days.  Bug #664120, #742008.
sci-chemistry/ortep3




Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files

2020-09-14 Thread David Seifert
On Sun, 2020-09-13 at 14:21 +0300, Andrew Savchenko wrote:
> On Sat, 29 Aug 2020 21:53:45 +0200 Michał Górny wrote:
> > Thanks to David Michael for the initial patch and upstream fixes.
> > 
> > Signed-off-by: Michał Górny 
> > ---
> >  eclass/acct-group.eclass | 16 +++-
> >  eclass/acct-user.eclass  | 16 +++-
> >  2 files changed, 30 insertions(+), 2 deletions(-)
> > 
> > diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> > index 5550e4a2fb10..dc1562974870 100644
> > --- a/eclass/acct-group.eclass
> > +++ b/eclass/acct-group.eclass
> > @@ -80,7 +80,7 @@ S=${WORKDIR}
> >  
> >  
> >  # << Phase functions >>
> > -EXPORT_FUNCTIONS pkg_pretend pkg_preinst
> > +EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst
> >  
> >  # @FUNCTION: acct-group_pkg_pretend
> >  # @DESCRIPTION:
> > @@ -116,6 +116,20 @@ acct-group_pkg_pretend() {
> > fi
> >  }
> >  
> > +# @FUNCTION: acct-group_src_install
> > +# @DESCRIPTION:
> > +# Installs sysusers.d file for the group.
> > +acct-group_src_install() {
> > +   debug-print-function ${FUNCNAME} "${@}"
> > +
> > +   insinto /usr/lib/sysusers.d
> > +   newins - ${CATEGORY}-${ACCT_GROUP_NAME}.conf < <(
> > +   printf "g\t%q\t%q\n" \
> > +   "${ACCT_GROUP_NAME}" \
> > +   "${ACCT_GROUP_ID/#-*/-}"
> > +   )
> > +}
> > +
> >  # @FUNCTION: acct-group_pkg_preinst
> >  # @DESCRIPTION:
> >  # Creates the group if it does not exist yet.
> > diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> > index e82f3c56dbbe..f9772c3cb111 100644
> > --- a/eclass/acct-user.eclass
> > +++ b/eclass/acct-user.eclass
> > @@ -312,7 +312,7 @@ acct-user_pkg_pretend() {
> >  # @FUNCTION: acct-user_src_install
> >  # @DESCRIPTION:
> >  # Installs a keep-file into the user's home directory to ensure it
> > is
> > -# owned by the package.
> > +# owned by the package, and sysusers.d file.
> >  acct-user_src_install() {
> > debug-print-function ${FUNCNAME} "${@}"
> >  
> > @@ -321,6 +321,20 @@ acct-user_src_install() {
> > # created yet
> > keepdir "${ACCT_USER_HOME}"
> > fi
> > +
> > +   insinto /usr/lib/sysusers.d
> > +   newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
> > +   printf "u\t%q\t%q\t%q\t%q\t%q\n" \
> > +   "${ACCT_USER_NAME}" \
> > +   "${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
> > +   "${DESCRIPTION//[:,=]/;}" \
> > +   "${ACCT_USER_HOME}" \
> > +   "${ACCT_USER_SHELL/#-*/-}"
> > +   if [[ ${#ACCT_USER_GROUPS[@]} -gt 1 ]]; then
> > +   printf "m\t${ACCT_USER_NAME}\t%q\n" \
> > +   "${ACCT_USER_GROUPS[@]:1}"
> > +   fi
> > +   )
> >  }
> 
> Why these files are installed unconditionally?
> 
> Of course we have a common "small files" policy that USE flags
> should not control small files in packages, such rule was designed
> for common packages where:
>   1) small files are insignificant disk usage compared to a whole
> package;
>   2) an average package takes significant time to rebuild and mass
> rebuild will cause problems during USE flip.
> 
> While both arguments are valid for a common packages which provide
> real software, this is not true for very special acct-* packages:
>   1) They may (and usually do) have zero size of installed files,
> this makes sysusers.d stuff an infinite times larger than a
> whole typical acct-* package (it will still be much larger if one
> will consider size of new passw/group records).

Using a multiplicative factor here seems purely for trying to make an
argument. Any filesystem space taken here seems negligible.

>   2) acct-* packages are very fast to rebuild, so such price will
> be small compared to other changes necessary when USE="systemd" is
> being flipped.
> 
> So it will be reasonable to add USE="systemd" to acct-* eclasses
> to control the changes proposed above.

Why not add these paths to INSTALL_MASK to ease the burden on the number
of installed files?

There's another argument to be made: every USE flag added potentially
increases the complexity of the depgraph. Given the tradeoffs, I'm
willing to accept a tiny file more here.




Re: [gentoo-dev] [PATCH 2/2] eutils.eclass: Use optfeature() from optfeature.eclass

2020-09-06 Thread David Seifert
On Sun, 2020-09-06 at 21:49 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 06 Sep 2020, David Seifert wrote:
> > @@ -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 preserve-libs \
> > +   inherit desktop epatch estack ltprune multilib optfeature
> > preserve-libs \
> > toolchain-funcs vcs-clean
> > ;;
> >  esac
> 
> I count 163 ebuilds calling optfeature in EAPI 7, but only 24 in older
> EAPIs, which makes me wonder if the conditional inherit makes any
> sense.
> 
> Maybe just commit the new eclass, update ebuilds, then remove the
> function from eutils?
> 
> Ulrich

I'll get a lot of heat for breaking EAPI 2 ebuilds in some random
abandoned overlay because we guarantee eclass API backwards
compatibility for 20 years!




Re: [gentoo-dev] [PATCH 1/2] optfeature.eclass: New eclass with definition from eutils

2020-09-06 Thread David Seifert
On Sun, 2020-09-06 at 18:51 +0300, Joonas Niilola wrote:
> On 9/6/20 6:47 PM, David Seifert wrote:
> > ---
> >  eclass/optfeature.eclass | 63
> > 
> >  1 file changed, 63 insertions(+)
> >  create mode 100644 eclass/optfeature.eclass
> > 
> Can we have the "why" answered? Wasn't this supposed to be part of
> future EAPI?
> 
> -- juippis
> 
> 

It's one of those features that comes up once a year, everyone agrees
that it would be great to have, noone wants to provide a proof-of-
concept because portage, and then it gets deferred for another round of
EAPI. Unless I can be convinced that it will be in EAPI 8, this function
will likely stick around.




[gentoo-dev] [PATCH 2/2] eutils.eclass: Use optfeature() from optfeature.eclass

2020-09-06 Thread David Seifert
Signed-off-by: David Seifert 
---
 eclass/eutils.eclass | 49 ++--
 1 file changed, 2 insertions(+), 47 deletions(-)

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index 20dec774f2f..4255056f310 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2019 Gentoo Authors
+# Copyright 1999-2020 Gentoo Authors
 # 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 preserve-libs \
+   inherit desktop epatch estack ltprune multilib optfeature preserve-libs 
\
toolchain-funcs vcs-clean
;;
 esac
@@ -186,51 +186,6 @@ use_if_iuse() {
use $1
 }
 
-# @FUNCTION: optfeature
-# @USAGE:   [other atoms]
-# @DESCRIPTION:
-# Print out a message suggesting an optional package (or packages)
-# not currently installed which provides the described functionality.
-#
-# The following snippet would suggest app-misc/foo for optional foo support,
-# app-misc/bar or app-misc/baz[bar] for optional bar support
-# and either both app-misc/a and app-misc/b or app-misc/c for alphabet support.
-# @CODE
-#  optfeature "foo support" app-misc/foo
-#  optfeature "bar support" app-misc/bar app-misc/baz[bar]
-#  optfeature "alphabet support" "app-misc/a app-misc/b" app-misc/c
-# @CODE
-optfeature() {
-   debug-print-function ${FUNCNAME} "$@"
-   local i j msg
-   local desc=$1
-   local flag=0
-   shift
-   for i; do
-   for j in ${i}; do
-   if has_version "${j}"; then
-   flag=1
-   else
-   flag=0
-   break
-   fi
-   done
-   if [[ ${flag} -eq 1 ]]; then
-   break
-   fi
-   done
-   if [[ ${flag} -eq 0 ]]; then
-   for i; do
-   msg=" "
-   for j in ${i}; do
-   msg+=" ${j} and"
-   done
-   msg="${msg:0: -4} for ${desc}"
-   elog "${msg}"
-   done
-   fi
-}
-
 case ${EAPI:-0} in
 0|1|2|3|4)
 
-- 
2.28.0




[gentoo-dev] [PATCH 1/2] optfeature.eclass: New eclass with definition from eutils

2020-09-06 Thread David Seifert
Signed-off-by: David Seifert 
---
 eclass/optfeature.eclass | 63 
 1 file changed, 63 insertions(+)
 create mode 100644 eclass/optfeature.eclass

diff --git a/eclass/optfeature.eclass b/eclass/optfeature.eclass
new file mode 100644
index 000..b0082606cd6
--- /dev/null
+++ b/eclass/optfeature.eclass
@@ -0,0 +1,63 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: optfeature.eclass
+# @MAINTAINER:
+# base-sys...@gentoo.org
+# @BLURB: Advertise optional functionality that might be useful to users
+
+case "${EAPI:-0}" in
+   [0-7]) ;;
+   *) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" ;;
+esac
+
+if [[ -z ${_OPTFEATURE_ECLASS} ]]; then
+_OPTFEATURE_ECLASS=1
+
+# @FUNCTION: optfeature
+# @USAGE:   [other atoms]
+# @DESCRIPTION:
+# Print out a message suggesting an optional package (or packages)
+# not currently installed which provides the described functionality.
+#
+# The following snippet would suggest app-misc/foo for optional foo support,
+# app-misc/bar or app-misc/baz[bar] for optional bar support
+# and either both app-misc/a and app-misc/b or app-misc/c for alphabet support.
+# @CODE
+#  optfeature "foo support" app-misc/foo
+#  optfeature "bar support" app-misc/bar app-misc/baz[bar]
+#  optfeature "alphabet support" "app-misc/a app-misc/b" app-misc/c
+# @CODE
+optfeature() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   local i j msg
+   local desc=$1
+   local flag=0
+   shift
+   for i; do
+   for j in ${i}; do
+   if has_version "${j}"; then
+   flag=1
+   else
+   flag=0
+   break
+   fi
+   done
+   if [[ ${flag} -eq 1 ]]; then
+   break
+   fi
+   done
+   if [[ ${flag} -eq 0 ]]; then
+   for i; do
+   msg=" "
+   for j in ${i}; do
+   msg+=" ${j} and"
+   done
+   msg="${msg:0: -4} for ${desc}"
+   elog "${msg}"
+   done
+   fi
+}
+
+fi
-- 
2.28.0




Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation

2020-09-06 Thread David Seifert
On Thu, 2020-09-03 at 15:37 +0200, Marek Szuba wrote:
> Ladies and gentlemen,
> 
> Here is my first attempt on creating an eclass which would handle
> installation of Lua modules for multiple implementations. As some of
> you
> are aware of, the lack of such an eclass has been a major issue for
> our
> efforts on slotting dev-lang/lua.
> 
> With many, many thanks to mgorny and everyone else who has worked on
> python-r1.eclass, to whom lua.eclass bears, ahem, striking
> resemblance.
> 
> At the moment this is only really useful for installing Lua modules
> but
> assuming it doesn't turn out to be a total failure, I'll work on
> single-target support as the next step. We should probably think about
> adding LuaJIT support at some point too.
> 
> Comments are very much welcome!

This is finally going in the right direction. Unfortunately we won't get
around a single-r1-style eclass too. What about all those programs
embedding a specific lua version as plugin architecture? Conversely, we
also won't get around the multi eclass too, given how many upstreams
won't unbundle/port their lua dependencies and require access to pure-
lua packages. But the basic principles underlying your eclass are
finally correct, unlike the previous lua.eclass attempt.




Re: [gentoo-dev] Enable "gui" flag in desktop profile

2020-08-27 Thread David Seifert
On Thu, 2020-08-27 at 11:46 +0200, Ulrich Mueller wrote:
> QA policy says that packages should use the "gui" USE flag for
> optional
> GUI support:
> https://projects.gentoo.org/qa/policy-guide/use-flags.html#pg0802
> 
> IMHO this means that the "gui" flag should be enabled in desktop
> profiles (similar to "X").
> 
> Any comments? If not, I'll enable it in two days from now.

ACK, please do so, thanks.




Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread David Seifert
On Tue, 2020-08-18 at 18:06 +0200, Michał Górny wrote:
> On Tue, 2020-08-18 at 11:58 -0400, Mike Gilbert wrote:
> > On Tue, Aug 18, 2020 at 11:48 AM Michał Górny 
> > wrote:
> > > On Tue, 2020-08-18 at 15:36 +, Peter Stuge wrote:
> > > > Joonas Niilola wrote:
> > > > > some of you may already have seen the new packages.gentoo.org
> > > > > page,
> > > > >   https://packages.gentoo.org/
> > > > 
> > > > I had not seen that - that's wonderful!
> > > > 
> > > > I would just request that /packages/ is removed from the start
> > > > of
> > > > package URLs. I understand how this makes request routing more
> > > > complicated, but I consider it a significant usability
> > > > improvement.
> > > > 
> > > > 
> > > > ..anyway:
> > > > 
> > > > > I'm suggesting of adding a new metadata flag to our Wiki's
> > > > > User:/Project: page which then prints a message to this page
> > > > > saying
> > > > > whether the maintainer (be it project or user), "accepts" or
> > > > > "deals
> > > > > with" Github contributions. The wording can be a bit better,
> > > > > but it'd be
> > > > > there to **notify** our **contributors** whether their time
> > > > > and effort
> > > > > will most likely be wasted making a pull request for this
> > > > > particular
> > > > > maintainer.
> > > > 
> > > > I think this is a very good feature.
> > > > 
> > > > If I ever do become a proper Gentoo developer I will certainly
> > > > not spend
> > > > any time on anything to do with GitHub, and in my current
> > > > position of
> > > > occasional contributor I don't either. The workflow imposed by
> > > > GitHub
> > > > isn't good and it's important to demonstrate other methods.
> > > > 
> > > 
> > > Read: it's important to slap users to satisfy developer's
> > > wannabes.
> > 
> > This sentence makes no sense, but it seems to be saying something
> > rude.
> > 
> > Would you like to clarify?
> > 
> 
> If user puts effort to make a good contribution, the developer
> shouldn't
> be rejecting it to 'demonstrate other methods'.  This is the horrible
> attitude that kills the project.
> 

Have to second this. "I'm not a Gentoo developer, but if I were, I
wouldn't use it" - what sort of ultimate put-down is that, because
someone seems to have an axe to grind.




Re: [gentoo-dev] [PATCH] media-fonts/font-misc-misc: upgrade to EAPI 7

2020-08-03 Thread David Seifert
On Mon, 2020-08-03 at 13:27 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 02 Aug 2020, Henrik Pihl wrote:
> > +IUSE=""
> > +DEPEND=""
> > +RDEPEND="${DEPEND}"
> 
> These empty assignments are not necessary and should be dropped.
> 
> Ulrich

Agreed, please drop them.




Re: [gentoo-dev] RFC: packages.g.o: new features available

2020-07-08 Thread David Seifert
On Wed, 2020-07-08 at 02:57 +, Max Magorsch wrote:
> Hi all,
> 
> I am glad to announce further progress at packages.gentoo.org (pgo in
> the following). Compared to previous work during the last months,
> which mostly addressed the back end, the new changes are rather
> comprehensive. That's why I am looking forward to feedback here.
> 
> So the tl;dr is that the new pgo version now displays:
>   - dependencies
>   - reverse dependencies
>   - pkgcheck results
>   - repology.org data
>   - github pull requests
>   - stabilization bugs
>   - keywording bugs
>   - security bugs
>   - general bugs
> for each package.
> 
> Additionally, there are new sites for all package maintainers, that
> is:
>   - Gentoo Projects (e.g. pyt...@gentoo.org)
>   - Gentoo Developers  (e.g. la...@gentoo.org
>   - Proxied Maintainers (e.g. la...@the-cow.de)
> 
> The maintainer's sites contain:
>   - all packages of the maintainer
>   - all outdated packages (according to repology)
>   - all related pull requests
>   - all related bugs (general, keywording and stabilization)
>   - all security bugs
>   - the changelog of all maintained packages
> You will find the new sites under the 'Maintainers' tab.
> 
> The overall appearance of the site has also slightly changed to
> display all of the new information.
> 
> Currently, the new version is deployed to:
> 
>   https://packagestest.gentoo.org/
> 
> Everyone is welcome to take a look around and tell me whether you
> consider the new information as useful for your workflow and/or what
> you would still change.
> 
> I'm looking forward to your feedback.
> 
> -M
> 

Max,
your contributions to Gentoo in such a short time have been nothing
short of amazing. This is absolutely great and a massive help to me.

David




Re: [gentoo-dev] Packages up for grabs: app-arch/unar, x11-misc/rofi-calc

2020-07-05 Thread David Seifert
On Sun, 2020-07-05 at 09:53 +0300, Joonas Niilola wrote:
> Hey all,
> 
> due to retirement of a proxied maintainer, app-arch/unar and
> x11-misc/rofi-calcare maintainer-needed. No bugs are open for either,
> but rofi-calc seems to have a new release available.
> 
> -- juippis
> 
> 

I'll take app-arch/unar.




Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

2020-05-11 Thread David Seifert
On Mon, 2020-05-11 at 09:51 -0400, Mike Gilbert wrote:
> On Sun, May 10, 2020 at 5:16 PM William Hubbs 
> wrote:
> > All,
> > 
> > now that go 1.14.2 is stable, I want to remove the EGO_VENDOR
> > support from
> > go-module.eclass.
> > 
> > This was kept when the EGO_SUM support was added on 4 Mar, with a qa
> > warning advising people to migrate their ebuilds to EGO_SUM.
> > 
> > This patch makes migrating mandatory by forcing ebuilds to die if
> > they
> > have EGO_VENDOR set and are using go-module.eclass.
> > 
> > Thoughts?
> 
> It seems like you're being very lazy about this. At a minimum, you
> should do the following:
> 
> 1. Search for affected packages.
> 2. Contact the maintainers, possibly via bug reports.
> 3. Give them a some time to convert their packages.
> 4. Mask any packages that do not get updated.
> 

Wow, and python changing one line in its implementation details is
breaking the world, whereas there's still a ton of users of EGO_VENDOR
in the tree?




Re: [gentoo-dev] [PATCH] rebar.eclass: Run tests with new code

2020-05-02 Thread David Seifert
On Sat, 2020-05-02 at 19:02 +0200, Hanno Böck wrote:
> Due to an update of dev-erlang/fast_tls I noticed an issue in the
> rebar
> eclass with tests.
> 
> It seems the way the eclass currently works it is running tests with
> the library installed in the system, not the code just compiled.
> 
> This is obviously not what we want and it also obviously can fail if
> the new tests use features that aren't present in the old version in
> the system.
> 
> The patch below fixes this and runs tests with libs from the current
> directory.
> 
> Closes: https://bugs.gentoo.org/720448
> Signed-off-by: Hanno Böck 
> ---
> 
> diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
> index 92dd16b08..f9849f0ff 100644
> --- a/eclass/rebar.eclass
> +++ b/eclass/rebar.eclass
> @@ -105,6 +105,9 @@ erebar() {
>   (( $# > 0 )) || die "erebar: at least one target is required"
>  
>   local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)"
> + if [ "$1" = "eunit" ]; then
> + local -x ERL_LIBS="."
> + fi
>   rebar -v skip_deps=true "$@" || die -n "rebar $@ failed"
>  }
>  
> 
> 

Please use proper bash brackets and shorten everything to

[[ ${1} == eunit ]] && local -x ERL_LIBS="."





Re: [gentoo-dev] [PATCH] meson.eclass: export NM and READELF variables

2020-04-20 Thread David Seifert
On Mon, 2020-04-20 at 11:18 -0400, Mike Gilbert wrote:
> These are used by the symbolextractor.py script in meson.
> 
> Closes: https://bugs.gentoo.org/717720
> Signed-off-by: Mike Gilbert 
> ---
>  eclass/meson.eclass | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 2bd1dc017609..81cfa7c38fc6 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -261,6 +261,11 @@ meson_src_configure() {
>   "${BUILD_DIR}"
>   )
>  
> + # Used by symbolextractor.py
> + # https://bugs.gentoo.org/717720
> + tc-export NM
> + tc-getPROG READELF readelf >/dev/null
> +
>   # https://bugs.gentoo.org/625396
>   python_export_utf8_locale
>  

+1
Thanks for adding this, LGTM.




Re: [gentoo-dev] Packages up for grabs

2020-04-14 Thread David Seifert
On Tue, 2020-04-14 at 11:36 +0300, Joonas Niilola wrote:
> Hey,
> 
> here's a list of packages recently dropped to maintainer-needed due to
> retirement of multiple inactive proxied maintainers.
> 
> (b) = open bugs,
> (v) = new version is available.
> 
> --
> net-im/skypeforlinux (b)
> net-vpn/vpnc (b,v)
> x11-wm/notion (b,v)
> --

I'll take these




Re: [gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla

2020-04-13 Thread David Seifert
On Mon, 2020-04-13 at 19:17 +0200, Michał Górny wrote:
> Hi,
> 
> One of the goals behind NATTkA was to make keywording/stabilization
> easier.  Right now it's mostly possible to file the most common requests
> without having to copy keywords everywhere.  Still, there's a need to CC
> arches which isn't exactly the most convenient part.
> 
> I was thinking how to make NATTkA help with that.  After considering
> a few options, I'd like to push forward the following proposition: let's
> add a 'CC-ARCHES' keyword to Bugzilla.  If a bug is marked with that
> keyword and passes sanity check, NATTkA will automatically CC all
> relevant arch teams (based on keyword list).
> 
> What do you think?
> 

Yes, and simplifies the workflow a lot!




Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-12 Thread David Seifert
On Sat, 2020-04-11 at 12:53 -0400, Mike Gilbert wrote:
> On Sat, Apr 11, 2020 at 12:28 PM Thomas Deutschmann  wrote:
> > On 2020-04-11 17:33, Michał Górny wrote:
> > > 1. We kill both keywords, and just rely on components, or
> > > 
> > > 2. I make NATTkA automatically add KEYWORDREQ or STABLEREQ where
> > > appropriate.
> > 
> > I think you cannot kill it.
> > 
> > Yes, we have a component for stabilization/keywording, but we also do
> > stabilization from security bugs which don't have such a component and
> > some tools must be able to filter.
> 
> Someone proposed that we change the security bug workflow to include a
> separate stable request bug, which would resolve this.
> 
> That would also help in cases where we are stabilizing
> security-unsupported archs at the same time.
> 

I agree, this sounds like the better solution, and separating concerns.




Re: [gentoo-dev] News item: Deprecation and removal of legacy X11 input drivers.

2020-04-02 Thread David Seifert
On Thu, 2020-04-02 at 00:44 +0200, Piotr Karbowski wrote:
> Title: Deprecation and removal of legacy X11 input drivers.
> Author: Piotr Karbowski 
> Posted: 2020-04-02
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: x11-drivers/xf86-input-mouse
> Display-If-Installed: x11-drivers/xf86-input-keyboard
> 
> The Gentoo X11 Team is announcing the deprecation and future removal of
> the legacy X11 input drivers x11-drivers/xf86-input-mouse and
> x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers
> will be masked for removal.
> 
> These drivers have been deprecated for many years, first by
> xf86-input-evdev and
> then by xf86-input-libinput.
> 
> The only use for those drivers remain in deployments which intentionally
> opt-out of using udev, as both evdev and libinput require udev during
> runtime, however given that upstream has already removed the Linux
> support from xf86-input-keyboard, future X11 releases will no longer
> support xf86-input-keyboard on Linux rendering those installation
> infeasible to use without udev.
> 
> In order to ensure fraction-less upgrade path for future X11 releases,

nice Freudian there ;)

> we have decided to deprecate those drivers that are not in active use by
> pretty much any installation of Gentoo.
> 
> No action is required from end-users who are already using libinput (or
> evdev). To check which driver is in use, one can use
> 
> $ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log
> 
> For the systems running xorg-server as regular user (-suid
> +elogind/+systemd) or by running
> 
> # grep 'Using input driver' /var/log/Xorg.0.log
> 
> for those that still runs xorg-server as root.
> 
> If however neither libinput or evdev is in use, one should append
> 'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf
> and update @world with new USE flags
> 
> # emerge -N @world
> 
> 




Re: [gentoo-dev] [PATCH] cmake.eclass: do not append -DNDEBUG to CPPFLAGS

2020-03-30 Thread David Seifert
On Sun, 2020-03-29 at 21:03 -0400, Mike Gilbert wrote:
> The NDEBUG macro turns the assert() function into a noop. This gives a
> small performance boost, but may allow subtle programming errors to go
> unnoticed.
> 
> This code was added back in 2008, when we started passing
> -DCMAKE_BUILD_TYPE=None instead of Release or Debug. It probably tries
> to mimic a default behavior of Release type builds.
> 
> Other common build systems do not do this by default. For example,
> autoconf's AC_HEADER_ASSERT macro only sets NDEBUG if --disable-assert
> is passed to configure (it defaults to enabled).
> 
> It is better to let users add this to CPPFLAGS themselves if they really
> want to save those few CPU cycles.
> 
> Signed-off-by: Mike Gilbert 
> ---
>  eclass/cmake.eclass | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
> index 160f40b1cf8e..3da3b9aeb555 100644
> --- a/eclass/cmake.eclass
> +++ b/eclass/cmake.eclass
> @@ -371,15 +371,6 @@ cmake_src_configure() {
>   # Fix xdg collision with sandbox
>   xdg_environment_reset
>  
> - # @SEE CMAKE_BUILD_TYPE
> - if [[ ${CMAKE_BUILD_TYPE} = Gentoo ]]; then
> - # Handle release builds
> - if ! in_iuse debug || ! use debug; then
> - local CPPFLAGS=${CPPFLAGS}
> - append-cppflags -DNDEBUG
> - fi
> - fi
> -
>   # Prepare Gentoo override rules (set valid compiler, append CPPFLAGS
> etc.)
>   local build_rules=${BUILD_DIR}/gentoo_rules.cmake
>  

Double ACK. Injecting this flag is imo doing too much and more feature creep
than anything else. This is why we should try and find ways of checking that
CPPFLAGS is respected as a user flag.




Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread David Seifert
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> There are situations in which downstream overlays need to have versions
> of python which Gentoo no longer supports in the tree.
> 
> Currently, the only way to do this is for the overlay author to fork
> python-utils-r1.eclass. This is highly undesirable since it creates a
> very significant maintenance burden for the overlay author.
> 
> There are a couple of things we can do upstream to make this easier, and
> I think we should do one of them.
> 
> The simplest way would be to apply the following patch.
> In this situation, all the overlay author
> would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable.
> 
> The other option would be to move _PYTHON_ALL_IMPLS and  the
> implementation of _python_impl_supported to a separate eclass, e.g.
> python-impls-r1.eclass. This eclass could be forked freely downstream
> without worrying about the other python eclasses.
> I will volunteer to do the legwork for this option if we do not like the
> first one.
> 
> I would advocate the first option however since no one has to fork
> anything.
> 
> Thoughts?
> 
> William
> 
> William Hubbs (1):
>   python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS
> 
>  eclass/python-utils-r1.eclass | 2 ++
>  1 file changed, 2 insertions(+)
> 

How do you prevent some extra clever Gentoo developer from doing the following
in ::gentoo

  dev-python/foo/foo-1.ebuild:

  # don't have the time to port this right now, patches welcome
  PYTHON_COMPAT_ALLOW_EXTRA_IMPLS=( python3_4 )
  PYTHON_COMPAT=( python3_4 )
  inherit distutils-r1

Furthermore, defining PYTHON_COMPAT_ALLOW_EXTRA_IMPLS is going to break metadata
invariance, causing tons of cache mis-hits. How do you prevent that?

In addition, this will very quickly cause whatever overlay this is being used in
to become invalid. Imagine I have dev-python/foo::gentoo that supports python
3.4 and 3.5 and have dev-python/bar::sony supporting 3.4 and 3.5 sitting in a
hypothetical overlay, which depends on dev-python/foo::gentoo. Now we remove
python 3.4 from ::gentoo in python-utils-r1, and one week later we remove
python3.4 from dev-python/foo::gentoo's PYTHON_COMPAT. Now your dev-
python/bar::sony in conjunction with PYTHON_COMPAT_ALLOW_EXTRA_IMPLS has an
invalid depgraph. How do you wish to resolve this?

I feel like keeping up with ::gentoo is ultimately the better strategy than
trying to add backdoors to eclasses because some overlays are somewhat behind.

Regards
David




Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-23 Thread David Seifert
On Mon, 2020-03-23 at 14:00 -0500, William Hubbs wrote:
> On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote:
> > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> > > Hey all,
> > > 
> > > it has been brought to my attention that there have been several
> > > backward-incompatible changes made to the python eclasses lately.
> > > 
> > > It is true that everything in ::gentoo has been fixed along with the
> > > changes to the eclasses; however, when a change like this goes into a
> > > widely used eclass it breaks overlays with little to no notice;
> > > especially since we do not require developers to be subscribed to this
> > > mailing list.
> > > 
> > > I do agree that overlay authors are on their own to fix things, but we
> > > need to
> > > find a way to notify them when a breaking change is going into a widely
> > > used eclass and give them time to adjust their ebuilds.
> > > 
> > > If the old way of doing things cannot be supported
> > > along side the new way the correct path forward is a new version of the
> > > eclass then a lastrites on the old version. That would give overlay
> > > authors time to switch to the new eclass.
> > > 
> > > If the old and new way can be supported in the same code base, a
> > > reasonable way forward is to  allow both ways to exist while ::gentoo is
> > > migrated to the new code path then do the equivalent of a lastrites for
> > > the old code path so overlay authors can adjust their ebuilds.
> > > 
> > > Thoughts?
> > > 
> > > William
> > > 
> > 
> > All of this was announced with a 3 month timeout, using the right channels.
> > Have
> > you checked all python-related eclasses changes submitted to the ML? In this
> > case, eqawarn would not have been possible, because the change involved
> > dereferencing a variable.
> 
> This is the change that broke us today.
> 
> https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258
> 
> Where is the three month timeout for it?
> 
> Thanks,
> 
> William
> 

Oh I thought you meant the python-single-r1 change from a month ago.




Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-23 Thread David Seifert
On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> Hey all,
> 
> it has been brought to my attention that there have been several
> backward-incompatible changes made to the python eclasses lately.
> 
> It is true that everything in ::gentoo has been fixed along with the
> changes to the eclasses; however, when a change like this goes into a
> widely used eclass it breaks overlays with little to no notice;
> especially since we do not require developers to be subscribed to this
> mailing list.
> 
> I do agree that overlay authors are on their own to fix things, but we need to
> find a way to notify them when a breaking change is going into a widely
> used eclass and give them time to adjust their ebuilds.
> 
> If the old way of doing things cannot be supported
> along side the new way the correct path forward is a new version of the
> eclass then a lastrites on the old version. That would give overlay
> authors time to switch to the new eclass.
> 
> If the old and new way can be supported in the same code base, a
> reasonable way forward is to  allow both ways to exist while ::gentoo is
> migrated to the new code path then do the equivalent of a lastrites for
> the old code path so overlay authors can adjust their ebuilds.
> 
> Thoughts?
> 
> William
> 

All of this was announced with a 3 month timeout, using the right channels. Have
you checked all python-related eclasses changes submitted to the ML? In this
case, eqawarn would not have been possible, because the change involved
dereferencing a variable.

Check the git-2 debacle: 6.5 years of deprecation, and still a bunch of overlays
exploded. There comes a point where you just have to suck it up and move on.




Re: [gentoo-dev] [PATCH] fixheadtails.eclass: move sed to BDEPEND for EAPI 7

2020-03-20 Thread David Seifert
On Fri, 2020-03-20 at 14:19 -0400, David Michael wrote:
> It executes sed at build time, so it should be installed in /.
> 
> Signed-off-by: David Michael 
> ---
> 
> Hi,
> 
> Here is another simple dependency move to put a required program in the
> correct ROOT so it can be executed during the build.  It's basically the
> same as 814ab1294edf3565fc02fe63d15d6fa7ca886429.
> 
> Thanks.
> 
> David
> 
>  eclass/fixheadtails.eclass | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/fixheadtails.eclass b/eclass/fixheadtails.eclass
> index c19d33924aa..5d221ca678c 100644
> --- a/eclass/fixheadtails.eclass
> +++ b/eclass/fixheadtails.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2020 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: fixheadtails.eclass
> @@ -8,7 +8,10 @@
>  # Original author John Mylchreest 
>  # @BLURB: functions to replace obsolete head/tail with POSIX compliant ones
>  
> -DEPEND=">=sys-apps/sed-4"
> +case "${EAPI:-0}" in
> + [0-6]) DEPEND=">=sys-apps/sed-4" ;;
> + *) BDEPEND=">=sys-apps/sed-4" ;;
> +esac
>  
>  _do_sed_fix() {
>   einfo " - fixed $1"

This is an ancient dependency, just kill it altogether.




[gentoo-dev] Last rites: x11-libs/gtkglarea and media-sound/galan

2020-03-20 Thread David Seifert
# David Seifert  (2020-03-20)
# Last release in 2014, unsupported, EOL.
# Include the last remaining revdep, which was last updated in 2004.
x11-libs/gtkglarea
media-sound/galan


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


Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread David Seifert
On Thu, 2020-03-19 at 14:57 +1300, Kent Fredric wrote:
> On Wed, 18 Mar 2020 11:59:25 -0500
> William Hubbs  wrote:
> 
> >  Sure, but if you run into something like that you just don't use the
> >  noarch keyword for those packages.
> 
> But as soon as this happens, all dependent packages that are noarch
> will need to also transition to not using no-arch.
> 
> So it turns into a lot of busywork without benefit.

Second this, it doesn't sound well though out at this point.




Re: [gentoo-dev] Last rites: dev-python/*, python-maintained, py3.6-only, no-revdep

2020-03-08 Thread David Seifert
On Sat, 2020-03-07 at 22:22 +0100, Ulrich Mueller wrote:
> > > > > > On Sat, 07 Mar 2020, Michał Górny wrote:
> > Surely, you can claim we could just drop them to maintainer-needed.
> > What problem does that solve?  The package would still miss 3.7 support.
> > Users will still suffer when we switch the default (if they have any
> > users, that is).  We would still have to last rite them when 3.6 is
> > gone.  What's the gain?
> > Right, let's talk about m-needed.  Over 2000 packages already and still
> > growing.  What message does *that* send to the users?
> 
> Sorry, but where have I suggested to drop these packages to m-n?
> 
> > How about the following message: the difference between Gentoo
> > and Debian stable is that Gentoo doesn't have the 'b'.
> > Finally, what message does it send to our users when developers keep
> > picking up fights like this?  You seem to disagree with my work
> > on Gentoo, and the only solution you can come up is publicly shaming me?
> > This isn't 'let's discuss a better solution' kind of mail, this is
> > 'justify yourself before me, you puny developer, how dare you do things
> > I don't like'.
> 
> This is neither a fight nor a personal issue. Also, please don't put
> words in my mouth that I haven't said and never intended to say.
> 
> Ulrich

In general, I don't the see the point of this thread. Python requires explicit
implementation enabling, and unless you're willing to help test py3.7 on py3.6-
only packages, complaining about masking packages gets us absolutely nowhere.
Propose actual solutions and step in to help and bump packages. Walk the walk,
don't just talk the talk.




Re: [gentoo-dev] Package up for grab: app-crypt/scute

2020-02-29 Thread David Seifert
On Sat, 2020-02-29 at 08:53 +0200, Joonas Niilola wrote:
> app-crypt/scute up for grabs due to retirement of a proxy-maintainer. One bug
> open requesting a version bump. 
> 
> 
> 
> -- juippis

I'll take this.




[gentoo-dev] Last rites: games-strategy/boswars

2020-02-23 Thread David Seifert
# David Seifert  (2020-02-23)
# Last release in 2013, the scons SConstruct script uses variables
# that have been removed from Scons years ago and also uses a ton of
# Python 2-only patterns, sed broken. Bug #703906, #710342.
# Masked for removal in 30 days.
games-strategy/boswars


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


[gentoo-dev] Last rites: app-vim/cream

2020-02-11 Thread David Seifert
# David Seifert  (2020-02-11)
# Unmaintained, EAPI 4, last release over 9 years ago, no revdeps.
# Removal in 30 days.
app-vim/cream


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


[gentoo-dev] Last rites: net-im/coccinella

2020-02-11 Thread David Seifert
# David Seifert  (2020-02-11)
# Unmaintained, EAPI 4, last release over 9 years ago, ebuild has QA
# issues, no revdeps.  Removal in 30 days.  Bug #558354.
net-im/coccinella


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


[gentoo-dev] Last rites: dev-lang/rebol{,-bin}

2020-02-10 Thread David Seifert
# David Seifert  (2020-02-10)
# Unmaintained, only live ebuild, doesn't build, last release over 7
# years ago, EAPI 4. Removal in 15 days. Bug #593008.
dev-lang/rebol
dev-lang/rebol-bin


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


[gentoo-dev] Last rites: epunt-cxx.eclass

2020-02-10 Thread David Seifert
# No consumers, this eclass is not useful anymore, as a functioning
# C++ compiler is required nowadays.  Removal in 15 days.
epunt-cxx.eclass


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


[gentoo-dev] Last rites: sys-apps/hbaapi

2020-02-09 Thread David Seifert
# David Seifert  (2020-02-10)
# Unmaintained, EAPI 4, doesn't respect CFLAGS and LDFLAGS, which masks
# undefined symbols in the shared object, upstream gone, no other
distro
# packages this anymore, no revdeps. Removal in 30 days.
sys-apps/hbaapi


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


Re: [gentoo-dev] Last rites: dev-python/epydoc

2020-01-30 Thread David Seifert
On Thu, 2020-01-30 at 06:18 +0100, David Haller wrote:
> Michal, ...
> 
> On Wed, 29 Jan 2020, Michal Górny wrote:
> > # Michal Górny  (2020-01-29)
> > # Abandoned in 2009.  Python 2 only.  No blockers left.
> > # Removal in 30 days.  Bug #706218.
> > dev-python/epydoc
> 
> ... I think you're getting a liiittle bit trigger happy there ...
> 
> # equery d dev-python/epydoc
>  * These packages depend on dev-python/epydoc:
> sys-apps/portage-2.3.86 (python_targets_python2_7 ? >=dev-
> python/epydoc-2.0[python_targets_python2_7(-)?,-
> python_single_target_python2_7(-)])
> 
> 
> $ cd /usr/portage/sys-apps/portage
> $ grep epydoc portage-2.3.86.ebuild
> IUSE="build doc epydoc gentoo-dev +ipc +native-extensions +rsync-
> verify selinux xattr"
> epydoc? (
> >=dev-python/epydoc-2.0[${PYTHON_USEDEP}]
> REQUIRED_USE="epydoc? ( $(python_gen_useflags 'python2*') )"
> use epydoc && DISTUTILS_ALL_SUBPHASE_IMPLS=( python2.7 )
> use epydoc && targets+=( epydoc )
> use epydoc && targets+=(
> install_epydoc
> 
> 
> ... and thats the fricking bleeding edge unstable portage, mind!
> Stable 2.3.84-r1 looks almost identical when grepped ...
> 
> BTW: has it been taken note of that (at least ESR) Mozillen like
> firefox still use python2.7 for quite a bit in the build process?
> 
> -dnh
> 

Portage is working on replacing their documentation with sphinx. Is a
missing USE="doc" breaking your system?




Re: [gentoo-dev] Last rites: virtual/cargo

2020-01-27 Thread David Seifert
On Sun, 2020-01-26 at 21:53 -0500, Michael Orlitzky wrote:
> On 1/26/20 9:46 PM, Georgy Yakovlev wrote:
> > # update your rust packages running emerge with the
> > # --changed-deps option if you have problems
> 
> If this advice helps, you have violated the PMS.
> 

Agreed, if possible revbump any critical ebuilds, so we can avoid the
virtual/pam disaster this time round.




[gentoo-dev] Last rites: sci-libs/pymmlib

2020-01-26 Thread David Seifert
# David Seifert  (2020-01-27)
# Unmaintained, py2 only, depends on dead dev-python/pygtkglext, last
release
# over 8 years ago, no sign of py3 port. Removal in 30 days.
sci-libs/pymmlib


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


[gentoo-dev] Last rites: media-gfx/pycam

2020-01-26 Thread David Seifert
# David Seifert  (2020-01-27)
# Unmaintained, py2 only, depends on dead dev-python/pygtkglext and
# dev-python/librsvg-python, no revdeps.
# Removal in 30 days.  Bug #640074.
media-gfx/pycam


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


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

2020-01-26 Thread David Seifert
# David Seifert  (2020-01-26)
# Unmaintained, last release 14 years ago, tons of patches,
# Autoconf script is broken, fails with gettext-0.20.
# Removal in 30 days.  Bug #578234, #685928.
app-i18n/zhcon


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


[gentoo-dev] Last rites: media-libs/adplug and media-sound/adplay

2020-01-25 Thread David Seifert
# David Seifert  (2020-01-25)
# Upstream is mostly unresponsive and doesn't have the resources to
# fix their code. Lots of bugs in the form of big endian issues, buffer
# overflows, heap overflows, memory leaks and missing sanity checks.
# Includes libbinio, which is only used by adplug and in a similarly
# poor state. Multiple open CVEs.
# Removal in 30 days. Bug #667170, #706346.
media-libs/adplug
dev-cpp/libbinio
media-sound/adplay


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


[gentoo-dev] Last rites: games-strategy/gwp

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# Upstream disappeared, no other distro still carries this,
# blocks removal of EOL gtkglext, no revdeps.
# Removal in 30 days.
games-strategy/gwp


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


[gentoo-dev] Last rites: games-strategy/ufoai

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# Blocks removal of EOL gtkglext, no revdeps.
# Removal in 30 days.
games-strategy/ufoai


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


[gentoo-dev] Last rites: media-sound/glmix

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# Last release over 13 years ago, depends on EOL gtkglext.
# No revdeps, Removal in 30 days.
media-sound/glmix


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


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

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# All released versions depend on EOL gtkglext, no revdeps.
# Bug #644334, #694834. Removal in 30 days.
sci-astronomy/celestia


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


[gentoo-dev] Last rites: sci-chemistry/gabedit

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# Last release over 2 years ago, depends on EOL gtkglext.
# No revdeps, Removal in 30 days.
sci-chemistry/gabedit


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


[gentoo-dev] Last rites: sci-chemistry/ghemical

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# Last release over 13 years ago, depends on EOL gtkglext, no revdeps.
# Bug #353119, #435676. Removal in 30 days.
sci-chemistry/ghemical


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


[gentoo-dev] Last rites: sci-physics/lightspeed

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# Last release over 18 years ago, depends on EOL gtkglext.
# No revdeps, Removal in 30 days.
sci-physics/lightspeed


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


[gentoo-dev] Last rites: sci-visualization/gfsview

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# Last release over 7 years ago, depends on EOL gtkglext.
# No revdeps, Removal in 30 days.
sci-visualization/gfsview


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


[gentoo-dev] Last rites: sci-visualization/gwyddion

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# No sign of py3 port, depends on EOL pygtk and gtkglext.
# Many open bugs, no revdeps.
# Bug #443088, #582454, #598682, #623314. Removal in 30 days.
sci-visualization/gwyddion


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


[gentoo-dev] Last rites: app-misc/gourmet and dependency

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# No sign of py3 port, depends on EOL pygtk. No revdeps.
# Bug #706030. Removal in 30 days.
app-misc/gourmet
dev-python/python-poppler


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


[gentoo-dev] Last rites: app-text/sary

2020-01-21 Thread David Seifert
# David Seifert  (2020-01-21)
# EAPI 4, last release in 2005, doesn't build, no revdeps.
# Bug #664498. Removal in 30 days.
app-text/sary




Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

2020-01-20 Thread David Seifert
On Mon, 2020-01-20 at 09:20 -0500, Michael Orlitzky wrote:
> On 1/20/20 2:02 AM, Ulrich Mueller wrote:
> > > > > > > On Mon, 20 Jan 2020, Michael Orlitzky wrote:
> > >   install-qa-check.d: allow acct-user home directories under
> > > /home.
> > 
> > Nope. As you've been told, /home is site specific and can be setup
> > in
> > multiple ways that are incompatible with the package manager
> > installing
> > things there (the only exception being baselayout creating the
> > directory
> > itself).
> 
> I haven't been given a single technical reason why using /home would
> cause a problem. What specific incompatibilities are you talking
> about?
> 
> 
> > Quoting FHS-3.0 again:
> > 
> > > On large systems (especially when the /home directories are
> > > shared
> > > amongst many hosts using NFS) it is useful to subdivide user home
> > > directories. Subdivision may be accomplished by using
> > > subdirectories
> > > such as /home/staff, /home/guests, /home/students, etc.
> > 
> > So, how are you going to detect if such a scheme is used on the
> > system,
> > and in which subdirectory the amavis user should be placed?
> 
> The same way we detect that scheme before setting a home directory to
> /var/lib/whatever, which you may notice, is not under /home/guests or
> anything like that. Does this cause a real technical problem, or is
> it
> just more FUD?

Rich has given reasons, ulm has, and mgorny suggested a solution.

> 
> > I also wonder why you would send this patch, when there wasn't a
> > single
> > voice supporting your proposition in the other thread and several
> > opposing ones.
> 
> I don't want to just complain without offering a solution.
> 
> No one has pointed out any problems with it.

Multiple people have pointed out issues with it in the last thread. In
fact, noone has said "great, go ahead".

> 
> This stuff is already in /home, and I'd like to get off user.eclass
> without introducing a new QA warning for a keepdir file.
> 




Re: [gentoo-dev] Last rites: net-im/silc-toolkit

2020-01-18 Thread David Seifert
On Sat, 2020-01-18 at 23:48 +, Michael 'veremitz' Everitt wrote:
> On 18/01/20 22:12, David Seifert wrote:
> > # David Seifert  (2020-01-18)
> > # Leftover from silc* removal (#522916), unmaintained, no
> > # upstream releases since 2014, no revdeps, EAPI-4.
> > # Bug #705462. Removal in 14 days.
> > net-im/silc-toolkit
> > 
> > 
> Looks like you missed:
> https://archives.gentoo.org/gentoo-dev/message/16247cdab4e597a5530eaec8b1229a62
> 
> Yw.
> 
Looks like you missed:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dfe1c280e312416b3856057ccd6c9f88bcaa1c88

Yw.












[gentoo-dev] Last rites: net-im/silc-toolkit

2020-01-18 Thread David Seifert
# David Seifert  (2020-01-18)
# Leftover from silc* removal (#522916), unmaintained, no
# upstream releases since 2014, no revdeps, EAPI-4.
# Bug #705462. Removal in 14 days.
net-im/silc-toolkit




[gentoo-dev] Last rites: net-ftp/oftpd

2020-01-18 Thread David Seifert
# David Seifert  (2020-01-18)
# EAPI 4, last release in 2004, ebuild has QA and licensing issues.
# Bug #426028, #454116. Removal in 30 days.
net-ftp/oftpd




[gentoo-dev] Last rites: net-dns/validns

2020-01-18 Thread David Seifert
# David Seifert  (2020-01-18)
# EAPI 4, doesn't build against OpenSSL 1.1 API, last release in 2014,
# lots of QA issues (calls cc directly, -Werror)
# Bug #634442, #664766. Removal in 30 days.
net-dns/validns




[gentoo-dev] Last rites: net-analyzer/pchar

2020-01-18 Thread David Seifert
# David Seifert  (2020-01-18)
# EAPI 4, doesn't build, last release in 2005.
# Bug #384031, #638492, #663644. Removal in 30 days.
net-analyzer/pchar




Re: [gentoo-dev] RFC: Dropping alpha keywords to unstable

2020-01-16 Thread David Seifert
On Wed, 2020-01-15 at 21:47 -0800, Matt Turner wrote:
> Hello,
> 
> It makes me a bit sad to say, having helped maintain Gentoo's DEC
> Alpha
> port for more than 10 years, that I think it is time to drop our
> stable
> keywords to ~alpha.
> 
> Stable testing is a valuable service we provide to users. Time
> invested
> by developers during stabilization has the potential to pay dividends
> to
> users multiple times over.
> 
> But the presumption in that statement is that the number of users
> meaningfully greater than the number of developers. I no longer
> believe
> this is the case for Alpha.
> 
> As a result, I don't think it's a good use of my time to perform
> stable
> testing on alpha.
> 
> I plan to keep the profiles "stable" (meaning no depgraph breakages)
> but
> to change to ACCEPT_KEYWORDS="~alpha".
> 
> Thoughts?
> 
> Matt

Thanks Matt, this will also help developers in cleaning up their
packages. I highly support this move.




Re: [gentoo-dev] unsanctioned python 2.7 crusade

2020-01-12 Thread David Seifert
On Sun, 2020-01-12 at 17:55 -0500, Joshua Kinard wrote:
> On 1/12/2020 17:46, David Seifert wrote:
> > On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote:
> > > On 1/12/2020 17:32, Andreas Sturmlechner wrote:
> > > > On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote:
> > > > > It might be worthwhile to treat the removal of Python-2.7
> > > > > from
> > > > > the tree in
> > > > > the same manner as an EAPI deprecation and removal, given how
> > > > > ingrained it
> > > > > is due to its longevity.  That will minimize the whiplash-
> > > > > effect
> > > > > of emerge
> > > > > complaining about slot conflicts and dependency
> > > > > conflicts.  Like
> > > > > I just ran
> > > > > into w/ setuptools-45.0.0.0's release.
> > > > 
> > > > So, no packaging of >=setuptools-45.0.0 until the end of 2020?
> > > > Do
> > > > you want to 
> > > > freeze all python libs that upstreams are dropping py27 support
> > > > from?
> > > > 
> > > 
> > > Not saying not to package it.  Right now, the issue seems to be
> > > it
> > > causes
> > > dependency conflicts in emerge's depgraph parsing when
> > > PYTHON_TARGETS
> > > includes python2_7 support.  Remove that and stick with python3_*
> > > only, then
> > > other packages that need python2_7 will whine.
> > > 
> > > Did setuptools-45.0.0 remove all python2 support?  I looked at
> > > the
> > > commit
> > > log, and it's only the title that any meaningful hint that it may
> > > have,
> > > "dev-python/setuptools: Bump to 45.0.0 (py3 only)".  If it did,
> > > then
> > > that
> > > change is the right change, but anyone with a userland that has a
> > > mix
> > > of
> > > python2 and python3 is going to have difficulty getting that
> > > update
> > > to merge
> > > in, so I really can't go higher than setuptools-44.0.0 for the
> > > time
> > > being.
> > > 
> > 
> > https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0
> 
> At least you didn't squirrel that behind a lmgtfy link 
> 
> In any event, it's clear the tree does not seem set up real well to
> handle
> the random removal or deprecation of python2 support.  And
> considering
> python2.7 isn't dead //yet//, I have to question the wisdom of
> removing
> packages that still support 2.7, and also wonder if there's a way to
> be more
> graceful in handling updates to packages whose upstream decides to
> remove
> python2 support.
> 
> Or we can just continue down the current Mad Max methodology and
> leave it to
> every developer for themselves.
> 

Or - you know - you could help? Talk is cheap, gracefully removing py2
from the tree is the hard part. A quick grep tells me we have 4388
ebuilds in the tree with python_targets_python2_7 in IUSE. Have fun
devising a plan (and then doing the actual work). Pro-tip: "Don't
remove py2" is not an actual plan when many important core dependencies
have started removing py2 already.




Re: [gentoo-dev] unsanctioned python 2.7 crusade

2020-01-12 Thread David Seifert
On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote:
> On 1/12/2020 17:32, Andreas Sturmlechner wrote:
> > On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote:
> > > It might be worthwhile to treat the removal of Python-2.7 from
> > > the tree in
> > > the same manner as an EAPI deprecation and removal, given how
> > > ingrained it
> > > is due to its longevity.  That will minimize the whiplash-effect
> > > of emerge
> > > complaining about slot conflicts and dependency conflicts.  Like
> > > I just ran
> > > into w/ setuptools-45.0.0.0's release.
> > 
> > So, no packaging of >=setuptools-45.0.0 until the end of 2020? Do
> > you want to 
> > freeze all python libs that upstreams are dropping py27 support
> > from?
> > 
> 
> Not saying not to package it.  Right now, the issue seems to be it
> causes
> dependency conflicts in emerge's depgraph parsing when PYTHON_TARGETS
> includes python2_7 support.  Remove that and stick with python3_*
> only, then
> other packages that need python2_7 will whine.
> 
> Did setuptools-45.0.0 remove all python2 support?  I looked at the
> commit
> log, and it's only the title that any meaningful hint that it may
> have,
> "dev-python/setuptools: Bump to 45.0.0 (py3 only)".  If it did, then
> that
> change is the right change, but anyone with a userland that has a mix
> of
> python2 and python3 is going to have difficulty getting that update
> to merge
> in, so I really can't go higher than setuptools-44.0.0 for the time
> being.
> 

https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0




Re: [gentoo-dev] unsanctioned python 2.7 crusade

2020-01-12 Thread David Seifert
On Sun, 2020-01-12 at 17:07 -0500, Joshua Kinard wrote:
> On 12/5/2019 09:24, Rich Freeman wrote:
> > On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld  > > wrote:
> > > It's quite another to mask random packages that have USE flags to
> > > optionally support whatever python 2.7 library. If you're going
> > > to
> > > last rites these, talk with the maintainer first, and only then,
> > > send
> > > emails one at a time. Doing that en masse isn't appropriate.
> > 
> > ++ - I have no idea if that happened.  For anything USE-controlled
> > it
> > would make more sense to file a bug or mask the package-flag combo
> > itself.
> > 
> > > On another topic, I'd prefer for python 2.7 not to be removed
> > > from
> > > gentoo. Tons of code still uses it.
> > > 
> > 
> > I'm sure a million people would share that preference.  I'm not
> > sure
> > what the upstream/security status is of 2.7.  Obviously to keep it
> > around it would need to be reasonably secure, and somebody within
> > Gentoo would have to want to maintain it.  That's basically the
> > criteria for keeping anything like this around.  If somebody
> > stepped
> > up and said "I'm maintaining 2.7 and here is why it will remain
> > secure..." I doubt they'd get a lot of resistance.
> > 
> 
> I'm late to the party as usual.  Seems upstream plans a final 2.7.18
> security update in April of 2020, then they will consider the 2.7
> branch
> EOL.  They say most of these updates were done in 2019, and so are
> still
> technically sticking to their mantra of no more updates after
> 01/01/2020.
> 
> PEP 373 covers this:
> https://www.python.org/dev/peps/pep-0373/#release-schedule
> 
> """
> Planned future release dates:
> 
> 2.7.18 code freeze January, 2020
> 2.7.18 release candidate early April, 2020
> 2.7.18 mid-April, 2020
> """
> 
> IMHO, I think we should retain 2.7.x compatibility for 1 year AFTER
> the
> release of 2.7.18.  This provides some time for people to transition
> systems
> off of 2.7-dependent packages.
> 
> It might be worthwhile to treat the removal of Python-2.7 from the
> tree in
> the same manner as an EAPI deprecation and removal, given how
> ingrained it
> is due to its longevity.  That will minimize the whiplash-effect of
> emerge
> complaining about slot conflicts and dependency conflicts.  Like I
> just ran
> into w/ setuptools-45.0.0.0's release.
> 

Thanks for volunteering to help us manage the ton of packages that have
dropped py2 in the mean time. I wasn't aware you were part of the
python team, but I must have been mistaken!




Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies

2020-01-03 Thread David Seifert
On Thu, 2020-01-02 at 21:54 +, Michael 'veremitz' Everitt wrote:
> On 02/01/20 21:08, Michał Górny wrote:
> > On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote:
> > > > > > > > On Thu, 02 Jan 2020, Michał Górny wrote:
> > > > --- a/eclass/ruby-ng.eclass
> > > > +++ b/eclass/ruby-ng.eclass
> > > > @@ -137,7 +137,7 @@ ruby_samelib() {
> > > > local res=
> > > > for _ruby_implementation in $(_ruby_get_all_impls); do
> > > > has -${_ruby_implementation} $@ || \
> > > > -   res="${res}ruby_targets_${_ruby_impleme
> > > > ntation}?,"
> > > > +   res="${res}ruby_targets_${_ruby_impleme
> > > > ntation}(-)?,"
> > > > done
> > > >  
> > > > echo "[${res%,}]"
> > > Hadn't we established that ruby_samelib() is dead code, no longer
> > > used
> > > since 2010?
> > > 
> > You did.  However, it isn't marked as private API and I'm not the
> > eclass
> > maintainer to take care of removing public API.  I have no clue if
> > Ruby
> > project doesn't have some secret overlays using it.
> > 
>  You can't use QA super-powerz ?! BDFL + sub-BDFL ?!
> *
> 
> * Thought the tags probably worth making explicit
> 

Can you please stop polluting the -dev mailing list with this senseless
chatter?




Re: [gentoo-dev] [PATCH] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies

2019-12-31 Thread David Seifert
On Tue, 2019-12-31 at 05:34 +0100, Michał Górny wrote:
> Using 2-style USE dependencies on packages not having the flag
> in question is forbidden by PMS.
> 
> Signed-off-by: Michał Górny 
> ---
>  eclass/ruby-ng.eclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
> index db701d81f4fc..c2b9442ef489 100644
> --- a/eclass/ruby-ng.eclass
> +++ b/eclass/ruby-ng.eclass
> @@ -137,7 +137,7 @@ ruby_samelib() {
>   local res=
>   for _ruby_implementation in $(_ruby_get_all_impls); do
>   has -${_ruby_implementation} $@ || \
> - res="${res}ruby_targets_${_ruby_implementation}
> ?,"
> + res="${res}ruby_targets_${_ruby_implementation}
> ?(-),"

https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-830008.3.4
In a 4-style use dependency, the flag name may *immediately* be
followed by a default specified by either (+) or (-)

https://github.com/gentoo-mirror/gentoo/blob/stable/metadata/md5-cache/dev-libs/boost-1.72.0
>=dev-python/numpy-1.17[python_targets_python3_6(-)?,...]

Given that you ran this through CI, this smells of dead code...

>   done
>  
>   echo "[${res%,}]"
> @@ -151,9 +151,9 @@ _ruby_atoms_samelib_generic() {
>   "||" | "(" | ")" | *"?")
>   echo "${token}" ;;
>   *])
> - echo
> "${token%[*}[RUBYTARGET,${token/*[}" ;;
> + echo "${token%[*}[RUBYTARGET(-
> ),${token/*[}" ;;
>   *)
> - echo "${token}[RUBYTARGET]" ;;
> + echo "${token}[RUBYTARGET(-)]" ;;
>   esac
>   done
>   echo ")"




[gentoo-dev] Last rites: games-rpg/dragonhunt, games-puzzle/jools, games-puzzle/hexamine, games-puzzle/4stattack, games-arcade/watermelons, games-arcade/triplexinvaders, games-arcade/pydance, games-ar

2019-12-25 Thread David Seifert
# David Seifert  (2019-12-25)
# Py2 only, dead upstream, no py3 port in sight.
# Removal in 30 days.  Bug #703792.
games-rpg/dragonhunt
games-puzzle/jools
games-puzzle/hexamine
games-puzzle/4stattack
games-arcade/watermelons
games-arcade/triplexinvaders
games-arcade/pydance
games-arcade/pydance-songs
games-arcade/pycadia
games-arcade/bub-n-bros
games-action/accelerator3d
games-kids/tuxmathscrabble


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


[gentoo-dev] Last rites: x11-terms/multi-aterm

2019-12-24 Thread David Seifert
# David Seifert  (2019-12-24)
# Unmaintained, uses dead POSIX streams interface, EAPI 4.
# Bug #692228, Removal in 30 days.
x11-terms/multi-aterm




[gentoo-dev] Last rites: sci-libs/jmol-acme, sci-libs/libcore, sci-libs/naga, sci-libs/spooles, sci-libs/vecmath-objectclub

2019-12-22 Thread David Seifert
# David Seifert  (2019-12-22)
# Unmaintained, dead upstreams, monstrous build systems.
# Bug #568364, Removal in 30 days.
sci-libs/jmol-acme
sci-libs/libcore
sci-libs/naga
sci-libs/spooles
sci-libs/vecmath-objectclub




Re: [gentoo-dev] [RFC] New eclass patches.eclass

2019-12-22 Thread David Seifert
On Sun, 2019-12-22 at 16:39 +0700, Vadim A. Misbakh-Soloviov wrote:
> HI there!
> 
> Some time ago I invented patches.eclass, which facilitates my work
> with 
> patches, and I would like you to express your opinion about it and
> whether it 
> is worth committing in gentoo repo.
> 
> Maybe it’s even worth it to become a helper, but not an eclass, or be
> bundled 
> somewhere in existing eclasses/helpers.
> 

It seems your eclass is truncated.

Anyhow, this eclass contains too much implicit magic, so we won't be
able to include it in the tree.




  1   2   3   >