[gentoo-dev] [PATCH 15/44] multibuild.eclass: add global-scope ewarn for deprecated < EAPI 7

Signed-off-by: Sam James --- eclass/multibuild.eclass | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/eclass/multibuild.eclass b/eclass/multibuild.eclass index f15d3327c7dd2..0677ea346e4ce 100644 --- a/eclass/multibuild.eclass +++ b/eclass/multibuild.eclass

Re: [gentoo-dev] Packages up for grabs

Hi, > On 14 Apr 2020, at 09:36, Joonas Niilola wrote: > > net-irc/ngircd (b,v) Quite happy to take this on. I’ll do a bump with GLEP 81 in there, provided nobody else is interested in this. Sam

[gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-proxy/mitmproxy

I’ll try look at this. > On 19 Apr 2020, at 21:05, Michał Górny wrote: > > # Michał Górny (2020-04-19) > # Unmaintained. Stuck on Python 3.6. Needs version bump. > # Removal in 30 days. Bug #718458. > net-proxy/mitmproxy > > -- > Best regards, > Michał Górny >

Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)

> On 2 May 2020, at 21:30, Andreas K. Hüttel wrote: > > Hey all, > > our installation handbook is right now something of a mess (in particular > regarding partitioning, bootloader, gpt/uefi, ...) > > I'm hereby volunteering to clean things up. But - I'll go the brutal way: > > * Legacy boo

Re: [gentoo-dev] Last rites: media-video/subliminal

> On 2 May 2020, at 11:12, Nikos Chantziaras wrote: > > On 19/04/2020 22:47, Michał Górny wrote: >> # Michał Górny (2020-04-19) >> # Unmaintained. Stuck on Python 3.6. Last release in 2016. >> # Removal in 30 days. Bug #718410. >> media-video/subliminal > > It's an active project. Just not

Re: [gentoo-dev] Gentoo clang team

> On 12 May 2020, at 14:48, Alexander Bilyak wrote: > > Hello everyone in this mailing list. > > I apologize for myself as I am not sure if it is the right place to write, > but anyway... > I am the (only) maintainer of gentoo-clang > overlay. > Recen

Re: [gentoo-dev] Packages up for grabs

> On 26 May 2020, at 23:12, Andrey Utkin wrote: > > I have transitioned to "away" state as I have to reclaim my time for other > uses. Here I am trying to reduce the scope of my Gentoo responsibilities to > make potential return to activity less dreadful and overwhelming. Nothing wrong with re

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

> On 8 Jun 2020, at 00:22, Philip Webb wrote: > > 200607 Pacho Ramos wrote: >> I think this is the list of completely unmaintained packages now, >> indeed most of them, around 100. > > -- extract from list -- > >> media-gfx/imagemagick : 200516 >> media-libs/giflib : 200312 >> media-libs/lib

Re: [gentoo-dev] glsa-check: missing CVE-2020-6509 for current stable chromium version

