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

> On 3 Nov 2021, at 15:03, Thomas Deutschmann wrote: > > Hi, > > it is currently not possible to smoothly run a world upgrade on a 4 months > old system which doesn't even have a complicated package list: > [snip] > > This is not about finding solution to upgrade the system (in this case it was

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

> On 3 Nov 2021, at 22:15, Joshua Kinard wrote: > Actually, it is possible to manage dependency errors like those. It just > takes a *lot* of elbow grease, and and long, long time time. Especially if > you have museum-grade hardware that these errors are happening on. > > For Perl, I've usuall

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

> On 3 Nov 2021, at 20:16, Rich Freeman wrote: > It probably would be good to get these policies documented someplace > OTHER than the council decision logs. I do remember the discussion > from the distant past but it is worth having it in a more prominent > place, especially since a one year st

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

> On 3 Nov 2021, at 23:53, Aaron Bauman wrote: > Is that where the policy belongs? > If so, shouldn't the council update it based on their decisions? > "patches are welcome" doesn't fit every scenario. Got to agree here. If there's a gap in the documentation, let's file a bug -- irrespective of

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

On 4 Nov 2021, at 00:02, Sam James wrote: >> On 3 Nov 2021, at 23:53, Aaron Bauman wrote: >> Is that where the policy belongs? >> If so, shouldn't the council update it based on their decisions? >> "patches are welcome" doesn't fit every scenario.

Re: [gentoo-dev] [RFC] Un-slotting LLVM

> On 8 Nov 2021, at 11:18, Michał Górny wrote: > Hi, > A few years back I've slotted LLVM and Clang to make the life with > revdeps easier. Long story short, every major LLVM release (which > happens twice a year) breaks API and it takes some time for revdeps to > adjust. Slotting made it poss

Re: [gentoo-dev] [RFC] Proposed dates for Python 3.10 switch and Python 3.8 removal

> > > On 11 Nov 2021, at 18:40, Patrick McLean wrote: > > On Thu, 11 Nov 2021 12:58:24 -0500 > "Wolfgang E. Sanyer" wrote: > >> El jue, 11 de nov. de 2021 12:56 p. m., Patrick McLean >> escribió: >> >>> On Thu, 11 Nov 2021 17:05:45 +0100 >>> Michał Górny wrote: I'd like to add some dates r

Re: [gentoo-dev] [RFC] Proposed dates for Python 3.10 switch and Python 3.8 removal

[Resending due to mail client nonsense...] > On 11 Nov 2021, at 18:44, Patrick McLean wrote: > On Thu, 11 Nov 2021 09:55:48 -0800 > Patrick McLean mailto:chutz...@gentoo.org>> wrote: >> On Thu, 11 Nov 2021 17:05:45 +0100 >> Michał Górny wrote: >>> I'd like to add some dates regarding 3.8 remova

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

# Volkmar W. Pogatzki (2021-11-13) # depends on deprecated jdk / jre, bug #787449 # stuck with EAPI 5, latest release in 2005 # Removal in 30 days. net-analyzer/neti signature.asc Description: Message signed with OpenPGP

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

# Volkmar W. Pogatzki (2021-11-13) # java package without consumers, bug #787338. Removal in 30 days. dev-db/db-je signature.asc Description: Message signed with OpenPGP

[gentoo-dev] Last rites: dev-java/jackson

# Volkmar W. Pogatzki (2021-11-15) # Library without consumers, # bug #771693 (multiple CVEs); Removal in 30 days. dev-java/jackson signature.asc Description: Message signed with OpenPGP

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

# Volkmar W. Pogatzki (2021-11-23) # Does not support updated dev-java/pdfbox-2.0.24, Bug #803488 # Blocks (CVE-2018-11797, CVE-2021-{27807,27906,31811,31812}) dev-tex/pdfannotextractor signature.asc Description: Message signed with OpenPGP

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

> On 25 Nov 2021, at 13:37, Thomas Deutschmann wrote: > For the records: > I hope that this news item won't get delayed by the recent ComRel bug someone > filled against me regarding this news item. No need to reference that here. Please keep that to e.g. -core. > While we often rush with news

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

> On 25 Nov 2021, at 13:59, Thomas Deutschmann wrote: > If you do a normal world upgrade, this is the default portage behavior, not? > I.e. package manager will downgrade if you don't stop. And especially on > servers, people tend to use cronjobs/scripts to do that... I would really not recom

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

