[gentoo-dev] Re: FYI lists.gentoo.org upcoming migration - COMPLETED

On Sat, Jan 18, 2025 at 09:54:21PM -0800, Robin H. Johnson wrote: > Hi everybody, > (please send replies to gentoo-proj...@lists.gentoo.org) > > As an FYI only, what should be a low-impact change, the hosting location > of lists.gentoo.org will be changing. This migration has been completed. --

[gentoo-dev] Re: A new bugzilla keyword for bug investigation

Sam James posted on Sat, 18 Jan 2025 18:02:58 + as excerpted: > Agostino Sarubbo writes: > >> Good morning everyone, >> >> during tinderbox activity I realized that sometimes there are bugs with >> unknown causes at the time of filing. >> >> Examples are: >> >> - no "error: " string >> >> -

Re: [gentoo-dev] Re: Last-rites: net-im/psi and net-im/psimedia

On Samstag, 11. Jänner 2025 11:59:08 Mitteleuropäische Normalzeit Alexey Sokolov wrote: > The version in ::rion is maintained and uses qt6. Only though. Thanks, I've amended the package.mask notice accordingly. Regards signature.asc Description: This is a digitally signed message part.

[gentoo-dev] Re: Last-rites: net-im/psi and net-im/psimedia

11.01.2025 10:09, Andreas Sturmlechner пишет: > # Andreas Sturmlechner (2025-01-11) > # Last release from 2020, effectively unmaintained in Gentoo. > # Depends on Qt5, app-crypt/qca[qt5] and dev-qt/qtwebengine:5. > # Bugs #755446, #926138, #926670. Removal on 2025-02-10. > net-im/psi > net-im/psim

[gentoo-dev] Re: [PATCH 2/2] mono.eclass: mark as DEAD

On Fri, Jan 03, 2025 at 04:23:08PM +0100, Petr Vaněk wrote: > The eclass is no longer used by any package in the tree nor in ::dotnet > overlay. If there are no objections to this change, should I send the last-rite email now or once it is merged? Petr > Signed-off-by: Petr Vaněk > --- > eclas

[gentoo-dev] Re: [PATCH] guile-utils.eclass: set GUILE_AUTO_COMPILE=fresh

Arsen Arsenović writes: > Hi Sam, > > Sam James writes: > >> Noticed this when looking at app-office/gnucash which was disabling >> GUILE_AUTO_COMPILE entirely (see 72dbf2ec4049df11ad63576971883ee239eadb7f). >> >> We don't want Guile making decisions based on the system cache >> files. Always re

[gentoo-dev] Re: [PATCH] guile-utils.eclass: set GUILE_AUTO_COMPILE=fresh

Hi Sam, Sam James writes: > Noticed this when looking at app-office/gnucash which was disabling > GUILE_AUTO_COMPILE entirely (see 72dbf2ec4049df11ad63576971883ee239eadb7f). > > We don't want Guile making decisions based on the system cache > files. Always recompile so we're deterministic. > > S

[gentoo-dev] Re: Confirm unsubscribe from gentoo-dev@lists.gentoo.org

On Fri, Dec 20, 2024, at 18:29, gentoo-dev+h...@lists.gentoo.org wrote: > > > Somebody (and we hope it was you) has requested that the email address > be removed from the list. > > To confirm you want to do this, please send a message to > > which

Re: [gentoo-dev] Re: LLVM build strategy

On Sun, 2024-12-08 at 17:23 -0500, Eli Schwartz wrote: > On 12/8/24 4:45 PM, Sam James wrote: > > > I don't like the idea of spending hours building everything before I'm > > > even able to start running tests, just to learn that LLVM is broken > > > and there's no point in even starting to build t

Re: [gentoo-dev] Re: LLVM build strategy

On 12/8/24 4:45 PM, Sam James wrote: >> I don't like the idea of spending hours building everything before I'm >> even able to start running tests, just to learn that LLVM is broken >> and there's no point in even starting to build the rest. > > I don't follow this bit -- you need the new LLVM mer

[gentoo-dev] Re: LLVM build strategy

Michał Górny writes: > On Sun, 2024-12-08 at 04:53 +, Sam James wrote: >> I fear this sort of assumes we won't switch to monobuild any time soon. > > I don't see one precluding the other. Categories are cheap. Package > moves not necessarily, but switching to monorepo will be complete pain

[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 for flang, polly...), I'd like to propose >> creating dedicate

[gentoo-dev] Re: Bugs in pitivi ebuild