> On 23 Jun 2020, at 21:57, Samuel Bernardo > wrote: > > Hi, > > Sorry if I miss any detail about glsa-check context, but I think that it > misses the CVE[1] id review I left in subject. > A GLSA (see https://security.gentoo.org/glsa ) has not yet been file

Re: [gentoo-dev] Last rites: */* More Py2 only items

> On 29 Jun 2020, at 01:35, Aaron Bauman wrote: > > # Aaron Bauman (2020-06-28) > # More Py2 only stuff. Plz see -dev ML for discussions > # Remove bindings, port to Py3, etc > > net-irc/irker > Upstream seem to be about to release 2.19 which includes several patches for Python 3 compatibili

[gentoo-dev] Last rites: net-irc/ptlink-ircd, net-irc/ptlink-opm

# Sam James (2020-08-30) # Collection of quite dead net-irc/* pkgs # Please speak up if you use any of these # and a modern alternative doesn't work for you. # None of these have alive upstreams, and we're # the only distro packaging them in many cases. # Unmaintained. Removal in 30 d

[gentoo-dev] Last rites: net-irc/irc-server

# Sam James (2020-08-30) # Collection of quite dead net-irc/* pkgs # Please speak up if you use any of these # and a modern alternative doesn't work for you. # None of these have alive upstreams, and we're # the only distro packaging them in many cases. # Unmaintained. Removal in 30 d

[gentoo-dev] Last rites: dev-db/sqliteodbc

# Sam James (2020-08-30) # Serious security bug, unmaintained. # Stuck on long-obsolete EAPI 4. # Several open bugs. # bug 720732, bug 729714, bug 722644, # bug 724184. dev-db/sqliteodbc signature.asc Description: Message signed with OpenPGP

[gentoo-dev] Last rites: www-apps/ampache

# Sam James (2020-08-30) # Serious security vulns, outdated. # bug 699834. Removal in 30 days. www-apps/ampache signature.asc Description: Message signed with OpenPGP

[gentoo-dev] Last rites: net-irc/xaric

# Sam James (2020-08-30) # Collection of quite dead net-irc/* pkgs # Please speak up if you use any of these # and a modern alternative doesn't work for you. # None of these have alive upstreams, and we're # the only distro packaging them in many cases. # Unmaintained. Removal

[gentoo-dev] Last rites: net-irc/nebula

This one is stuck on EAPI 4 and we’re the only ones packaging it. Dead upstream. # Sam James (2020-08-30) # Collection of quite dead net-irc/* pkgs # Please speak up if you use any of these # and a modern alternative doesn't work for you. # None of these have alive upstreams, and we

Re: [gentoo-dev] Please port your packages to Python 3.8

> On 1 Sep 2020, at 12:02, Michał Górny wrote: > > Hello, > > [snip] > Python 3.8 is planned to become the default on 2020-12-01. > Note that this means we need to keep in mind stabilisation of Python 3.8+ supporting-packages going forward. Please request stabilisation of your Python 3.8+

[gentoo-dev] Last rites: dev-tex/biblatex-apa

# Sam James (2020-09-12) # Merged into dev-texlive/texlive-bibtexextra # Removal in 30 days dev-tex/biblatex-apa signature.asc Description: Message signed with OpenPGP

[gentoo-dev] Last rites: dev-tex/chktex

# Sam James (2020-09-12) # Merged into app-text/texlive-core # Removal in 30 days dev-tex/chktex signature.asc Description: Message signed with OpenPGP

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

# Sam James (2020-09-13) # Dead upstream, EAPI 4, no maintainer # Removal in 30 days # bug #740954 dev-lang/cll1h signature.asc Description: Message signed with OpenPGP

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

# Sam James (2020-09-13) # Dead upstream, EAPI 4, no maintainer # Removal in 30 days net-dialup/tkvoice signature.asc Description: Message signed with OpenPGP

[gentoo-dev] Last rites: sys-fs/ufsutils

# Sam James (2020-09-15) # No longer exists upstream, stuck on long-obsolete EAPI 4, # and fails to build with glibc-2.32. # Vestige of Gentoo/FreeBSD. # bug #715506, #737892, #740916, #547244. sys-fs/ufsutils signature.asc Description: Message signed with OpenPGP

[gentoo-dev] Last rites: app-admin/recursos

# Sam James (2020-09-16) # Stuck on EAPI 4, only source is mirror://gentoo, # unmaintained, HOMEPAGE gone. app-admin/recursos signature.asc Description: Message signed with OpenPGP

Re: [gentoo-dev] RFC: GID assignment for gamemode

> On 20 Sep 2020, at 18:40, Kai Krakow wrote: > > Supersedes: > https://archives.gentoo.org/gentoo-dev/message/06a2f464c836a0f8d9dd1d48963aefb1 > > > > I would like to reserve GID 37 for games-util/gamemode. >

Re: [gentoo-dev] OSL 1.11.8.0 ebuild

Hi, Can you submit this on Bugzilla and/or via a GitHub pullrequest? Thanks! > On 9 Oct 2020, at 19:31, Luke A. Guest wrote: > > Hi, > > I copied and updated the osl ebuild. There's a bit of a hack in there to find > the LLVM_ROOT. But it builds. > > signature.asc Description: Message s

Re: [gentoo-dev] sys-apps/firejail and sys-apps-firejail lts are up for grabs

> On 14 Oct 2020, at 18:40, Hank Leininger wrote: > > On 2020-10-11, Dennis Lamm wrote: >> the following packages are up for grabs: >> >> - sys-apps/firejail >> - sys-apps/firejail-lts > > I will proxy maintain both of these. Preparing a PR shortly... > I think ajak is also working on this (

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

> On 3 Nov 2020, at 21:53, James Le Cuirot wrote: > > On Tue, 03 Nov 2020 22:32:11 +0100 > Michał Górny wrote: > >> Additionally, the following packages are looking for a new maintainer: >> >> net-misc/chrony > > I may take this if no one else really wants it. I run a simple client > and se

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

> On 26 Nov 2020, at 22:37, Peter Stuge wrote: > 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? > It won’t be keyworded where it’s not available so Portage

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

> On 29 Dec 2020, at 09:13, Marcel Schilling > wrote: > > > I just want to comment that I switched to LibreSSL on several Gentoo > systems years ago and never had any major issues. > I run both desktop and server systems with LibreSSL, based on X and > Wayland. The only issues I ran into is a

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

> On 28 Dec 2020, at 10:02, Hanno Böck wrote: > > If it has any weight: > I think I was the first person to build Gentoo with LibreSSL. I support > this. > I’m pleased to have yours and blueness’ input. Really, I think going is probably best. Just make it clear it can come back with some new

[gentoo-dev] Last rites: dev-libs/ilbc-rfc3951

# Jaco Kroon (2021-01-04) # media-libs/libilbc is (for every package I manage) a drop-in for # dev-libs/ilbc-rfc3951. The latter had net-misc/asterisk, # net-libs/pjproject and net-voip/yate as dependencies. # (All of which has been bumped to no longer have this dependency.) # Removal in 30 days,

Re: [gentoo-dev] Non-maintainer commits and CI

> On 7 Jan 2021, at 14:28, Agostino Sarubbo wrote: > > Hello, > > it happens frequently that CI discovers failure(s) in non-maintainer commits. > > The most striking examples are maintainer-needed, proxy-maint and general pull > request where who made the change has no visibility on the new bu

Re: [gentoo-dev] ml project created

> On 12 Jan 2021, at 19:24, Alfredo Tupone wrote: > > As I have interest on lot of ebuild on dev-ml, and most of them are not > managed by any project, I have created a project to handle them. > Thanks Alfredo, I’m in and I joined #gentoo-ml too. > I have build https://wiki.gentoo.org/wiki/Pr

Re: [gentoo-dev] Packages up for grabs

> On 17 Jan 2021, at 09:26, Michał Górny wrote: > > Hello, > > The following packages are in need of a new maintainer due to their > current maintainer being MIA: > > […] > [ ] app-admin/stow Adopted the wonderful stow, but I’ll leave xstow for others. > [Bv] app-admin/xstow Thanks, Sam

[gentoo-dev] Package up for grabs: x11-misc/i3blocks

Hello, Packages up for grabs due to the retirement of mudler@: x11-misc/i3blocks No open bugs and no version bump pending. Thanks! Sam signature.asc Description: Message signed with OpenPGP

[gentoo-dev] Package up for grabs: media-gfx/frogr

Hello, Packages up for grabs due to the retirement of sobhan@: media-gfx/frogr It has 1 open bug and a version bump pending according to Repology. Thanks! Sam signature.asc Description: Message signed with OpenPGP

Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

> On 8 Feb 2021, at 00:52, Aisha Tammy wrote: > > Hi all, > [snip] > This transition is expected to take a long time so there shouldn't be a worry > about sudden > changes in packages. We are going to keep some of the more important old > GTK:2 ebuilds, > such as the CJK ebuilds, around as lon

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

> On 8 Feb 2021, at 11:19, Michał Górny wrote: > > Hi, > > FYI the developers of dev-python/cryptography decided that Rust is going > to be mandatory for 1.5+ versions. It's unlikely that they're going to > provide LTS support or security fixes for the old versions. > > Since cryptography is

[gentoo-dev] [RFC] Dropping s390 (but not s390x) entirely and s390, s390x to ~arch.

Hi all, I have two linked proposals: 1) I propose we remove support for Gentoo on s390 and support only s390x instead; 2) We drop the s390 arch (covering both s390 and s390x) keywords to ~s390 (unstable). Right now, we support both s390 and s390x with the same keyword (’s390’) but s390x has a

Re: [gentoo-dev] verifying profiles/package.mask comment format

> On 21 Feb 2021, at 04:30, Tim Harder wrote: > > Hi all, > > Is there interest in enforcing some basic QA for the semi-formatted > comments in profiles/package.mask (and possibly other profiles file > types)? I have code implementing the basic functionality done for > pkgcheck, but wondered if

[gentoo-dev] Last rites: dev-scheme/greg

# Sam James (2021-02-27) # Broken with newer(?) dev-scheme/guile, dead upstream # bug #642736, bug #773196 dev-scheme/greg signature.asc Description: Message signed with OpenPGP

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

# Sam James (2021-02-27) # Fails to build with GCC 10, out of date. # bug #723192, bug #737058 # Removal in 30 days dev-lang/ats signature.asc Description: Message signed with OpenPGP

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

# Sam James (2021-02-27) # Fails to build with GCC 10 (or otherwise!) # bug #708508, bug #728026, bug #542280 # Removal in 30 days sci-mathematics/ggnfs signature.asc Description: Message signed with OpenPGP

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

# Bernd Waibel (2021-02-27) # No longer actively supported upstream. # Removal needed to clean-up {ilmbase,openexr}-2.3.0 # Masked for removal in 30 days. media-gfx/openexr_viewers signature.asc Description: Message signed with OpenPGP

Re: [gentoo-dev] pkgdev: an alternative to `repoman commit`

> On 27 Feb 2021, at 14:50, Tim Harder wrote: > > Hi all, > > Finally responding to all the requests, I've hacked up an initial > alternative to repoman's commit functionality in the form of pkgdev [1] > that uses pkgcheck's API behind the scenes. The project is meant to grow > into a collecti

Re: [gentoo-dev] Non-maintainer commits and CI

> On 7 Jan 2021, at 14:28, Agostino Sarubbo wrote: > > Hello, > > it happens frequently that CI discovers failure(s) in non-maintainer commits. > > The most striking examples are maintainer-needed, proxy-maint and general pull > request where who made the change has no visibility on the new bu

[gentoo-dev] Last rites: games-strategy/0ad-data

# Sam James (2021-02-28) # games-strategy/0ad-data has been merged # into games-strategy/0ad for simplicity. # Note that in most cases, the latter uses # upstream pre-built assets anyway. # Nothing should really be using this. # bug #735352, bug #768930 # Removal in 14 days. games-strategy/0ad

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

> On 2 Mar 2021, at 05:10, Michael Orlitzky wrote: > > On Mon, 2021-03-01 at 22:54 -0500, Matt Turner wrote: >> tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote, >> called merge-driver-ekeyword that can automatically resolve git merge >> conflicts involving the KEYWORDS=... line

[gentoo-dev] Re: [gentoo-dev-announce] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

> On 2 Mar 2021, at 03:54, Matt Turner wrote: > > tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote, > called merge-driver-ekeyword that can automatically resolve git merge > conflicts involving the KEYWORDS=... line in ebuilds. > Thanks a lot for your work here, Matt! It’s som

[gentoo-dev] Begging notice: please use NATTkA / CC-ARCHES for keywording/stabilisation bugs

Hi, This is a begging notice to ideally use NATTkA if possible for your keywording or stabilisation bugs! [If you don’t know what to do, I hereby give you permission to nag me and ask me to check each one of your bugs to let you know if it’s working okay and if it’s all gone alright. New tools

[gentoo-dev] Begging notice: always CC all arches which are currently stable on your package

Hi, This is a friendly reminder that you should CC arch teams *for all arches which currently have a stable keyword for your package*. NATTkA handles this for you (see my other email [0]), but if you decide to not use it, please be sure you do CC all arches for which the previous stable version

[gentoo-dev] Urgent reminder to port your packages to Python 3.8 and Python 3.9

Hi, We still have ~31 packages still not declaring support for newer Python 3 targets than Python 3.7, we have ~1085 packages still not declaring support for newer Python 3 targets than Python 3.8 (i.e. Python 3.9). Please review this list to see if your packages are stuck on Python 3.7: http:/

[gentoo-dev] Last rites: app-office/moneyguru

# Sam James (2021-03-03) # Declared abandoned upstream and stuck # on Python 3.7. # Removal in 30 days. app-office/moneyguru signature.asc Description: Message signed with OpenPGP

Re: [gentoo-dev] Urgent reminder to port your packages to Python 3.8 and Python 3.9

> On 3 Mar 2021, at 22:55, Sam James wrote: > > Hi, > > We still have ~31 packages still not declaring support for newer Python 3 > targets than Python 3.7, > we have ~1085 packages still not declaring support for newer Python 3 targets > than Python 3.8 (i.e. > Py

Re: [gentoo-dev] [RFC] Dropping PyPy(3) back to ~arch

> On 2 Mar 2021, at 15:05, Michał Górny wrote: > > Hi, > > I think I've made a mistake by stabilizing PyPy(3), and I would like to > drop it back to ~arch (and stable-mask the relevant flags). > > Roughly, there are 4 problems with it: > > [snip] > Honestly, I've tried to improve PyPy in the

[gentoo-dev] Packages up for grabs: app-emulation/fuse app-emulation/fuse-utils app-emulation/libspectrum

Hi, Following the retirement of a proxy maintainer, as their request, we have the following packages up for grabs: app-emulation/fuse app-emulation/fuse-utils app-emulation/libspectrum Thanks! signature.asc Description: Message signed with OpenPGP

Re: [gentoo-dev] [News item review] V2 Chromium access to Google services

> On 8 Mar 2021, at 19:01, Stephan Hartmann wrote: > > Hi, Hi! Review from mobile so please excuse non-ideal formatting. > > updated based on previous suggestions. > > ``` > Title: Chromium access to Google services > Author: Stephan Hartmann > Content-Type: text/plain > Posted: 2021-0

Re: [gentoo-dev] Urgent reminder to port your packages to Python 3.8 and Python 3.9

> On 3 Mar 2021, at 22:55, Sam James wrote: > > Hi, > > We still have ~31 packages still not declaring support for newer Python 3 > targets than Python 3.7, > we have ~1085 packages still not declaring support for newer Python 3 targets > than Python 3.8 (i.e. &

[gentoo-dev] Begging notice: please mark your packages as ALLARCHES

Hi, Please mark your package as ALLARCHES if at all possible. The metadata.xml tag indicates to arch teams that the package is architecture independent and therefore testing on one architecture is sufficient. You can read more in the devmanual: https://devmanual.gentoo.org/keywording/#simultane

[gentoo-dev] Last rites: various old dev-ml/* packages stuck on oasis.eclass

# Sam James (2021-03-13) # Stuck on oasis.eclass, out of date # No reverse dependencies # bug #775785 # Removal in 14 days. Nothing should really # be able to use any of these right now anyway. dev-ml/qcheck dev-ml/macaque dev-ml/pgocaml dev-ml/csv dev-ml/gen dev-ml/tyxml dev-ml/stringext dev-ml

Re: [gentoo-dev] [PATCH] gstreamer-meson.eclass: New eclass required for gstreamer-1.18.0+

> On 17 Mar 2021, at 01:49, Haelwenn (lanodan) Monnier > wrote: > > Gstreamer switched to meson in 1.16.0 and removed autotools support in 1.18.0, > this eclass is an update of gstreamer.eclass. > > [snip] Thanks for working on this! > +# > +# GStreamer consuming applications should depend

[gentoo-dev] Last-rites: oasis.eclass

oasis.eclass: mark as @DEAD (last-rite eclass) Removal on 2021-04-05 when the rest of the Oasis packages, including Oasis (dev-ml/oasis) is removed. There's no point in keeping the eclass when Oasis itself is gone and nothing should be able to use this right now anyway due to the large number of

[gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs

o eqawarn * consistent 'case' style * consistent variable references * consistent references to bugs in comments * consistent use of ${ECLASS}, not "autotools.eclass" * use same ${WANT_AUTOCONF} comparison test throughout Signed-off-by: Sam James ---

Re: [gentoo-dev] [PATCH] xorg-2.eclass: Mark @DEAD for removal

> On 27 Mar 2021, at 19:25, Matt Turner wrote: > > Per Sam's suggestion, I'll also add > > # @DEPRECATED: Use xorg-3.eclass > I made the same mistake with oasis, do just ‘xorg-3.class’ because the pkgcheck text says ‘replacement: ${text}’. signature.asc Description: Message signed with Ope

[gentoo-dev] Last-rites: autotools-utils.eclass

autotools-utils.eclass: mark as @DEAD (last-rite eclass) Removal on 2021-04-28. Please port to autotools.eclass or out-of-source.eclass. signature.asc Description: Message signed with OpenPGP

Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs

 > On 28 Mar 2021, at 13:46, Ulrich Mueller wrote: > >  >>> On Sun, 28 Mar 2021, David Seifert wrote: >> This is just bringing it in line with the rest of the eclass. You know, >> consistency. > > If that's the goal then the patch should update all occurences, though. Well, that was defi

Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs

> On 27 Mar 2021, at 22:21, Sam James wrote: > Given how uncontroversial most of it is, the positive reviews, and the fact that I pushed a load of other eclassdoc changes (for other eclasses) but CI is still down, it makes sense to throw in as much as we can to not waste the big

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: get rid of eutils in

> On 31 Mar 2021, at 07:39, Andreas Sturmlechner wrote: > > qa-reports showing >7300 ebuilds with EAPI-7 using eutils.eclass, that can't > be right. > > - Restrict inherit eutils to - Drop bogus multilib.eclass (inherited by toolchain-funcs.eclass anyway) > - Several functions look like they

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: get rid of eutils in

> On 31 Mar 2021, at 10:09, Ulrich Mueller wrote: > >> On Wed, 31 Mar 2021, Andreas Sturmlechner wrote: > >> setup-allowed-flags() { >> +[[ ${EAPI} == [0-7] ]] || >> +die "Internal function ${FUNCNAME} is not available in >> >=EAPI-8." >> +_setup-allowed-flags >> +} >

[gentoo-dev] [PATCH v2 1/3] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs, configure.ac rename

consistent 'case' style * consistent variable references * consistent references to bugs in comments * consistent use of ${ECLASS}, not "autotools.eclass" * use same ${WANT_AUTOCONF} comparison test throughout Bug: https://bugs.gentoo.org/426262 Closes: https://bugs.gentoo.org/5

[gentoo-dev] [PATCH v2 2/3] gnuconfig.eclass: provide basic @ECLASS block, docs

Signed-off-by: Sam James --- eclass/gnuconfig.eclass | 33 +++-- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/eclass/gnuconfig.eclass b/eclass/gnuconfig.eclass index 3433837787c..f679441445f 100644 --- a/eclass/gnuconfig.eclass +++ b/eclass

[gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

EPREFIX is only available in > EAPI 2 but let's take the opportuinty to clean up in general. We don't want to keep worrying about *very* old EAPI cases, especially given other eclasses either barely - or don't - support it. Signed-off-by: Sam James --- eclass/gnu

Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

> On 5 Apr 2021, at 17:24, Ulrich Mueller wrote: > >>>>>> On Mon, 05 Apr 2021, Sam James wrote: > >> +4|5|6) >> +DEPEND=" >> +sys-apps/grep >> +sys-devel/gnuconfig >> +

[gentoo-dev] Packages up for grabs: app-emulation/img, app-forensics/aide, app-text/cherrytree, media-gfx/zbar, net-p2p/go-ethereum

Packages up for grabs due to retirement of a proxied maintainer (and somebody giving up a package): app-emulation/img app-forensics/aide app-text/cherrytree media-gfx/zbar net-p2p/go-ethereum Most have no open bugs and are in a reasonable state. signature.asc Description: Message signed with Op

Re: [gentoo-dev] Packages up for grabs: app-emulation/img, app-forensics/aide, app-text/cherrytree, media-gfx/zbar, net-p2p/go-ethereum

> On 6 Apr 2021, at 22:16, Sam James wrote: > > Packages up for grabs due to retirement of a proxied maintainer (and somebody > giving up a package): > app-emulation/img > app-forensics/aide > app-text/cherrytree > media-gfx/zbar > net-p2p/go-ethereum > > Mo

[gentoo-dev] s390 has been dropped to ~s390 (testing/unstable)

Hi, Given I received no comments on the mailing list [0] post from 16th Feb and affirmative comments via IRC, I’ve dropped all s390 keywords to ~s390 (testing/unstable). We’ll keep the s390 arch in addition to s390x as a subprofile for now as this reduces the hassle of maintaining s390. This is

[gentoo-dev] s390 has been dropped to ~s390 (testing/unstable) (resent)

Hi, Given I received no comments on the mailing list [0] post from 16th Feb and affirmative comments via IRC, I’ve dropped all s390 keywords to ~s390 (testing/unstable). We’ll keep the s390 arch in addition to s390x as a subprofile for now as this reduces the hassle of maintaining s390. This is

[gentoo-dev] games.eclass: last-rite eclass

games.eclass: mark as @DEAD (last-rite eclass) Removal on 2021-05-09. Please port to general eclass functions/helpers. No specific eclass is needed for general games installation. signature.asc Description: Message signed with OpenPGP

[gentoo-dev] base.eclass: last-rites

base.eclass: last-rite eclass (mark as @DEAD) Removal on 2021-05-09. Please port to general eclass functions/helpers. See https://bugs.gentoo.org/497022 for information. signature.asc Description: Message signed with OpenPGP

Re: [gentoo-dev] vdr-plugin-2.eclass QA fix, please review, bug 778815

> On 9 Apr 2021, at 22:10, Joerg Bornkessel wrote: > > https://bugs.gentoo.org/show_bug.cgi?id=778815 > > pkgcheck, gives an error like this > VariableScope: vdr-plugin-2: variable 'WORKDIR' used in > 'vdr-plugin-2_pkg_setup', line 371 > Hi, thanks for looking into this! > inserted patch w

Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

> On 7 Apr 2021, at 12:06, Ulrich Mueller wrote: > >>>>>> On Tue, 06 Apr 2021, Sam James wrote: > >> 1) @system varies between profiles anyway which makes it hard to fully >> rely on; > > That's exactly the reason why you _don't_* add

Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

> On 7 Apr 2021, at 12:18, Michael Orlitzky wrote: > > On Tue, 2021-04-06 at 20:32 +0100, Sam James wrote: >> >>> >>> We usually don't add basic tools like grep to dependencies. >> >> Few points: >> >> ... > > 5) There

Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

> On 10 Apr 2021, at 01:13, Michael Orlitzky wrote: > > On Sat, 2021-04-10 at 00:32 +0100, Sam James wrote: >> >> >> Yes, this is the part I find difficult too. The important >> distinction here was *bootstrapping* (which I missed) >> but I think at

Re: [gentoo-dev] Continuous integration on GURU

> On 22 Apr 2021, at 13:59, Ionen Wolkens wrote: > [snip] > And, even if you don't see it like that, someday someone may want > to go on a fixing spree using those trackers (may it be for ::guru > or ::gentoo) but will keep seeing them mixed up together. Yes, this is particularly apt for me. L

Re: [gentoo-dev] python and frieds installs test code

> On 22 Apr 2021, at 11:50, Joakim Tjernlund > wrote: > > I have noted that python, portage and gentoolkit appers to install many MB of > what appers > to be test code: > python: /usr/lib/python*/test, /usr/lib/python*/ctypes/test, > /usr/lib/python*/lib2to3/tests, >/usr/lib/python*/

Re: [gentoo-dev] Continuous integration on GURU

> On 22 Apr 2021, at 14:31, Agostino Sarubbo wrote: > > Thanks for all feedback. > > Please discuss all points internally (branch, email, trackers and so on) and > send me an email with all changes you would like to have. As an aside, I do appreciate the CI and it’s turned out to be pretty us

Re: [gentoo-dev] TEXTRELs in assembly program

> On 22 Apr 2021, at 22:07, Nekun wrote: > > Hi all, > Hi! > Working on the fasm ebuild, have some questions: > > 1. fasm is written on itself and has two variants: self-contained binary for > x86 and amd64 and linked with libc only for x86. Also, there are tools for > working with the pr

Re: [gentoo-dev] gcc-11 enters ~arch tree

> On 27 Apr 2021, at 19:22, Sergei Trofimovich wrote: > > Today gcc-11.1.0 released upstream and was added to ::gentoo as: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc068d96fb49e308456cbe944fb29b1f78e6ad5c > And same day too! > [snip] > As usual if you can't figure out wh

Re: [gentoo-dev] [PATCH news v2] Add Python 3.9 news item

> On 29 Apr 2021, at 22:01, Michał Górny wrote: > > Signed-off-by: Michał Górny > --- > .../2021-04-29-python3-9.en.txt | 93 +++ > 1 file changed, 93 insertions(+) > create mode 100644 2021-04-29-python3-9/2021-04-29-python3-9.en.txt > > diff --git a/2021-04-29-

Re: [gentoo-dev] [PATCH news v2] Add Python 3.9 news item

> On 30 Apr 2021, at 08:23, Joonas Niilola wrote: > > > > On 30.4.2021 3.50, Sam James wrote: >>> On 29 Apr 2021, at 22:01, Michał Górny wrote: >>> >>> + >>> + >>> +You can also switch to Python 3.9 earlier

Re: [gentoo-dev] [PATCH news v2] Add Python 3.9 news item

> On 2 May 2021, at 22:46, Michał Górny wrote: > > On Fri, 2021-04-30 at 01:50 +0100, Sam James wrote: >> >> [snip] > > I've applied most of your suggestions... and feel like this still needs > more work. I'll try to make it clearer what all options

Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item

> On 2 May 2021, at 23:04, Michał Górny wrote: > [snip] > +Upgrade commands > + > +The Python 3.8 cleanup requires that Python 3.8 is removed from complete > +dependency trees in batch. If some of the installed packages using > +an older Python version are not triaged for the u

Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item

> On 3 May 2021, at 21:18, Michał Górny wrote: > > On Mon, 2021-05-03 at 19:06 +0100, Sam James wrote: >> [snip] > > I want to avoid it on the top, so people don't do it prematurely before > reading their options. > Good point - and I can’t complain, given I

[gentoo-dev] Package up for grabs: media-libs/libplacebo

Hi, media-libs/libplacebo is now maintainer-needed after its proxy maintainer decided to retire. It has several open bugs and a version bump pending. Thanks, sam signature.asc Description: Message signed with OpenPGP

Re: [gentoo-dev] Need help with perl-cleaner (and app-admin/gentoo-perl-helpers)

> On 13 May 2021, at 12:15, Andreas K. Huettel wrote: > > Am Donnerstag, 13. Mai 2021, 12:02:32 CEST schrieb Andreas K. Huettel: >> Hi all, >> >> due to having somewhat too many Gentoo projects and not enough time >> at the moment, I'd like to ask for help with perl-cleaner here. >> > > PS.

Re: [gentoo-dev] News item: >=net-p2p/syncthing-1.17.0 incompatibility with

> On 14 May 2021, at 15:31, Marek Szuba wrote: > > Nb. 1.17.0 has not come out yet but given 1.17.0-rc.3 came out 3 days ago and > Syncthing upstream normally only has 3 release candidates before an actual > release, we can expect it to come out quite soon. > > * * * > > Title: >=net-p2p/syn

[gentoo-dev] Last rites: mail-client/etpan-ng

# Sam James (2021-06-10) # Fails to build with modern libetpan. Unmaintained. # See bug #699570, bug #448574. # Removal on 2021-07-10. mail-client/etpan-ng signature.asc Description: Message signed with OpenPGP

Re: [gentoo-dev] Packages up for grabs

> On 13 Jun 2021, at 10:01, David Seifert wrote: > > The following packages have been dropped to m-n, since johu hasn't > touched them in over a year and show no signs of maintaining them: > > acct-group/quassel > acct-user/quassel [...] > net-irc/quassel > Adopted these. best, sam sig

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

# Sam James (2021-06-15) # Fails to build with GCC 11. Strange build system that needs more # work to function properly (and integrate better). Several open bugs. # bug #795999, bug #787902, bug #766033, bug #724674, bug #713206. # Removal on 15-07-2021. media-sound/sc2mpd signature.asc

Re: [gentoo-dev] [RFC] Should we switch IRC client defaults off Freenode?

> On 16 Jun 2021, at 10:13, Michał Górny wrote: > > [snip] The only case not covered by your questions is where an IRC client might autojoin #gentoo@libera (Smuxi does this with #smuxi) in which case we want to update it. > 1. Should we be proactively changing the default network in IRC clien

<    2   3   4   5   6   7   8   9   10   >