> On 25 Nov 2021, at 03:21, Thomas Deutschmann wrote: > > Bug: https://bugs.gentoo.org/825234 > Signed-off-by: Thomas Deutschmann > --- > [snip] > +On 2021-11-21, a member of the QA project accidentially de-keyworded > +MariaDB 10.6 to address a file collision, users, who also had latest > +d

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

> On 25 Nov 2021, at 17:07, Thomas Deutschmann wrote: > > On 2021-11-25 18:01, Piotr Karbowski wrote: >>> https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643 >> Would you see something like this on more ebuilds, postgres, mysql, >> elasticsearch, or have prope

Re: [gentoo-dev] rfc: java-vm-2.eclass eapi 8 support

> On 27 Nov 2021, at 09:54, Miroslav Šulc wrote: > > hello devs, > > please find attached patch for upgrade of java-vm-2.eclass to support eapi 8. > eapi 5 is not used by any package inheriting this eclass so i dropped it. > > i also attach update of the ebuilds of packages that use this ecl

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

> On 28 Nov 2021, at 23:26, Michael Orlitzky wrote: > [sinp] > The only problem that anyone has put forth is one that does not exist. > UIDs and GIDs are still assigned dynamically in Gentoo. The number you > type in the ebuild is only a hint: it's the first number that will be > tried during th

Re: [gentoo-dev] Clang/LLVM profile

> On 29 Nov 2021, at 01:45, 2b57 <2...@protonmail.com> wrote: > > Sorry all, it seems that I've confused the lists. I'll forward this to user > > ‐‐‐ Original Message ‐‐‐ > On Monday, November 29th, 2021 at 2:42 AM, 2b57 <2...@protonmail.com> wrote: >> Hello all, >> >> I'm in the middl

Re: [gentoo-dev] [PATCH] go-module.eclass: Add GO_OPTIONAL flag

> On 28 Nov 2021, at 19:23, Zac Medico wrote: > >> [snip] > > How about if we also add a GO_DEPEND variable, so that eclasshi consumers can > do something like BDEPEND="go? ( ${GO_DEPEND} )" ? > -- My preference is to go with what we've been doing more recently (do _OPTIONAL) so that consum

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

