[gentoo-dev] Last rites: media-gfx/videorbits
# 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
# 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
# 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
# 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
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
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
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
# 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
# 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?
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?
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?
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?
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
# 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
# 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
# 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
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
# 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
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
# @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
# 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
# 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
# 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
# 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
# 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}
# 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
# 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()
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()
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
# 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-*
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
# 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
# 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
# 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
# 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
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
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
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
# 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
# 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
# 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}
# 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
# 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
# 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
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
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
# 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
# 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
# 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
# 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
# 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
# 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
# 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
# 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
# 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
# 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
# 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
# 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
# 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
# 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
# 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
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
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
# 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
# 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
# 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
# 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
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
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
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
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
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
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
# 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
# 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
# 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
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.