In FreeBSD both gsound and gstreamer are dependecies of the pitivi package. See: https://ports.freebsd.org/cgi/ports.cgi?query=pitivi&stype=all&sektion=all Why Gentoo pitivi ebuild is so special that these two packages are not considered to be dependencies of pitivi? сб, 7 дек. 2024 г. в 16:15, G

[gentoo-dev] Re: profiles/base/make.defaults: add XDG_DATA_DIRS & XDG_CONFIG_DIRS to ENV_UNSET

El mar, 06-08-2024 a las 13:27 -0400, Mike Gilbert escribió: > On Wed, Jul 17, 2024 at 2:57 PM Pacho Ramos wrote: > > > > Hello, > > > > This is a follow up from an older thread by leio in the mailing > > list: > > https://archives.gentoo.org/gentoo-dev/message/bf36c4c50f9c15db222faa6a66b0c6c9 >

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

On 12/10/24 15:03, Michał Górny wrote: emerge =python-3.14 would install both a non-freethreading and a freethreading version and it would satisfy 3_14 and 3_14t at the same. But that's not how PMs work? It would install only the "newer" version, which would probably mean freethreading, whic

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] Re: [RFC] Splitting dev-lang/python into per-slot packages, starting with 3.14

On Sat, 2024-10-12 at 17:30 +0500, Anna (cybertailor) Vyalkova wrote: > On 2024-10-12 11:13, Michał Górny wrote: > > 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

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

On Sat, 2024-10-12 at 15:00 +0200, Luca Barbato wrote: > On 12/10/24 11:13, Michał Górny wrote: > > 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

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

On 12/10/24 11:13, Michał Górny wrote: 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? potentially it

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

On 2024-10-12 11:13, Michał Górny wrote: 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? Absolutely n

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

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 proposed solution, if an user want

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

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. With your proposed solution, if an user wants to have any version of python what should ask to emerge? An alternative for free

[gentoo-dev] Re: [RFC] News item: Haskell destabilization

On Thu, Sep 26, 2024 at 9:51 PM Matt Turner wrote: > > Signed-off-by: Matt Turner > --- > GitHub PR with the keywording changes: > https://github.com/gentoo/gentoo/pull/38542 > > .../2024-09-27-haskell-destabilization.en.txt | 40 +++ > 1 file changed, 40 insertions(+) >

[gentoo-dev] Re: [PATCH] distutils-r1.eclasS: Switch scikit-build-core to build.verbose

On Tue, Sep 24, 2024 at 08:14:02AM +0200, Michał Górny wrote: > Replace `cmake.verbose` with `build.verbose`, following the change > in scikit-build-core 0.10. LGTM. There is a typo in commit subject, eclasS -> eclass. Petr

[gentoo-dev] Re: New project: Vulkan

On 17/09/24 16:55, Matt Turner wrote: I suggest making a new Vulkan project within Gentoo and moving these packages from x11@ maintainership to it: dev-cpp/robin-hood-hashing dev-util/glslang dev-util/spirv-headers dev-util/spirv-tools dev-util/volk dev-util/vulkan-headers dev-util/vulkan-tools

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

Hi, On 2024/09/13 12:22, Michael Orlitzky wrote: On 2024-09-11 17:23:16, Jaco Kroon wrote: 1.  Let users (myself included) just download and use that. 2.  We package the phar file rather than the individual deps. Yes, this is cheating.  Like using embedded libs, however, I've seen and observed

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

On 2024-09-11 17:23:16, Jaco Kroon wrote: > 1.  Let users (myself included) just download and use that. > 2.  We package the phar file rather than the individual deps. Yes, this > is cheating.  Like using embedded libs, however, I've seen and observed > that in some cases this makes more sense th

[gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

Jaco Kroon posted on Wed, 11 Sep 2024 09:33:10 +0200 as excerpted: > I missed this announcement, looking specifically for composer again. > > If I make the effort of bumping to newest version, is this something > that would be re-added to the tree? > > I note there were active security vulnerab

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

Hi Michael, Looks like we keep bumping into each other ... and not only on PHP packages. n 2024/09/11 13:26, Michael Orlitzky wrote: On Wed, 2024-09-11 at 09:33 +0200, Jaco Kroon wrote: Hi, I missed this announcement, looking specifically for composer again. If I make the effort of bumping t

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

On Wed, 2024-09-11 at 09:33 +0200, Jaco Kroon wrote: > Hi, > > I missed this announcement, looking specifically for composer again. > > If I make the effort of bumping to newest version, is this something > that would be re-added to the tree? I'd re-commit if you're interested in keeping up wit

[gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

Hi, I missed this announcement, looking specifically for composer again. If I make the effort of bumping to newest version, is this something that would be re-added to the tree? I note there were active security vulnerabilities under very specific conditions (composer.phar is exposed via htt

[gentoo-dev] Re: Last rites: eapi7-ver.eclass, eqawarn.eclass, versionator.eclass

> On Mon, 26 Aug 2024, Ulrich Mueller wrote: > Eclasses that support EAPI 6 only, which is no longer used in the > Gentoo repository. > Removal in 30 days, i.e. on 2024-09-25. Update from the local planning office (beware of the leopard!): Removal of these eclasses will be postponed to 2024-

[gentoo-dev] Re: [PATCH] rocm.eclass: add rocm_use_hipcc function and update example accordingly

Following the discussion in https://github.com/gentoo/gentoo/pull/37639, rocm_use_hipcc now creates ROCM_TARGET_LST to prevent GPU access during src_configure phase. Interdiff is below: diff -u b/eclass/rocm.eclass b/eclass/rocm.eclass --- b/eclass/rocm.eclass +++ b/eclass/rocm.eclass @@ -20,7 +20

[gentoo-dev] Re: profiles/base/make.defaults: add XDG_DATA_DIRS & XDG_CONFIG_DIRS to ENV_UNSET

On Wed, Jul 17, 2024 at 2:57 PM Pacho Ramos wrote: > > Hello, > > This is a follow up from an older thread by leio in the mailing list: > https://archives.gentoo.org/gentoo-dev/message/bf36c4c50f9c15db222faa6a66b0c6c9 > > The problem is that, at present time, we are getting more and more bugs > co

Re: [gentoo-dev] Re: [PATCH 2/2] rebar3.eclass: add new eclass

On 15/07/2024 04.39, Eli Schwartz wrote: On 7/10/24 11:38 PM, Anna (cybertailor) Vyalkova wrote: On 2024-07-10 09:19, Florian Schmaus wrote: From: Florian Schmaus Add a new eclass for dev-util/rebar:3, based on the work of Anna Vyalkova in ::guru (thanks!). There's also rebar3.eclass in lan

Re: [gentoo-dev] Re: [PATCH 2/2] rebar3.eclass: add new eclass

On 7/10/24 11:38 PM, Anna (cybertailor) Vyalkova wrote: > On 2024-07-10 09:19, Florian Schmaus wrote: >> From: Florian Schmaus >> >> Add a new eclass for dev-util/rebar:3, based on the work of Anna >> Vyalkova in ::guru (thanks!). > > There's also rebar3.eclass in lanodanOverlay, hereby CC-ing Ha

[gentoo-dev] Re: [PATCH 2/2] rebar3.eclass: add new eclass

On 2024-07-10 09:19, Florian Schmaus wrote: From: Florian Schmaus Add a new eclass for dev-util/rebar:3, based on the work of Anna Vyalkova in ::guru (thanks!). There's also rebar3.eclass in lanodanOverlay, hereby CC-ing Haelwenn on this. The Erlang/OTP ecosystem is moving to Rebar3. Upst

[gentoo-dev] Re: [gentoo-project] Council meeting 2024-07-21 - call for agenda items

On 02/07/2024 22.30, Ulrich Mueller wrote: > ... > > The agenda is still open for additional items that the council should > discuss or vote on. For agenda items, please respond to this message > on the gentoo-project mailing list. I want to pass the first plan from previous thread about the Vari

[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs

* Michał Górny schrieb am 28.06.24 um 13:12 Uhr: > Hi, > > Due to their maintainers retiring from Gentoo, the following packages > are now in need of a new maintainer: > > acct-group/syncthing > acct-user/stdiscosrv > acct-user/strelaysrv > acct-user/syncthing > net-p2p/syncthing I use this ever

Re: [gentoo-dev] Re: Notion of stable depgraph vs stable keywords (Re: Arch Status and Future Plans)

Duncan <1i5t5.dun...@cox.net> writes: > Sam James posted on Wed, 26 Jun 2024 01:06:12 +0100 as excerpted: > >> Arthur Zamarin writes: >> >>> As you all know, Gentoo supports many various arches, in various >>> degrees (stable, dev, exp). Let me explain those 3 statuses fast: >>> >>> * stable arc

[gentoo-dev] Re: Notion of stable depgraph vs stable keywords (Re: Arch Status and Future Plans)

Sam James posted on Wed, 26 Jun 2024 01:06:12 +0100 as excerpted: > Arthur Zamarin writes: > >> As you all know, Gentoo supports many various arches, in various >> degrees (stable, dev, exp). Let me explain those 3 statuses fast: >> >> * stable arch - meaning we have stable profile for this arch

Re: [gentoo-dev] Re: Arch Status and Future Plans

Hi all, As a 32bit user on many arches I'll try to answer Flow's question below. On Wed, 26 Jun 2024 at 07:38, Florian Schmaus wrote: > > Hi Arthur, > > thanks for taking the time to write this mail. > > On 25/06/2024 19.33, Arthur Zamarin wrote: > > x86 > > > > Stable 32-bit a

[gentoo-dev] Re: Arch Status and Future Plans

Am 26.06.24 um 09:38 schrieb Florian Schmaus: Hi Arthur, thanks for taking the time to write this mail. On 25/06/2024 19.33, Arthur Zamarin wrote: x86 Stable 32-bit arch. I'll be honest, I don't believe at all this should be stable arch anymore. I have the impression as we

[gentoo-dev] Re: Arch Status and Future Plans

Hi Arthur, thanks for taking the time to write this mail. On 25/06/2024 19.33, Arthur Zamarin wrote: x86 Stable 32-bit arch. I'll be honest, I don't believe at all this should be stable arch anymore. I have the impression as well. The time to drop stable keywords for x86 p

[gentoo-dev] Re: [PATCH v4] greadme.eclass: new eclass

Arthur Zamarin posted on Sun, 16 Jun 2024 21:15:25 +0300 as excerpted: > On 16/06/2024 18.51, Florian Schmaus wrote: >> This new eclass includes various improvements over the existing >> readme.gentoo-r1.eclass. > > So, some weird question from me - why is it called greadme? I can > understand wh

[gentoo-dev] Re: [PATCH 1/2] common-lisp-3.eclass: Support EAPI 8

> On Sat, 08 Jun 2024, Ulrich Müller wrote: > - [[ $# != 1 ]] && die "${FUNCNAME[0]} must receive exactly one argument" > + [[ $# = 1 ]] || die "${FUNCNAME[0]} must receive exactly one argument" Ten seconds after hitting send I notice that these should use -eq, not =. Also elsewhere

Re: [gentoo-dev] Re: Last rites: sec-keys/openpgp-keys-jiatan

Duncan <1i5t5.dun...@cox.net> writes: > Sam James posted on Wed, 29 May 2024 19:37:47 +0100 as excerpted: > >> # Sam James (2024-05-29) >> # OpenPGP key of malicious xz co-maintainer. This key is no longer used >> # by any ebuilds in tree. Removal on 2024-06-29. >> # Bug #928134. >> sec-keys/open

[gentoo-dev] Re: Last rites: sec-keys/openpgp-keys-jiatan

Sam James posted on Wed, 29 May 2024 19:37:47 +0100 as excerpted: > # Sam James (2024-05-29) > # OpenPGP key of malicious xz co-maintainer. This key is no longer used > # by any ebuilds in tree. Removal on 2024-06-29. > # Bug #928134. > sec-keys/openpgp-keys-jiatan I'd suggest adding the xzutils

Re: [gentoo-dev] Re: [PATCH 2/3] To build ada we need a c++ compiler too

Alfredo Tupone writes: > On Fri, 26 Apr 2024 10:29:43 +0200 > Arsen Arsenović wrote: > >> > is_ada() { >> >gcc-lang-supported ada || return 1 >> > - _tc_use_if_iuse ada >> > + _tc_use_if_iuse cxx && _tc_use_if_iuse ada >> >> Is this redundant? Would gcc-lang-supported c++ (called thro

[gentoo-dev] Re: [PATCH 2/3] To build ada we need a c++ compiler too

On Fri, 26 Apr 2024 10:29:43 +0200 Arsen Arsenović wrote: > > is_ada() { > > gcc-lang-supported ada || return 1 > > - _tc_use_if_iuse ada > > + _tc_use_if_iuse cxx && _tc_use_if_iuse ada > > Is this redundant? Would gcc-lang-supported c++ (called through the > ada support check) not

[gentoo-dev] Re: [PATCH 2/3] To build ada we need a c++ compiler too

Hi, Alfredo Tupone writes: > Signed-off-by: Alfredo Tupone > --- > eclass/toolchain.eclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass > index fd820f60f45d..f8e06fa39884 100644 > --- a/eclass/toolchain.eclass > +++

[gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo

Joonas Niilola posted on Thu, 11 Apr 2024 08:21:39 +0300 as excerpted: > I just want to point out you > may not have to edit ebuilds at all. If xz-utils is package.provided > portage should ignore the dependency without you removing the dep from > an ebuild. package.provided: YMMV, but here rath

[gentoo-dev] Re: Re: Update on the 23.0 profiles

* "Andreas K. Huettel" <2862978.mvXUDI8C0e @pinacolada> : Wrote on Sun, 07 Apr 2024 15:27:42 +0200: >> I see no way of migrating to 23.0 profile because of not-recompilable >> packages that are installed (over 4 years) which block --emptytree, >> and do not wish to be forced to migrate to merged-u

[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs

Hi All: I will help with the following packages, but if anyone is interested, feel free to join to co-maintain them.. Thanks On 12:01 Wed 03 Apr , Michał Górny wrote: > The following packages are up for grabs due to the inactivity of their > maintainers: > > acct-group/privoxy > acct-us

[gentoo-dev] Re: Update on the 23.0 profiles

Andreas K. Huettel posted on Sun, 07 Apr 2024 15:07:01 +0200 as excerpted: > Am Sonntag, 7. April 2024, 14:51:55 CEST schrieb Michael Orlitzky: [USE="lzma zstd" in 23.0 profiles] >> [R]emarkably bad timing. How it looks: Gentoo's response to the xz >> incident is to have me rebuild my entire sys

Re: [gentoo-dev] Re: Update on the 23.0 profiles

> I see no way of migrating to 23.0 profile because of not-recompilable > packages that are installed (over 4 years) which block --emptytree, > and do not wish to be forced to migrate to merged-usr on an openrc box > without a compelling need (on principle). That sounds a bit like self-inflicted p

[gentoo-dev] Re: Update on the 23.0 profiles

> Thanks for the update and the work on the 23.0 profiles. :) >> Most 17.x profiles have been downgraded to "exp". > I could imagine there is a reason to downgrade those back to 'exp', > could you elaborate a bit on that? > > Isn't it bit strange that a 'stable' profiles gets downgraded back to > '

[gentoo-dev] Re: [PATCH] efmtutil-sys: use ebegin/eend and log output

I just noticed two things seconds after sending the patch: Commit message is missing "texlive-common.eclass" prefix. On 04/04/2024 15.01, Florian Schmaus wrote: Use ebegin/eend and instead of redirecting the output to /dev/null capture stdout and stderr under a file under $T. Signed-off-by: Fl

[gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo

Michael Orlitzky posted on Wed, 03 Apr 2024 12:40:26 -0400 as excerpted: > On Wed, 2024-04-03 at 16:30 +0100, Eddie Chapman wrote: >> It does involve a relatively small hack and functionality previously >> provided by xz-utils is replaced by app-arch/p7zip. > > I did the same thing with app-arch/

[gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo

Kévin GASPARD DE RENEFORT posted on Wed, 3 Apr 2024 14:22:18 +0200 as excerpted: > Fork Gentoo, or any other distros, start a LFS… In fact, Gentoo has been forked in this way at least three times. The first time was over 20 years ago, before 2004 as I remember researching it before I switched

Re: [gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo

Sorry but I wanted to add something to what is written below: I'll insist as other did before: An other alternative would be to start your own overlay, push something to help Gentoo's dev, anything, because saying more or less "Do that because actually it's bad" is something rarely appreciated

Re: [gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo

Helping with any of these three would certainly be reasonable. But demanding a *LOT* of work to alternative-force an already attack-reverted package, when we actually KNOW about that one, it's reverted to pre-attack and there's likely to be no more mischief there /because/ everybody's looking

Re: [gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo

Duncan <1i5t5.dun...@cox.net> writes: > Eddie Chapman posted on Tue, 2 Apr 2024 20:32:41 +0100 as excerpted: > >> Yes, I have no issue with the format at all, just with the xz utils >> project. > > FWIW, feel free to do that bug-fix or package-bump if you'd rather instead > of reading this long t

[gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo

Eddie Chapman posted on Tue, 2 Apr 2024 20:32:41 +0100 as excerpted: > Yes, I have no issue with the format at all, just with the xz utils > project. FWIW, feel free to do that bug-fix or package-bump if you'd rather instead of reading this long thing! I won't complain! =:^) IMO... The thing i

[gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo

Dale posted on Sat, 30 Mar 2024 02:06:26 -0500 as excerpted: > Gentoo has some awesome devs. Agreed with the whole thing and the above is a bit of an aside from the thread, but it's worth repeating! Thanks devs! (And security contributors, infra providers, testers, tinder-box runners, bug rep

Re: [gentoo-dev] Re: Profile 23.0 testing with stages and binhost (part 2 of 2)

Am Samstag, 16. März 2024, 13:12:04 CET schrieb Duncan: > Andreas K. Huettel posted on Fri, 15 Mar 2024 19:12:54 +0100 as excerpted: > > > Note 3: amd64 now has CET turned on by default. > > https://docs.kernel.org/next/x86/shstk.html If you have already used the > > unannounced 23.0 profiles, you

[gentoo-dev] Re: Profile 23.0 testing with stages and binhost (part 2 of 2)

Andreas K. Huettel posted on Fri, 15 Mar 2024 19:12:54 +0100 as excerpted: > Note 3: amd64 now has CET turned on by default. > https://docs.kernel.org/next/x86/shstk.html If you have already used the > unannounced 23.0 profiles, you should wipe your package cache and emerge > -ev world now. There

Re: [gentoo-dev] Re: RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo

On 3/9/24 4:13 PM, Duncan wrote: > I'm not saying don't use gentoo -- I'm a gentooer after all -- I'm saying > gentoo simply isn't in a good position to condemn AI for its energy > inefficiency. In fact, I'd claim that in the Gentoo case there are > demonstrably more energy efficient practical

[gentoo-dev] Re: RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo

Michał Górny posted on Sat, 09 Mar 2024 16:04:58 +0100 as excerpted: > On Fri, 2024-03-08 at 03:59 +, Duncan wrote: >> Robin H. Johnson posted on Tue, 5 Mar 2024 06:12:06 + as excerpted: >> >> > The energy waste argument is also one that needs to be made >> > carefully: >> >> Indeed. In

Re: [gentoo-dev] Re: RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo

On Fri, 2024-03-08 at 03:59 +, Duncan wrote: > Robin H. Johnson posted on Tue, 5 Mar 2024 06:12:06 + as excerpted: > > > The energy waste argument is also one that needs to be made carefully: > > Indeed. In a Gentoo context, condemning AI for the computative energy > waste? Maybe someo

[gentoo-dev] Re: RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo

Robin H. Johnson posted on Tue, 5 Mar 2024 06:12:06 + as excerpted: > The energy waste argument is also one that needs to be made carefully: Indeed. In a Gentoo context, condemning AI for the computative energy waste? Maybe someone could argue that effectively. That someone isn't Gentoo.

Re: [gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

On Thu, 2024-02-29 at 15:21 +0100, Florian Schmaus wrote: > On 29/02/2024 15.08, Michael Orlitzky wrote: > > On Thu, 2024-02-29 at 14:47 +0100, Florian Schmaus wrote: > > > > > > > > +if [[ -z ${TL_PV} ]] \ > > > > + && [[ ${EAPI} -ge 8 ]] \ > > > > > > I am skeptical of this construc

Re: [gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

On 29/02/2024 15.34, Michael Orlitzky wrote: On Thu, 2024-02-29 at 15:21 +0100, Florian Schmaus wrote: The eclass only supports EAPIs {7,8,...} so it should suffice to blacklist EAPI=7. Fair point, but that would mean to remember to adjust this line once the eclass gets support for EAPI 9.

Re: [gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

On Thu, 2024-02-29 at 15:21 +0100, Florian Schmaus wrote: > > > > The eclass only supports EAPIs {7,8,...} so it should suffice to > > blacklist EAPI=7. > > Fair point, but that would mean to remember to adjust this line once the > eclass gets support for EAPI 9. > It should do the right thing

Re: [gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

On 29/02/2024 15.08, Michael Orlitzky wrote: On Thu, 2024-02-29 at 14:47 +0100, Florian Schmaus wrote: +if [[ -z ${TL_PV} ]] \ + && [[ ${EAPI} -ge 8 ]] \ I am skeptical of this construct, as in the past we had non-numeric EAPIs. So I may have to go with EAPI == 8 for now. Input ap

Re: [gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

On Thu, 2024-02-29 at 14:47 +0100, Florian Schmaus wrote: > > > > +if [[ -z ${TL_PV} ]] \ > > + && [[ ${EAPI} -ge 8 ]] \ > > I am skeptical of this construct, as in the past we had non-numeric > EAPIs. So I may have to go with EAPI == 8 for now. Input appreciated. > The eclass only sup

[gentoo-dev] Re: [PATCH 1/3] texlive-module.eclass: implicitly set TL_PV if not explicitly set

On 29/02/2024 14.38, Florian Schmaus wrote: Signed-off-by: Florian Schmaus --- eclass/texlive-module.eclass | 6 ++ 1 file changed, 6 insertions(+) diff --git a/eclass/texlive-module.eclass b/eclass/texlive-module.eclass index afcd4532975a..d1bf0f86185b 100644 --- a/eclass/texlive-module

Re: [gentoo-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item

On 27/02/2024 04:55, Duncan wrote: Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as excerpted: Removing sys-kernel/installkernel from your system WILL change the way kernels are installed by 'make install'! Instead of the versioned /boot/vmlinuz-x.y.z that you are used to, 'ma

Re: [gentoo-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item

On 2/26/24 10:55 PM, Duncan wrote: > Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as > excerpted: > >> Removing sys-kernel/installkernel from your system WILL change the way >> kernels are installed by 'make install'! Instead of the versioned >> /boot/vmlinuz-x.y.z that you are

[gentoo-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item

Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as excerpted: > Removing sys-kernel/installkernel from your system WILL change the way > kernels are installed by 'make install'! Instead of the versioned > /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply > copy b

[gentoo-dev] Re: [PATCH v2 3/5] meson.eclass: refactor src_configure into a setter function

On 2/20/24 1:14 AM, Eli Schwartz wrote: > +# Calculate the command line which meson should use, and other relevant > +# variables. Invoke via "${mesonargs[@]}" in the calling environment. > +# This function is called from meson_src_configure. I'm sure someone probably has a better name than "${m

Re: [gentoo-dev] Re: [PATCH] check-reqs.eclass: more disk checks

On Mon, 2024-02-19 at 22:14 +, Robin H. Johnson wrote: > On Mon, Feb 19, 2024 at 02:08:32PM -0800, Robin H. Johnson wrote: > > Allow checking more disk space, for users with many split volumes and > > ever-larger packages. > > > > gentoo-kernel-bin: > > / >=350MB/version (in /lib/modules)

[gentoo-dev] Re: [PATCH] check-reqs.eclass: more disk checks

On Mon, Feb 19, 2024 at 02:08:32PM -0800, Robin H. Johnson wrote: > Allow checking more disk space, for users with many split volumes and > ever-larger packages. > > gentoo-kernel-bin: > / >=350MB/version (in /lib/modules) > /boot >=40MB/version > > rust-bin: > /opt >=450MB/version Meta: Is

Re: [gentoo-dev] Re: Packages up for grabs due to developer inactivity

On 2/17/24 21:39, Holger Hoffstätte wrote: On 2024-02-14 10:49, Michał Górny wrote: net-dns/dnsdist I can proxymaint this since I occasionally report bugs/contribute to upstream. Will open a maintainer PR and version bump soon-ish. Thanks Holger, but I'm not retired and will retake maint

[gentoo-dev] Re: Packages up for grabs due to developer inactivity

On 2024-02-14 10:49, Michał Górny wrote: net-dns/dnsdist I can proxymaint this since I occasionally report bugs/contribute to upstream. Will open a maintainer PR and version bump soon-ish. cheers Holger

[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs due to developer inactivity

On Wed, 14 Feb 2024 10:49:57 +0100 Michał Górny wrote: > The following packages are now looking for a new maintainer, due to > their prior maintainer being inactive: > ML take this > dev-ml/ppx_cold > dev-ml/ppx_fixed_literal > dev-ml/ppx_module_timer > dev-ml/ppx_stable > dev-ml/ppx_string > d

[gentoo-dev] Re: [gentoo-dev-announce] More packages up for grabs due to developer inactivity

* Michał Górny schrieb am 14.02.24 um 11:38 Uhr: > Hello, > > The following packages are also left with no maintainer: I will take care of this: > sys-fs/zfs-auto-snapshot -- 0x8201F9436611ABF9 - 41C5 71F2 0535 7D66 2E71 6DAA 8201 F943 6611 ABF9 signature.asc Descripti

[gentoo-dev] Re: [gentoo-dev-announce] More packages up for grabs due to developer inactivity

On Wed, 14 Feb 2024 11:38:49 +0100, Michał Górny wrote : > Hello, > > The following packages are also left with no maintainer: > dev-util/google-perftools I had started to look into this one already, adding to my list > x11-misc/xssstate I use this one and should be low-maintenance -- Berna

[gentoo-dev] Re: [gentoo-dev-announce] x86 arch testing: please use -mfpmath=sse

Michał Górny writes: > [[PGP Signed Part:Undecided]] > Hello, > > TL;DR: when arch testing for x86, please use `-mfpmath=sse` (this may > require raising `-march=` to `pentium4` or newer, or adding `-msse2`. > > > The x86 architecture historically supports two floating-precision > arithmetic mod

Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-nds/nsscache

On Thu, 2024-01-25 at 07:40 +, Robin H. Johnson wrote: > On Wed, Jan 24, 2024 at 12:55:25PM +0100, Michał Górny wrote: > > # Michał Górny (2024-01-24) > > # No support for Python 3.11+.  No PEP517.  Tests are not enabled. > > # The current keyworded version is from 2019.  It was bumped in 2022

[gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-nds/nsscache

On Wed, Jan 24, 2024 at 12:55:25PM +0100, Michał Górny wrote: > # Michał Górny (2024-01-24) > # No support for Python 3.11+.  No PEP517.  Tests are not enabled. > # The current keyworded version is from 2019.  It was bumped in 2022 > # but it has not been keyworded since (pending "testing"). > # D

[gentoo-dev] Re: [PATCH] profiles: workaround sandbox bug with getcwd() configure test (gl_cv_func_getcwd_path_max)

Hi, Sam James writes: > Workaround for sandbox bug which causes this gnulib configure test to take > many real hours on slower machines, and certainly a huge amount of CPU hours > on others. > > Spoof the same result as configure gets on a modern glibc & musl system for > now. > > Bug: https://

Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: dev-build/bazel, sci-libs/keras, sci-libs/tensorflow, sci-libs/tensorflow-estimator, sci-visualization/tensorboard

On Thu, Jan 18, 2024 at 02:33:08PM +0100, Maciej Barć wrote: > A lot of Bazel bugs were just left to rot, even though they are invalid. > There are work from users to get Bazel to a reasonable state, see: > https://bugs.gentoo.org/918703 (plus comment #1) > > > # Unmasking this requires a sign-off

Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: dev-build/bazel, sci-libs/keras, sci-libs/tensorflow, sci-libs/tensorflow-estimator, sci-visualization/tensorboard

On Thu, 2024-01-18 at 14:33 +0100, Maciej Barć wrote: > A lot of Bazel bugs were just left to rot, even though they are > invalid. > There are work from users to get Bazel to a reasonable state, see: > https://bugs.gentoo.org/918703 (plus comment #1) > > > # Unmasking this requires a sign-off from

[gentoo-dev] Re: [gentoo-dev-announce] Last rites: dev-build/bazel, sci-libs/keras, sci-libs/tensorflow, sci-libs/tensorflow-estimator, sci-visualization/tensorboard

A lot of Bazel bugs were just left to rot, even though they are invalid. There are work from users to get Bazel to a reasonable state, see: https://bugs.gentoo.org/918703 (plus comment #1) # Unmasking this requires a sign-off from QA and treecleaners, since # these packages require a ton of ment

[gentoo-dev] Re: help

On 1/10/2024 6:51 AM, Sam James wrote: > > gentoo_bugs_p...@parallaxshift.com writes: > >> help > > ??? Whoops! Sorry about that. I brain farted and thought this was a mailinglist control e-mail address. And I'm on the digest, so I hadn't received my own stupidity sent back to myself yet.

[gentoo-dev] Re: [PATCH v2 2/3] add UNPACKER_NO_BANNER variable

On 09/01/2024 09.39, Florian Schmaus wrote: Signed-off-by: Florian Schmaus --- eclass/-cover-letter.patch | 49 eclass/0001-greadme.eclass-new-eclass.patch | 305 Ignore those to patch files. They are accidentally added to the commit. diff --git

[gentoo-dev] Re: [RFC] News item: LXD to lose access for its image server

On Mon, Dec 25, 2023 at 20:01:49 +0200, Joonas Niilola wrote: > ### Notes: Tried to keep this news item as concise as possible, > ### more information in #920527. > > > Title: LXD to lose access for its image server > Author: Joonas Niilola > Posted: 2023-12-28 > Revision: 1 > News-Item-Format:

[gentoo-dev] Re: Last rites: net-misc/drive

Hi, net-misc/insync::ppfeufer-gentoo-overlay is a sensible albeit proprietary alternative. Kind regards, Jaco On 2023/11/13 00:08, Zac Medico wrote: commit ba6f1c6fd9b9434bd2c07cf7233ee38cb6ab430a Author: Brian Harring AuthorDate: 2023-11-09 20:51:11 -0800 Commit: Zac Medico Commi

Re: [gentoo-dev] Re: Last rites: media-gfx/gmic

Zoltan Puskas writes: > [[PGP Signed Part:Undecided]] > On Fri, Oct 27, 2023 at 12:24:32PM +0100, Marek Szuba wrote: >> On 2023-10-26 02:29, Jonas Stein wrote: >> >> > this is a very powerful package with many users. >> >> ...but sadly, very few maintainers. It was m-n when I took it over 3 y

  1   2   3   4   5   6   7   8   9   10   >