> On 29 Nov 2021, at 00:06, Michael Orlitzky wrote: > > On Sun, 2021-11-28 at 23:39 +0000, Sam James wrote: >> >> Whissi and others raised some points that I think you may have some views on >> (and I'm interested in hearing them). >> > > I don&#

Re: [gentoo-dev] [PATCH v2] eclass/dune.eclass: fixes

> On 9 Dec 2021, at 22:10, Maciej Barć wrote: > > bump to EAPI 8 Say "support EAPI 8" instead. May be worth splitting the commit into a few different changes so the summary can be more informative than "fixes" (try git add -p). lgtm otherwise, thanks for doing this! > drop support for EAPI

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: add detection for loongarch

> On 30 Aug 2021, at 04:25, WANG Xuerui wrote: > > From: WANG Xuerui > > The Linux port currently under review has arch/loongarch, and should > almost certainly remain that way till merge; meanwhile it's ARCH=loong > on the Gentoo side, per mailing list discussion[1] and eselect > adaptation[

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: filter-lfs-flags: remove -D_TIME_BITS=64

> On 18 Dec 2021, at 18:27, Mike Gilbert > wrote: > > glibc only allows _TIME_BITS=64 when _FILE_OFFSET_BITS=64. > > Signed-off-by: Mike Gilbert mailto:flop...@gentoo.org>> > --- > eclass/flag-o-matic.eclass | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >

[gentoo-dev] Up for grabs: media-tv/plex-media-server

media-tv/plex-media-server is up for grabs as the result of a proxied maintainer retiring. It's a popular package. There are some active overlays with Plex in them, it'd be nice to pull in their work / approach their authors and ask if they'd be willing to share their work in ::gentoo. Best, sam

Re: [gentoo-dev] [PATCH] toolchain.eclass: fix crossdev powerpc-*-musl builds

> On 27 Dec 2021, at 05:24, Georgy Yakovlev wrote: > > otherwise initial build may fail with: > unknown long double size, cannot define BFP_FMT If possible, would you mind filing a bug with the build log of it failing (and brief steps on how to get it) just so we can easily test if we can drop

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

> On 1 Jan 2022, at 22:21, Piotr Karbowski wrote: > > Hi, > > I'd like to get some insight how others see the concept of narrowing the > scope of USE flags in Gentoo. > > Taking a quote from devmanual: > > > USE flags are to control optional dependencies and settings which the user > may

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

> On 2 Jan 2022, at 04:28, Blake Bartenbach wrote: > > On Sat Jan 1, 2022 at 4:21 PM CST, Piotr Karbowski wrote: >> The thing is, it's 2022, and it does not make any sense to *not* support >> IPv6, even if one does not connect to any network with IPv6, there's no >> harm to just have it there.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

> On 2 Jan 2022, at 00:03, Scott Ellis wrote: > > Your `ipv6` USE flag hits home - I don't use IPv6, nor do I want to have IPv6 > support built into things (just another potential "thing" that I have to > secure, or errors/warnings I need to suppress since I run an IPv6-less > kernel). > >

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

> On 4 Jan 2022, at 00:29, Michael Orlitzky wrote: > > On Mon, 2022-01-03 at 21:29 +0100, Piotr Karbowski wrote: >> >> Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam >> shared, does not make sense to be togglable. >> > > Many packages need their ipv6 code disabled if the

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

> On 3 Jan 2022, at 17:16, Alec Warner wrote: >> [snip] > > I'm trying to understand your principles here. Like on what basis do > you remove or add flags (in general). > > I want to remove: > - bash-completion FWIW, I've managed to remove basically all instances of {bash,zsh}-completion and

[gentoo-dev] [PATCH 2/2] linux-info.eclass: drop unnecessary IUSE="kernel_linux"

It's already an implicit IUSE, so we don't need this. Signed-off-by: Sam James --- eclass/linux-info.eclass | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass index 568f7a1a2832..a0942f0e554c 100644 --- a/ec

[gentoo-dev] [PATCH 1/2] linux-mod.eclass: drop unnecessary IUSE="kernel_linux"

It's already an implicit IUSE, so we don't need this. Signed-off-by: Sam James --- eclass/linux-mod.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass index 9f4ae64f6b55..496b9c98b526 100644 --- a/ec

Re: [gentoo-dev] [PATCH 1/2] linux-mod.eclass: drop unnecessary IUSE="kernel_linux"

> On 4 Jan 2022, at 21:54, Michał Górny wrote: > > On Tue, 2022-01-04 at 11:17 -0500, Mike Gilbert wrote: >> On Tue, Jan 4, 2022 at 5:23 AM Sam James wrote: >>> >>> It's already an implicit IUSE, so we don't need this. >> >> I think it

[gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the amount of RAM available (uses amount declared as needed in the ebuild). Typically should be ~2GB per job. Bug: https://bugs.gentoo.org/570534 Signed-off-by: Sam James --- eclass/check-reqs.e

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

> On 4 Jan 2022, at 22:58, Sam James wrote: > > Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the > amount of RAM available (uses amount declared as needed > in the ebuild). Typically should be ~2GB per job. > > Bug: https://bugs.gentoo.org/57

Re: [gentoo-dev] [PATCH v3] kernel-2.eclass: Respect portage toolchain variables

> On 3 Jan 2022, at 18:23, Mike Gilbert wrote: > On Mon, Jan 3, 2022 at 12:49 PM Adrian Ratiu > wrote: >> >> Starting with kernel>=v5.7 the build system can override the >> tools vars by setting LLVM=1 [1], but older kernels still use >> the default GNU tools

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

> On 5 Jan 2022, at 19:53, Ulrich Mueller wrote: > >> On Wed, 05 Jan 2022, Florian Schmaus wrote: > >>> That applies to all parallel builds though, not only to ebuilds >>> inheriting check-reqs.eclass. By tweaking MAKEOPTS, we're basically >>> telling the user that the --jobs setting in th

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

> On 5 Jan 2022, at 08:28, Ulrich Mueller wrote: > >>>>>> On Tue, 04 Jan 2022, Sam James wrote: > >> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the >> amount of RAM available (uses amount declared as needed >> in the ebu

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

> On 5 Jan 2022, at 19:18, Kai Krakow wrote: > > Am Mi., 5. Jan. 2022 um 19:22 Uhr schrieb Ulrich Mueller >: >> >>> [...] >> That applies to all parallel builds though, not only to ebuilds >> inheriting check-reqs.eclass. By tweaking MAKEOPTS, we're basically >> te

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

> On 5 Jan 2022, at 19:02, Roy Bamford wrote: > > Sam, > > Do users with FEATURES=distcc still have to opt out of this > MAKEOPTS clamping? > Great point! I think we could add an exemption for that and make it a noop or warning-only. Best, sam signature.asc Description: Message signed w

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

> On 5 Jan 2022, at 17:51, Alec Warner wrote: > On Tue, Jan 4, 2022 at 3:03 PM Sam James wrote: >> >> On 4 Jan 2022, at 22:58, Sam James wrote: >> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the >> amount of RAM available (uses am

[gentoo-dev] Mailing list for ebuild patches? (Was: Re: [PATCH] media-libs/freetype: fix GCC usage during configure)

> On 7 Jan 2022, at 13:08, Adrian Ratiu wrote: > > If $CC_BUILD is not set, configure defaults to GCC for some > of its tests causing clang builds to use a mixture of the > two compilers instead of using just clang consistently. > [snip] Thanks! Looks like Polynomial-C applied this as https:

Re: [gentoo-dev] Maintainer needed: dev-db/sqlite

> On 14 Jan 2022, at 23:10, Peter Stuge wrote: > > Mike Gilbert wrote: >> The current (proxied) maintainer is somewhat difficult to work with > > Why is Arfrever being treated so bad here? To me, it looks like > you're the one who is difficult to work with. :\ > floppym is not obligated to w

[gentoo-dev] Last rites: dev-db/oracle-instanclient-*

# Marco Genasci (2022-01-15) # Removed in favor of unified package dev-db/oracle-instantclient # Removal on 2022-02-15. Bug #589146 dev-db/oracle-instantclient-basic dev-db/oracle-instantclient-jdbc dev-db/oracle-instantclient-odbc dev-db/oracle-instantclient-sqlplus signature.asc Description: M

[gentoo-dev] [PATCH 1/4] autotools.eclass: don't inject -I${SYSROOT} to aclocal

: https://bugs.gentoo.org/710792 Closes: https://bugs.gentoo.org/677002 Closes: https://bugs.gentoo.org/738918 Thanks-to: James Le Cuirot Signed-off-by: Sam James --- eclass/autotools.eclass | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/eclass/autotools.eclass b/eclass/autotools.ec

[gentoo-dev] [PATCH 2/4] autotools.eclass: use --system-acdir for aclocal

ing board) Signed-off-by: Sam James --- eclass/autotools.eclass | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass index e2572290f0cbe..2cf7c076d01ed 100644 --- a/eclass/autotools.eclass +++ b/eclass/autotools.

[gentoo-dev] [PATCH 3/4] autotools.eclass: update for latest automake 1.16.4

Signed-off-by: Sam James --- eclass/autotools.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass index 2cf7c076d01ed..5250b28042ee2 100644 --- a/eclass/autotools.eclass +++ b/eclass/autotools.eclass @@ -74,7 +74,7

[gentoo-dev] [PATCH 4/4] autotools.eclass: update for autoconf 2.71

Closes: https://bugs.gentoo.org/827852 Signed-off-by: Sam James --- eclass/autotools.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass index 5250b28042ee2..5568cca505d78 100644 --- a/eclass/autotools.eclass +++ b

Re: [gentoo-dev] [PATCH 2/4] autotools.eclass: use --system-acdir for aclocal

> On 17 Jan 2022, at 11:09, Sam James wrote: > > We need to instruct aclocal that it might find macros in both > ${BROOT} _and_ ${SYSROOT}. > > - A classic example within BROOT is autoconf-archive. > > - A classic example within SYSROOT is, say, libogg. A fair amo

Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust

> On 17 Jan 2022, at 23:24, Georgy Yakovlev wrote: > > Hi, > > I've been approached multiple times with that request, and a lot of > time I see new users completely destroyed by rust build time and disk > space requirements. > I'll out myself as being one of these people! > WDYT about switc

[gentoo-dev] [PATCH 1/8] flag-o-matic.eclass: strip-flags: Fix logic to properly support "=" in patterns.

From: Arfrever Frehtes Taifersar Arahesis Signed-off-by: Arfrever Frehtes Taifersar Arahesis Signed-off-by: Sam James --- eclass/flag-o-matic.eclass | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o

[gentoo-dev] [PATCH 2/8] flag-o-matic.eclass: allow -fno-diagnostics-color -fmessage-length=0

Both of these options are useful for automated reports and should be harmless. Closes: https://bugs.gentoo.org/830534 Reported-by: Agostino Sarubbo Signed-off-by: Sam James --- eclass/flag-o-matic.eclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/eclass/flag-o-matic.eclass b/eclass

[gentoo-dev] [PATCH 3/8] flag-o-matic.eclass: restructure comments a bit

No functional change. Signed-off-by: Sam James --- eclass/flag-o-matic.eclass | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass index 38ad14d8f5fe8..37577209281a1 100644 --- a/eclass/flag-o-matic.eclass

[gentoo-dev] [PATCH 4/8] flag-o-matic.eclass: allow Spectre mitigation flags

Closes: https://bugs.gentoo.org/646076 Signed-off-by: Sam James --- eclass/flag-o-matic.eclass | 5 + 1 file changed, 5 insertions(+) diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass index 37577209281a1..d6590a2e52dfd 100644 --- a/eclass/flag-o-matic.eclass +++ b/eclass

[gentoo-dev] [PATCH 5/8] flag-o-matic.eclass: allow -glldb

We already allow -ggdb for GDB and this is the analogue for LLDB. Bug: https://bugs.gentoo.org/800533 Reported-by: Jannik Glückert Signed-off-by: Sam James --- eclass/flag-o-matic.eclass | 1 + 1 file changed, 1 insertion(+) diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass

[gentoo-dev] [PATCH 6/8] flag-o-matic.eclass: allow -ffixed-x18 for arm64

Needed for shadow stack bits on ARM64. Closes: https://bugs.gentoo.org/800533 Thanks-to: Jannik Glückert Signed-off-by: Sam James --- eclass/flag-o-matic.eclass | 3 +++ 1 file changed, 3 insertions(+) diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass index a2e37b89b6f08

[gentoo-dev] [PATCH 7/8] flag-o-matic.eclass: allow -fstack-clash-protection, -fcf-protection=*

-fstack-clash-protection suggested by Arfrever. Reported-by: Arfrever Frehtes Taifersar Arahesis Signed-off-by: Sam James --- eclass/flag-o-matic.eclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass index 7ac4f4a7791d1

[gentoo-dev] [PATCH 8/8] flag-o-matic.eclass: allow -frecord-command-line

In Clang, -frecord-gcc-switches does the same as this anyway. Signed-off-by: Sam James --- eclass/flag-o-matic.eclass | 1 + 1 file changed, 1 insertion(+) diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass index 062bd04e2e0bd..50caa401bacfb 100644 --- a/eclass/flag-o

Re: [gentoo-dev] [PATCH 1/4] autotools.eclass: don't inject -I${SYSROOT} to aclocal

> On 19 Jan 2022, at 06:35, Mike Frysinger wrote: > > On 17 Jan 2022 11:09, Sam James wrote: >> When -I${SYSROOT} is injected, it'll override the default of -Im4, which >> results in trying to install macros to ${SYSROOT} (a sandbox violation) >> when they can&#

[gentoo-dev] Last rites for USE flag: sys-libs/db[java]

# Sam James (2022-01-23) # Java bindings are broken with OpenJDK 11+ and we're not # aware of any consumers. bug #713866 # The bindings will be removed on 2022-02-23 due to their state # of disrepair. sys-libs/db java (Note that sys-libs/db IS NOT going away, just the Java USE

Re: [gentoo-dev] Feature request: auto-CC for bugs modified via commit tags

> On 25 Jan 2022, at 17:00, Michael Orlitzky wrote: > > Can I request that Bug: and Closes: tags in our commits automatically > CC the committer on the bug that is modified? > > Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user > will leave a comment like "it still crashes on

[gentoo-dev] Itanium (IA64) port: call for help

Hi all, TL;DR: We really need help! There aren't many developers in Gentoo Currently interested in working on Itanium. Come hang around in #gentoo-ia64 on libera.chat (IRC) if you're interested in helping. As discussed in the recent Gentoo Council meeting [0], concerns were raised about the statu

Re: [gentoo-dev] Itanium (IA64) port: call for help

> On 27 Jan 2022, at 18:22, Sam James wrote: > > Hi all, > > TL;DR: We really need help! There aren't many developers in Gentoo > Currently interested in working on Itanium. Come hang around in #gentoo-ia64 > on libera.chat (IRC) if you're interested in help

Re: [gentoo-dev] [PATCH 01/12] toolchain.eclass: remove EAPI 5 and 6

> On 29 Jan 2022, at 17:31, David Seifert wrote: > > Signed-off-by: David Seifert > -- series lgtm Best, sam signature.asc Description: Message signed with OpenPGP

[gentoo-dev] [PATCH] texlive-common.eclass: respect EPREFIX in symlink creation

Closes: https://bugs.gentoo.org/832408 Signed-off-by: Sam James --- eclass/texlive-common.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass index 1fe33444f1e56..5acac2090cd16 100644 --- a/eclass/texlive

[gentoo-dev] Last rites: media-video/atomicparsley-wez

# Sam James (2022-01-31) # Fork of media-video/atomicparsley. media-video/atomicparsley now uses this # fork (wez), so just switch to that. No need for a separate package for the fork. # Removal on 2022-02-31. bug #668708. media-video/atomicparsley-wez signature.asc Description: Message

[gentoo-dev] [PATCH v2] texlive-common.eclass: respect EPREFIX in symlink creation

Closes: https://bugs.gentoo.org/832408 Signed-off-by: Sam James --- eclass/texlive-common.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass index 1fe33444f1e56..40e2c3530510b 100644 --- a/eclass/texlive

Re: [gentoo-dev] [PATCH] texlive-common.eclass: respect EPREFIX in symlink creation

> On 31 Jan 2022, at 05:55, Ulrich Mueller wrote: > >>>>>> On Mon, 31 Jan 2022, Sam James wrote: > >> -dosym /etc/texmf/$(dirname ${f}).d/$(basename ${f}) >> ${TEXMF_PATH}/${f} >> +dosym "${EPREFIX}"/etc/texmf/$

Re: [gentoo-dev] [PATCH 5/6] distutils-r1.eclass: Add DISTUTILS_DEPS output var for PEP 517 mode

> On 31 Jan 2022, at 22:59, Michał Górny wrote: > > The PEP 517 build-time deps have gotten more complex, and largely depend > on the internal eclass logic used to build and install wheels. > Introduce a DISTUTILS_DEPS output variable that contains the correct > BDEPEND string for use in DISTUT

Re: [gentoo-dev] [PATCH v2] texlive-common.eclass: respect EPREFIX in symlink creation

> On 31 Jan 2022, at 22:55, Sam James wrote: > > Closes: https://bugs.gentoo.org/832408 > Signed-off-by: Sam James > --- > eclass/texlive-common.eclass | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Tested on prefix & normal Gentoo. Pushed.

[gentoo-dev] [PATCH] kernel-build.eclass: add HPPA support

do this cleanly only for HPPA 2.0. Tested on RP3440 and C8000. Signed-off-by: Sam James --- eclass/kernel-build.eclass | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass index 2796493010878..0a49533e48d34 10

Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14

Michał Górny writes: > On Mon, 2024-10-14 at 01:43 +0100, Sam James wrote: >> >> > However, I think the cleanest way forward would be to stop slotting >> > CPython like this, and instead have a separate package for each version, >> > just like the va

Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14

Michał Górny writes: > Hello, > > Historically, all versions of CPython were slotted in a single package, > i.e.: > > dev-lang/python:3.N > I feel like this whole thing happened so fast I didn't have a chance to comment properly. I understand you've retracted it but I'd like to add some contex

Re: [gentoo-dev] Re: [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14

Michał Górny writes: > On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote: >> On 12/10/24 10:12, Michał Górny wrote: >> > Comments? >> > >> I'm afraid it would lead to way too many packages and I'm not sure the >> overall experience would be an improvement. > > 5 are too many? > >> With your

Re: [gentoo-dev] [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14

Mitchell Dorrell writes: > How will the upgrade path look, from e.g. 3.16 to 3.17? What will the typical > Gentoo user experience be? What will the > experience be for a Python developer with a local overlay containing custom > Python packages? It should be transparent because PYTHON_COMPAT wi

[gentoo-dev] [COMMITTED] profiles: sync cpu_flags_x86 with cpuid2cpuflags

From: Paul Zander Signed-off-by: Paul Zander Closes: https://github.com/gentoo/gentoo/pull/38695 Signed-off-by: Sam James --- profiles/arch/amd64/use.mask | 23 +++ profiles/arch/base/use.mask | 23 +++ profiles/arch/x86/use.mask | 23

Re: [gentoo-dev] Slotting PyPy

Michał Górny writes: > Hello, > > Given that you've expressed your preference for dev-lang/python > remaining slotted, I'd like to open another can of worms: should we slot > PyPy consistently with it? Some history and then my ideas below. I'm on board with this. It'd been on my mind for a whil

Re: [gentoo-dev] Slotting PyPy

Michał Górny writes: > On Sat, 2024-10-19 at 11:42 +0100, Sam James wrote: >> I think we should do it, but I have one question: I thought (I might be >> misremembering though) that one reason for the existing scheme was to >> allow easy testing of pypy versions for th

Re: [gentoo-dev] [COMMITTED] profiles: sync cpu_flags_x86 with cpuid2cpuflags

Ulrich Mueller writes: >>>>>> On Fri, 11 Oct 2024, Sam James wrote: > >> From: Paul Zander >> Signed-off-by: Paul Zander >> Closes: https://github.com/gentoo/gentoo/pull/38695 >> Signed-off-by: Sam James >> --- >> profiles/arch/amd

Re: [gentoo-dev] [PATCH] profiles/thirdpartymirrors: add final fallback for apache

Eli Schwartz writes: > Apache has a mirror network, which only covers the most recent release > of any given package. They also have an additional site which does not > appear to be a CDN, and is throttled and can maybe ban you if you use it > too much. Unfortunately, it is also the ONLY way to a

Re: [gentoo-dev] [PATCH 2/2] eclass/dotnet-pkg-base: add efsi function for running FSI

x...@gentoo.org writes: > From: Maciej Barć > > This will replace "edotnet fsi" as used in "app-shells/pwsh" package. > > Signed-off-by: Maciej Barć OK given people will likely forget nologo, so probably worth having. > --- > eclass/dotnet-pkg-base.eclass | 12 > 1 file changed,

Re: [gentoo-dev] Help needed for maintaining GNOME

Eli Schwartz writes: > On 9/25/24 1:47 PM, Mart Raudsepp wrote: >> Hello >> >> > [...] >> To my knowledge, one big issue right now is a circular dep between >> glib->gobject-introspection->glib, which needs proper solving to move >> forward with things. Or at least look at reducing the glib requ

Re: [gentoo-dev] Foreseen update to ada.eclass to allow use of gcc:14 and gcc:15

Alfredo Tupone writes: > diff --git a/eclass/ada.eclass b/eclass/ada.eclass > index 3c3fa3c01453..faff19a6ac85 100644 > --- a/eclass/ada.eclass > +++ b/eclass/ada.eclass > @@ -45,31 +45,31 @@ _ADA_ECLASS=1 > # dev-foo/mydep" > # DEPEND="${RDEPEND}" > # @CODE > # > # Example value: > # @CO

Re: [gentoo-dev] Updating community maintained Gentoo Eclipse IDE repository ebuild to EAPI 7

Kevin Brace writes: > Hi, Hi, > > I am a first time poster who just subscribed to the gentoo-dev mailing list. > I installed Eclipse IDE 4.6 to one Gentoo Linux installation using the > community maintained Eclipse IDE repository ebuild when Portage still > supported EAPI 6, but the current rele

Re: [gentoo-dev] [PATCH 1/3] [QA] fix .editorconfig

Paul Zander writes: > This series of patches is meant as a basis to fix the .editorconfig used in > ::gentoo. Initial reason was that .patch > files are being broken by the current version. > > trimming trailing whitespace breaks patches > > Signed-off-by: Paul Zander > --- > .editorconfig | 6

Re: [gentoo-dev] [PATCH 00/10] new eclass: rust; slotting dev-lang/rust{-bin}

kan...@gentoo.org writes: > From: Matt Jolly > > This patchset slots Rust, adds `rust.eclass`, a helper eclass for slotted > Rust, > and updates `cargo.eclass` to take advantage of the new slotted Rust, > requiring a > revbump of dependent packages. Thanks for doing this. As we've already dis

Re: [gentoo-dev] [PATCH 1/2] eclass/dotnet-pkg-base: turn off DOTNET_NUGET_SIGNATURE_VERIFICATION

x...@gentoo.org writes: > From: Maciej Barć > > Speeds up "dotnet restore". Especially can be noticed when running > without network sandbox. > Suggested by vimproved on IRC - thanks! > > See also: https://github.com/NuGet/Home/issues/13062 > > Signed-off-by: Maciej Barć lgtm > --- > eclass/d

Re: [gentoo-dev] [PATCH 1/2] sec-keys.eclass: new eclass

Michał Górny writes: > On Wed, 2024-11-27 at 15:30 -0500, Eli Schwartz wrote: >> The current state of verify-sig support is a bit awkward. We rely on >> validating distfiles against a known trusted keyring, but creating the >> known trusted keyring is basically all manual verification. We somehow

Re: [gentoo-dev] [PATCH 1/2] sec-keys.eclass: new eclass

Eli Schwartz writes: > The current state of verify-sig support is a bit awkward. We rely on > validating distfiles against a known trusted keyring, but creating the > known trusted keyring is basically all manual verification. We somehow > decide an ascii armored key is good enough without any po

Re: [gentoo-dev] [PATCH v2 1/2] sec-keys.eclass: new eclass

Eli Schwartz writes: > On 11/28/24 8:10 AM, Michał Górny wrote: >> On Wed, 2024-11-27 at 23:32 -0500, Eli Schwartz wrote: >> >> That looks like something you could do in src_compile() already. > > > Perhaps. But it felt like exporting keys is work that is conceptually > part of installing, in mu

Re: [gentoo-dev] [PATCH v2 1/2] sec-keys.eclass: new eclass

Michał Górny writes: > On Thu, 2024-11-28 at 16:56 +0000, Sam James wrote: >> Eli Schwartz writes: >> >> > On 11/28/24 8:10 AM, Michał Górny wrote: >> > > On Wed, 2024-11-27 at 23:32 -0500, Eli Schwartz wrote: >> > > >> > > Tha

[gentoo-dev] Last rites: sys-boot/woeusb

# Takuya Wakazono (2024-11-27) # Replaced by sys-boot/woeusb-ng, which has more recent upstream # activity and optional GUI support. # Removal on 2024-12-24. sys-boot/woeusb

Re: [gentoo-dev] [PATCH] rust.eclass: add ERUST_{SLOT,TYPE} user variables

kan...@gentoo.org writes: > From: Matt Jolly > > These variables enable users (though most likely Gentoo developers) > to override the selection of the Rust implementation by the eclass. > > This means that _only_ the specified ERUST_SLOT and/or ERUST_TYPE > ('source' or 'binary') will be checked

[gentoo-dev] [PATCH] profiles/default/linux: export cache variables for sed and friends

variables to avoid that. Bug: https://bugs.gentoo.org/927837 Bug: https://bugs.gentoo.org/927864 Bug: https://bugs.gentoo.org/935721 Signed-off-by: Sam James --- profiles/default/linux/make.defaults | 11 +++ 1 file changed, 11 insertions(+) diff --git a/profiles/default/linux/make.defaults

LLVM build strategy (was: Re: [gentoo-dev] [RFC] New categories for LLVM)

Michał Górny writes: > Hello, > > Given that the number of LLVM packages is growing, and probably will > grow again (I'm introducing "offload" right now, expect at least MLIR > soon, there are open requests for flang, polly...), I'd like to propose > creating dedicated categories for these packag

Re: [gentoo-dev] [RFC] New categories for LLVM

Michał Górny writes: > Hello, > > Given that the number of LLVM packages is growing, and probably will > grow again (I'm introducing "offload" right now, expect at least MLIR > soon, there are open requests for flang, polly...), I'd like to propose > creating dedicated categories for these packag

Re: [gentoo-dev] Bugs in pitivi ebuild

Grand Duet writes: > I emerged gsteamer with introspection use flag enabled and it did not help. > > I have just looked into > https://ports.freebsd.org/cgi/ports.cgi?query=pitivi&stype=all&sektion=all > and found out that media-libs/gstreamer-editing-services are also a > dependency of pitivi >

Re: [gentoo-dev] Bugs in pitivi ebuild

Grand Duet writes: > I emerged gsteamer with introspection use flag enabled and it did not help. and this is already a dependency too. > > I have just looked into > https://ports.freebsd.org/cgi/ports.cgi?query=pitivi&stype=all&sektion=all > and found out that media-libs/gstreamer-editing-servi

[gentoo-dev] Re: LLVM build strategy

Sam James writes: > Michał Górny writes: > >> Hello, >> >> Given that the number of LLVM packages is growing, and probably will >> grow again (I'm introducing "offload" right now, expect at least MLIR >> soon, there are open requests fo

<    4   5   6   7   8   9   10   >