Re: [gentoo-dev] Proposal for a Universal Remote-ID File
Ulrich Mueller writes: > [[PGP Signed Part:Undecided]] >> On Fri, 22 Sep 2023, Siddhanth Rathod wrote: > >> I'm writing to propose the creation of a universal remote-ID file >> within the api.git or gentoo.git in the metadata/ directory. >> Currently, we have eight different locations that require manual >> updates for any future changes, including my recent commit >> (https://gitweb.gentoo.org/proj/gentoolkit.git/commit/?id=5146d35eb97e2c1a8f7691e59c755ed14e858dd4) >> to gentoolkit and the rest seven as mentioned here >> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Upstream_remote-id_types. > >> By establishing a universal remote-ID file, we can streamline this >> process. Your thoughts and feedback on this proposal would be greatly >> appreciated.Also, Any preferences on format? > > My preference would be a simple text file with a table, similar to > files/uid-gid.txt in api.git. Then we could just modify the existing > tooling to generate the wiki page form it, and wouldn't need any special > tools to create the other files. Sounds ok. > > Alternatively, it could be in XML. While I'm not a large fan of XML, it > seems a natural choice here, because metadata.xml, the DTD, and the XML > and Relax-NG schemas are all from the XML world. > > Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Arthur Zamarin writes: > [[PGP Signed Part:Undecided]] > On 22/09/2023 17.50, Alex Boag-Munroe wrote: >> On Fri, 22 Sept 2023 at 15:37, Sam James wrote: >>> >>> >>> Alex Boag-Munroe writes: >>> >>>> Any reason for the parseable parts to not be in an established human >>>> readable/editable format? e.g. the config ini style format, or TOML? >>> >>> The only issue really is that depending on how it's done (do we do >>> it for the whole file, or just comments), it may need a new (profile) >>> EAPI which will take a while to implement and deploy. >>> >>> If it's just for comments, then we can do it immediately though. >>> >>>> >>>> To crib from the OP example with something configparser understands: >>>> [PREAMBLE] >>>> Timestamp: 2023-09-21 15:07:42+00:00 >>>> Author: Arthur Zamarin >>>> Justification: Very broken, no idea why packaged, need to drop ASAP. >>>> The project is done with supporting this package. >>>> Bugs: 667687, 667689 >>>> Removal Date: 2023-10-21 >>>> Packages: dev-lang/python >>>> >>>> The format is well documented already and simple to check for >>>> validity, so any GLEP would just need to cover correct keys/values. >>>> >>> >>> But yeah, I agree it's worth thinking about a proper format rather than >>> fragile text mangling going into the future. >>> >> Perhaps eventually it could/should be used for the whole file but as >> an interim/beginning there's no reason you couldn't start with >> comments: >> >> # [PREAMBLE] >> # Timestamp: 2023-09-21 15:07:42+00:00 >> # Author: Arthur Zamarin >> # Justification: Very broken, no idea why packaged, need to drop ASAP. >> # The project is done with supporting this package. >> # Bugs: 667687, 667689 >> # Packages: dev-lang/python >> dev-lang/python >> >> This simply adds a pre parse step of stripping the comments then >> feeding directly into configparser or probably more suitable, TOML >> since TOML has better syntax for directly delivering things like a >> "Packages:" key as a list. >> >> Redoing a bunch of package.* parsing probably wasn't in scope of the >> OP but I've always wondered and this felt an opportune moment to >> ask/suggest :) > > Thanks for the idea. Yes, it was out of scope such suggestions for me > originally, but thinking more about it, I take it more positively. > Please let me (and others) to consider it for some days, cause this is > very interesting proposal. Things to consider is how much effort it is > to file in future, which format to use, etc. > It's fine with me if we just go with the original for now, but I think the awkwardness (which is not your fault, but the nature of wrangling free-form text) of the specification shows that we should at some point move to something structured. But I don't consider it a blocker for doing something better than the status quo. Maybe we'll be better off just going straight for Exherbo-style p.mask in future: https://ciaranm.wordpress.com/2011/03/27/classifying-repository-masks/ Ultimately, text munging sucks and there's only so much we can do to polish it. But your original proposal is a good improvement on how things are now. >> -- >> Ninpo >>
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Ulrich Mueller writes: > [[PGP Signed Part:Undecided]] >> On Fri, 22 Sep 2023, Alex Boag-Munroe wrote: > >> Perhaps eventually it could/should be used for the whole file but as >> an interim/beginning there's no reason you couldn't start with >> comments: > >> # [PREAMBLE] >> # Timestamp: 2023-09-21 15:07:42+00:00 >> # Author: Arthur Zamarin >> # Justification: Very broken, no idea why packaged, need to drop ASAP. >> # The project is done with supporting this package. >> # Bugs: 667687, 667689 >> # Packages: dev-lang/python >> dev-lang/python > > And I thought my suggestion to use XML was far-fetched and an obvious > joke. :( This is rather disrespectful to someone (who is a new contributor as well) making a suggestion in earnest. You could've dropped this sentence and the rest of your critique would stand. Please consider phrasing in future. > > This seems rather restrictive, adds unnecessary redundancy, and would > make it hard to type an entry without the aid of special tools. > > Also, there are other files like use.mask which probably shouldn't have > a completely different format. Their entries often have the author/date > line plus a one line comment which says all that is needed. Adding > massive header blocks there would be excessive. > > IMHO Arthur's original proposal was fine. Let's not over-complicate > things. > > Ulrich > > [[End of PGP Signed Part]]
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Alex Boag-Munroe writes: > Any reason for the parseable parts to not be in an established human > readable/editable format? e.g. the config ini style format, or TOML? The only issue really is that depending on how it's done (do we do it for the whole file, or just comments), it may need a new (profile) EAPI which will take a while to implement and deploy. If it's just for comments, then we can do it immediately though. > > To crib from the OP example with something configparser understands: > [PREAMBLE] > Timestamp: 2023-09-21 15:07:42+00:00 > Author: Arthur Zamarin > Justification: Very broken, no idea why packaged, need to drop ASAP. > The project is done with supporting this package. > Bugs: 667687, 667689 > Removal Date: 2023-10-21 > Packages: dev-lang/python > > The format is well documented already and simple to check for > validity, so any GLEP would just need to cover correct keys/values. > But yeah, I agree it's worth thinking about a proper format rather than fragile text mangling going into the future. > Just a thought.
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Ulrich Mueller writes: >> On Fri, 22 Sep 2023, Ulrich Mueller wrote: > >> On Fri, 22 Sep 2023, Florian Schmaus wrote: >>> Some, including me, consider timestamps without timezone specifiers to >>> be in local time (either of the consumer or producer of the >>> timestamp). Hence, if you really must have UTC here, then at least >>> consider making it explicit my requiring the 'Z' timezone specifier >>> (which, if you want to be ISO compatible, probably means that the >>> timestamp must include HH:MM too). > >> How about converting package.mask to XML? The xs:date type would allow >> a date followed by a time zone [1]. > >> /me hides > > Seriously, this isn't a hill I am willing to die on. I still prefer UTC > there, but I'd be fine if the wording said "should" instead of "must". Yes, I want the UTC bit in there, but it's fine if it's "should" and not "must". I was trying to articulate that before but I didn't do so very clearly. > > Ulrich
Re: [gentoo-dev] Standard parsable format for profiles/package.mask file
Tim Harder writes: > On 2023-09-21 Thu 15:22, Ulrich Mueller wrote: >>> On Thu, 21 Sep 2023, Arthur Zamarin wrote: >>> Should it be a GLEP, I don't think so? But I'm unsure about it. We do >>> need to document it (for example header of that exact file). >> >>It shouldn't be too difficult to wrap this up as a GLEP. > > To me standardizing a format in Gentoo (outside of PMS-related > functionality) requires a GLEP or at the very least some semi-formal > documentation outside the file in question in a place like the > devmanual. Consider it due diligence of the process that allows people > writing code to target the format without having to chase details down > into code bases or mailing list threads. +1
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Ulrich Mueller writes:
> [[PGP Signed Part:Undecided]]
>> On Thu, 21 Sep 2023, Florian Schmaus wrote:
>
>>> The first line of the "#"-prefixed explanation block must be of the
>>> format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
>>> format -MM-DD, in UTC timezone.
>>
>
>> Can we drop this? Or, at least, relax this.
>
> I think UTC makes a lot of sense in an international context like ours.
> It also avoids flapping of the date between entries (i.e. a newer entry
> having an older date than the previous one).
Yes, I don't think we need to punish people for getting it wrong, but at
the same time, I'd like us to standardise on UTC - saying this as
someone who isn't in UTC half of the year.
That means others are free to correct it if they notice it's the
wrong date and so on.
>> I usually just enter my locale date here and like to avoid having to
>> think about that UTC is potentially in a different date. I also can
>> not remember any situation where the date being in UTC matters. Plus,
>> if you want accurate timestamps, then the git commit/author date is
>> here for you. :)
Users consume p.mask entries directly rather than via git.
[gentoo-dev] Up for grabs: packages from sultan's retirement
Packages up for grabs: acct-group/croc acct-user/croc app-misc/liquidctl dev-libs/hidapi dev-python/hidapi net-misc/croc
[gentoo-dev] [PATCH 2/2] perl-module.eclass: disable Canary::Stability
Canary::Stability emits very vocal warnings about "unsupported" Perl versions
even if they're fine in reality. It's not worth scaring our users over.
See https://metacpan.org/pod/Canary::Stability#ENVIRONMENT-VARIABLES.
Signed-off-by: Sam James
---
eclass/perl-module.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/perl-module.eclass b/eclass/perl-module.eclass
index 83f94865e0214..c9b690992f22d 100644
--- a/eclass/perl-module.eclass
+++ b/eclass/perl-module.eclass
@@ -220,6 +220,8 @@ perl-module_src_configure() {
[[ -z ${pm_echovar} ]] && export PERL_MM_USE_DEFAULT=1
# Disable ExtUtils::AutoInstall from prompting
export PERL_EXTUTILS_AUTOINSTALL="--skipdeps"
+ # Noisy and not really appropriate to show to the user in a PM
+ export PERL_CANARY_STABILITY_DISABLE=1
if [[ $(declare -p myconf 2>&-) != "declare -a myconf="* ]]; then
local myconf_local=(${myconf})
--
2.42.0
[gentoo-dev] [PATCH 1/2] perl-module.eclass: set NONINTERACTIVE_TESTING=1
See https://www.perlmonks.org/?node_id=1225311
I did consider the others, but:
* AUTOMATES_TESTING appears inappropriate for us, as it affects
exit codes and might mask failures if configuration is wrong.
* EXTENDED_TESTING is something we could consider if we had
some way to opt-in to expensive tests.
so just set NONINTERACTIVE_TESTING=1 for now, not the others mentioned
in the link.
Signed-off-by: Sam James
---
eclass/perl-module.eclass | 7 +++
1 file changed, 7 insertions(+)
diff --git a/eclass/perl-module.eclass b/eclass/perl-module.eclass
index e2b66e3b6f7d2..83f94865e0214 100644
--- a/eclass/perl-module.eclass
+++ b/eclass/perl-module.eclass
@@ -358,6 +358,13 @@ perl-module_src_test() {
export NO_NETWORK_TESTING=1
fi
+ # See https://www.perlmonks.org/?node_id=1225311
+ # * AUTOMATES_TESTING appears inappropriate for us, as it affects
+ # exit codes and might mask failures if configuration is wrong.
+ # * EXTENDED_TESTING is something we could consider if we had
+ # some way to opt-in to expensive tests.
+ export NONINTERACTIVE_TESTING=1
+
case ${EAPI} in
7)
;;
--
2.42.0
Re: [gentoo-dev] last rites: sys-fs/eudev
Oskari Pirhonen writes: > [[PGP Signed Part:Undecided]] > On Wed, Sep 13, 2023 at 03:10:51 -0500, Dale wrote: >> Andrew Ammerlaan wrote: >> > >> > And then another thing, how is it possible that so many people missed >> > the news item? They are displayed quite prominently I think, and >> > emerge will keep buggering you about it until it is marked as read. >> > Just wondering if there is something that can be improved here. >> > >> > Best regards, >> > Andrew >> >> >> I'm pretty good at reading the news items. I seem to recall that you >> see one only if it affects you, you have a package installed or >> something. So, if it shows up, it is best to take notice. That said, I >> don't recall seeing the news item either. I can't imagine me missing it >> but I also can't imagine me not taking action either. After all, (eu)dev >> is a important package. >> >> One thing is for sure, the name is rather obvious. The first word in >> the title is eudev. I have yet to figure out how I missed it. Given >> the number of people who did, could there have been a glitch and it >> didn't show for some weird reason? Has someone who understands the code >> checked to see if there was some typo that made it not show for most >> users? >> >> I do think this is worth looking into. It just seems odd. >> > > It's not impossible for a news item to have bugs. > > Somewhat recently, when the hardened toolchain changes were being made, > a news item was sent out recommending an `-e @world`. I knew it was > coming because I saw the drafts of the news item here (as well as > discussion on irc), so I was surprised when I didn't see it on my > laptop on the day of. But I did see it on my work machine. > > We managed to track it down to my work machine using the hardened > profile whereas my laptop is using the hardened/selinux profile, and > Portage didn't quite catch that as being relevant for both. FTR: since then, the Portage logic got fixed but I also used it as impetus to implement a bunch of tests for the news item logic which would've caught this and a few other problems. But definitely possible this happened here. > > - Oskari > > [[End of PGP Signed Part]]
[gentoo-dev] [PATCH 3/3] dev-libs/libsodium: use new verify-sig minisign support
Closes: https://bugs.gentoo.org/783066
Signed-off-by: Sam James
---
dev-libs/libsodium/libsodium-1.0.19-r1.ebuild | 20 +++
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/dev-libs/libsodium/libsodium-1.0.19-r1.ebuild
b/dev-libs/libsodium/libsodium-1.0.19-r1.ebuild
index cb3ef0373a0fa..d175a5ffc7f5a 100644
--- a/dev-libs/libsodium/libsodium-1.0.19-r1.ebuild
+++ b/dev-libs/libsodium/libsodium-1.0.19-r1.ebuild
@@ -3,7 +3,9 @@
EAPI=8
-inherit autotools multilib-minimal
+VERIFY_SIG_OPENPGP_KEY_PATH=/usr/share/openpgp-keys/libsodium.key
+VERIFY_SIG_METHOD=minisig
+inherit autotools multilib-minimal verify-sig
DESCRIPTION="Portable fork of NaCl, a higher-level cryptographic library"
HOMEPAGE="https://libsodium.org;
@@ -41,22 +43,6 @@ PATCHES=(
"${FILESDIR}"/${PN}-1.0.10-cpuflags.patch
)
-src_unpack() {
- # TODO: Could verify-sig.eclass support minisig? bug #783066
- MINISIGN_KEY="RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3"
-
- if use verify-sig ; then
- ebegin "Verifying signature using app-crypt/minisign"
- minisign -V \
- -P ${MINISIGN_KEY} \
- -x "${DISTDIR}"/${P}.tar.gz.minisig \
- -m "${DISTDIR}"/${P}.tar.gz
- eend $? || die "Failed to verify distfile using minisign!"
- fi
-
- default
-}
-
src_prepare() {
default
--
2.42.0
[gentoo-dev] [PATCH 2/3] sec-keys/minisig-keys-libsodium: new package, add 20230914
Signed-off-by: Sam James
---
.../metadata.xml | 0
.../minisig-keys-libsodium-20230914.ebuild} | 11 +--
2 files changed, 5 insertions(+), 6 deletions(-)
copy sec-keys/{openpgp-keys-adamspiers => minisig-keys-libsodium}/metadata.xml
(100%)
copy sec-keys/{openpgp-keys-karelzak/openpgp-keys-karelzak-20230517.ebuild =>
minisig-keys-libsodium/minisig-keys-libsodium-20230914.ebuild} (51%)
diff --git a/sec-keys/openpgp-keys-adamspiers/metadata.xml
b/sec-keys/minisig-keys-libsodium/metadata.xml
similarity index 100%
copy from sec-keys/openpgp-keys-adamspiers/metadata.xml
copy to sec-keys/minisig-keys-libsodium/metadata.xml
diff --git
a/sec-keys/openpgp-keys-karelzak/openpgp-keys-karelzak-20230517.ebuild
b/sec-keys/minisig-keys-libsodium/minisig-keys-libsodium-20230914.ebuild
similarity index 51%
copy from sec-keys/openpgp-keys-karelzak/openpgp-keys-karelzak-20230517.ebuild
copy to sec-keys/minisig-keys-libsodium/minisig-keys-libsodium-20230914.ebuild
index 524e114f27746..27bc79712eae6 100644
--- a/sec-keys/openpgp-keys-karelzak/openpgp-keys-karelzak-20230517.ebuild
+++ b/sec-keys/minisig-keys-libsodium/minisig-keys-libsodium-20230914.ebuild
@@ -3,10 +3,8 @@
EAPI=8
-DESCRIPTION="OpenPGP keys used by Karel Zak"
-HOMEPAGE="https://kzak.redcrew.org/doku.php?id=me;
-# Grabbed from HOMEPAGE but it's HTML
-SRC_URI="https://dev.gentoo.org/~sam/distfiles/${CATEGORY}/${PN}/${P}.asc;
+DESCRIPTION="OpenPGP keys used for libsodium"
+HOMEPAGE="https://doc.libsodium.org/installation#integrity-checking;
S="${WORKDIR}"
LICENSE="public-domain"
@@ -14,7 +12,8 @@ SLOT="0"
KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64
~riscv ~s390 ~sparc ~x86"
src_install() {
- local files=( ${A} )
insinto /usr/share/openpgp-keys
- newins - karelzak.asc < <(cat "${files[@]/#/${DISTDIR}/}" || die)
+ newins - libsodium.minisig <<-EOF
+ RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3
+ EOF
}
--
2.42.0
[gentoo-dev] [PATCH 1/3] verify-sig.eclass: minisig support
Closes: https://bugs.gentoo.org/783066
Signed-off-by: Sam James
---
eclass/verify-sig.eclass | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass
index 49557b633c87f..bb847bb80cc64 100644
--- a/eclass/verify-sig.eclass
+++ b/eclass/verify-sig.eclass
@@ -55,17 +55,22 @@ IUSE="verify-sig"
# @DESCRIPTION:
# Signature verification method to use. The allowed value are:
#
+# - minisig -- verify signatures with (base64) Ed25519 public key using
app-crypt/minisign
# - openpgp -- verify PGP signatures using app-crypt/gnupg (the default)
# - signify -- verify signatures with Ed25519 public key using
app-crypt/signify
: "${VERIFY_SIG_METHOD:=openpgp}"
case ${VERIFY_SIG_METHOD} in
+ minisig)
+ BDEPEND="verify-sig? ( app-crypt/minisign )"
+ ;;
openpgp)
BDEPEND="
verify-sig? (
app-crypt/gnupg
>=app-portage/gemato-16
- )"
+ )
+ "
;;
signify)
BDEPEND="verify-sig? ( app-crypt/signify )"
@@ -139,6 +144,10 @@ verify-sig_verify_detached() {
[[ ${file} == - ]] && filename='(stdin)'
einfo "Verifying ${filename} ..."
case ${VERIFY_SIG_METHOD} in
+ minisig)
+ minisign -V -P "$(<"${key}")" -x "${sig}" -m "${file}"
||
+ die "minisig signature verification failed"
+ ;;
openpgp)
# gpg can't handle very long TMPDIR
# https://bugs.gentoo.org/854492
@@ -198,6 +207,10 @@ verify-sig_verify_message() {
[[ ${file} == - ]] && filename='(stdin)'
einfo "Verifying ${filename} ..."
case ${VERIFY_SIG_METHOD} in
+ minisig)
+ minisign -V -P "$(<"${key}")" -x "${sig}" -o
"${output_file}" -m "${file}" ||
+ die "minisig signature verification failed"
+ ;;
openpgp)
# gpg can't handle very long TMPDIR
# https://bugs.gentoo.org/854492
@@ -356,7 +369,7 @@ verify-sig_src_unpack() {
# find all distfiles and signatures, and combine them
for f in ${A}; do
found=
- for suffix in .asc .sig; do
+ for suffix in .asc .sig .minisig; do
if [[ ${f} == *${suffix} ]]; then
signatures+=( "${f}" )
found=sig
--
2.42.0
Re: [gentoo-dev] New bootstrap-prefix global USE-flag and patch to llvm.eclass
Fabian Groffen writes:
> [[PGP Signed Part:Undecided]]
> On 12-09-2023 20:32:19 +0100, Alexey Sokolov wrote:
>> Bug: https://bugs.gentoo.org/758167
>> Full PR is at https://github.com/gentoo/gentoo/pull/32730
>>
>> Several LLVM packages require this early return, otherwise they fail to
>> build on Darwin. I'll also need this USE-flag for
>> sys-devel/clang-common, to distinguish between stage2 and stage3 of
>> bootstrap-prefix.sh to configure clang differently.
>>
>> --
>> Best regards,
>> Alexey "DarthGandalf" Sokolov
>
>> From de2bd1abc3e5c7607413633d132c604c6a801802 Mon Sep 17 00:00:00 2001
>> From: Alexey Sokolov
>> Date: Mon, 11 Sep 2023 23:26:49 +0100
>> Subject: [PATCH] llvm.eclass: add global USE flag bootstrap-prefix
>>
>> Mask it everywhere except for prefix profiles
>>
>> Without this, stage2's LLVM packages fail to build.
>>
>> Bug: https://bugs.gentoo.org/758167
>> Signed-off-by: Alexey Sokolov
>> ---
>> eclass/llvm.eclass| 7 +++
>> profiles/base/use.mask| 4
>> profiles/features/prefix/use.mask | 4
>> profiles/use.desc | 1 +
>> 4 files changed, 16 insertions(+)
>>
>> diff --git a/eclass/llvm.eclass b/eclass/llvm.eclass
>> index 8198650aad9a7..87c2cedb3a376 100644
>> --- a/eclass/llvm.eclass
>> +++ b/eclass/llvm.eclass
>> @@ -64,6 +64,8 @@ esac
>> if [[ ! ${_LLVM_ECLASS} ]]; then
>> _LLVM_ECLASS=1
>>
>> +IUSE="bootstrap-prefix"
>> +
>> # make sure that the versions installing straight into /usr/bin
>> # are uninstalled
>> DEPEND="!!sys-devel/llvm:0"
>> @@ -242,6 +244,11 @@ llvm_fix_tool_path() {
>> llvm_pkg_setup() {
>> debug-print-function ${FUNCNAME} "${@}"
>>
>> +if use bootstrap-prefix; then
>> +# AppleClang has unparseable version numbers, but it's
>> irrelevant anyway
>> +return
>> +fi
>> +
>
> I might misunderstand this, but is this USE-flag supposed to be set only
> during bootstrap, e.g. when host-provided Clang is used? If so, would
> it be possible to use has_version or something instead?
Another option is something I think we've done in the past - check
for use prefix and then some extra env var we set in the bootstrap
script.
I think I'd prefer either your idea or the one I just mention
to a USE, but I don't think I feel very strongly between any of it.
(but given mgorny isn't keen on the USE in the PR at
https://github.com/gentoo/gentoo/pull/32730,
that's a vote against it)
>
> Thanks,
> Fabian
>
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
Eli Schwartz writes:
> On 9/12/23 10:26 PM, Michał Górny wrote:
>> On Tue, 2023-09-12 at 22:07 -0400, Eli Schwartz wrote:
>>> On 9/12/23 3:56 PM, Ulrich Mueller wrote:
> On Tue, 12 Sep 2023, Eli Schwartz wrote:
> + mkdir -p "${BUILD_DIR}" || die
> + local -x
> DIST_EXTRA_CONFIG="${BUILD_DIR}/extra-setup.cfg"
> + cat > "${DIST_EXTRA_CONFIG}" <<-EOF
> + [build]
> + build_base = ${BUILD_DIR}/build
> +
> + [build_ext]
> + parallel = ${jobs}
> + EOF
"|| die" should also be added for the cat command.
>>>
>>>
>>> Redirecting output to a file in a directory you have just guaranteed to
>>> exist cannot fail.
>>
>> Eh, you make me prove you wrong:
>>
>> # cat > dupa <<-EOF
>> blahblah
>>> EOF
>> cat: write error: No space left on device
>
>
> ಠ_ಠ
>
> Is portage generally expected to successfully complete (including
> internal metadata write stages) when its workdir drive runs out of space
> partway through?
oh you
Re: [gentoo-dev] last rites: sys-fs/eudev
"Eddie Chapman" writes: > martin-kokos wrote: >> --- Original Message --- >> On Tuesday, September 12th, 2023 at 3:36 PM, Eddie Chapman >> wrote: >> >>> Sam James wrote: >>> >>>> "Eddie Chapman" ed...@ehuk.net writes: >>>> >>>>>>> So what's the situation with the current Gentoo maintainers? >>>>>>> Have >>>>>>> they disappeared? I often see on here packages being offered up >>>>>>> for grabs. Why hasn't there been a call to give others the >>>>>>> opportunity to volunteer as maintainers rather than going >>>>>>> straight to last riting the package? Or >>>>>>> has that happened and I've missed it, in which case I apologise. >>>>>> >>>>>> There was a year ago or so and nothing really came out of it. But >>>>>> see above wrt 'tags'. >>>>> >>>>> A year is a long time, there might well now be people willing to >>>>> take over maintaining it that were not willing to 1 year ago, if >>>>> that is what is required. >>>> >>>> They have a month to step up anyway, although that will involve >>>> upstream activity too. >>> >>> I see there was already a change in the tree yesterday that assumes >>> sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1, >>> sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually >>> been decided behind the scenes already? This starts to smell a little >>> ugly unless I've completely misunderstood something. I hope I'm wrong. >>> >>> One thing I don't understand: the Gentoo project page for eudev lists 4 >>> members including the lead, and FWICT they are mostly still active in >>> other areas of Gentoo (recent commits to the tree in other packages). >>> The >>> project lead is also an original author of eudev. I find it hard to >>> believe that all 4 of these people have completely lost interest in >>> eudev in Gentoo. Have any of these 4 maintainers publicly said >>> (anywhere) that >>> they are not interested in being maintainers anymore (which is fine if >>> that is the case)? We're not talking here about a lone maintainer of >>> some peripheral package that's disappeared leaving an orphaned package. >>> >>> I'm an outsider to Gentoo development (just a heavy user for over a >>> decade both personally and professionally) so I might have missed >>> something. I just find it puzzling. >> >> I don't understand why there is need to go off of *hints and clues* >> whether its active development or whether the project maintainers want to >> maintain it or not. The project lead has explained the original reason for >> eudev being part of base and why that reason has passed. Issue decided 2 >> years ago. >> >> https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.htm >> l >> >> If there were maintainers to suport it for 2 extra years, that's very >> nice of them. Speculating, without them, after their decision to >> last-rite and asking to support eudev indefinitely, without giving any >> insightful reason as to why, seems ... not a great way to motivate >> someone to do something extra for me. >> >> Martin >> > > Thank you Martin and Sam for pointing out to me the news item above from 2 > years ago, which for some reason I missed originally, so I wasn't aware > this is how the people listed as current maintainers felt. > > This seems like a crucial piece of information that was sadly omitted from > the original last rite message. > > Maybe there is a lesson here somewhere about communication and last riting > of core system packages. I've just pushed https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6d1669686c56dc7f05750d9b36db1c2f9001275a which I think should help. That's a fair point, thank you. It's also easy to forget that people might have missed an item etc.
Re: [gentoo-dev] last rites: sys-fs/eudev
"Eddie Chapman" writes: > Rich Freeman wrote: >> On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman wrote: >> >>> in Gentoo. Have any of these 4 maintainers publicly said (anywhere) >>> that they are not interested in being maintainers anymore (which is fine >>> if that is the case)? We're not talking here about a lone maintainer of >>> some peripheral package that's disappeared leaving an orphaned package. >> >> It isn't like somebody is censoring the lists or waging commit wars on >> the metadata.xml/mask file. If somebody was eager to maintain it I'm sure >> they'd have spoken up. >> >>> I'm an outsider to Gentoo development (just a heavy user for over a >>> decade both personally and professionally) so I might have missed >>> something. I just find it puzzling. >> >> I'm not puzzled by what is going on, or by your email, because it >> happens basically anytime a high-profile package is treecleaned. Yes, >> Gentoo is about choice, but somebody has to actually do work to make >> the choices viable. There are always more people interested in using >> software than maintaining it. The frustration is completely >> understandable, but also kinda unavoidable. > > It starts to bother me that so many people straight away assume that when > someone questions things it's because they are a frustrated user who just > wants everyone else to do the work for them. And the same old argument > keeps being repeated over and over again *as if they think that no one > gets it* apart from us devs. I've been a free & oss software user for over > 20 years and I find it very patronising whenever it happens. The reality > is that are very few people in this community that don't understand the > fundamentals of free software, that no one is being paid, no one is > obligated, we are all volunteers, well then why don't you do it, etc, etc. > I've never asked or expected anyone to actually step up and do the work > and if you read my messages you will see that I've never even implied it. > No, but other people in the thread have, and the expectation is others will read it too. This is one of those topics where in particular we get a lot of it. Suggestions of "something smelly" then do imply some of the things you're saying. We're used to conspiratorial suggestions with this topic too. >> Repo QA standards don't mean that it has to barely work for your >> specific use case. The package has to deal with compatibility issues with >> stuff you don't use as well, which is why maintaining a system package can >> be hard work. It is usually less of an issue for more ordinary >> applications, which tend to have fewer interactions. If it is "good >> enough" for you as it is, then just move it to a private overlay and keep >> using it. You probably would need to override a virtual or two as well. >> Or publish your work somewhere others can use >> it. > > I see, so again I just don't get it do I? I'm just a user who is in their > own little world and all they care about is what works for them, and I > don't think or understand anything about the bigger picture. I wouldn't read that much into it. Rich is always verbose (and I mean no insult there), he's just being explicit about the options. > >> -- >> Rich
Re: [gentoo-dev] last rites: sys-fs/eudev
Rich Freeman writes: > On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman wrote: >> in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that >> they are not interested in being maintainers anymore (which is fine if >> that is the case)? We're not talking here about a lone maintainer of some >> peripheral package that's disappeared leaving an orphaned package. > > It isn't like somebody is censoring the lists or waging commit wars on > the metadata.xml/mask file. If somebody was eager to maintain it I'm > sure they'd have spoken up. > >> I'm an outsider to Gentoo development (just a heavy user for over a decade >> both personally and professionally) so I might have missed something. I >> just find it puzzling. > > I'm not puzzled by what is going on, or by your email, because it > happens basically anytime a high-profile package is treecleaned. Yes, > Gentoo is about choice, but somebody has to actually do work to make > the choices viable. There are always more people interested in using > software than maintaining it. The frustration is completely > understandable, but also kinda unavoidable. > > Repo QA standards don't mean that it has to barely work for your > specific use case. The package has to deal with compatibility issues > with stuff you don't use as well, which is why maintaining a system > package can be hard work. It is usually less of an issue for more > ordinary applications, which tend to have fewer interactions. If it > is "good enough" for you as it is, then just move it to a private > overlay and keep using it. You probably would need to override a > virtual or two as well. Or publish your work somewhere others can use > it. Yes. We value having a coherent system with decent UX and we have to choose what we can support. Users are free to override those choices in local repositories - and if they want advice on the best way to do so, they're free to ask.
Re: [gentoo-dev] last rites: sys-fs/eudev
"Eddie Chapman" writes: > Sam James wrote: >> >> "Eddie Chapman" writes: >>>>> So what's the situation with the current Gentoo maintainers? Have >>>>> they disappeared? I often see on here packages being offered up for >>>>> grabs. Why >>>>> hasn't there been a call to give others the opportunity to volunteer >>>>> as maintainers rather than going straight to last riting the package? >>>>> Or >>>>> has that happened and I've missed it, in which case I apologise. >>>> >>>> There was a year ago or so and nothing really came out of it. But see >>>> above wrt 'tags'. >>> >>> A year is a long time, there might well now be people willing to take >>> over maintaining it that were not willing to 1 year ago, if that is what >>> is required. >> >> They have a month to step up anyway, although that will involve >> upstream activity too. > > I see there was already a change in the tree yesterday that assumes > sys-fs/eudev is going (commit d46677fd864b30315423c8364ca44db2de98e2a1, > sys-fs/mdadm/mdadm-4.2-r2, amd64 stable keyworded). Has this actually been > decided behind the scenes already? This starts to smell a little ugly > unless I've completely misunderstood something. I hope I'm wrong. I think someone just didn't want to bother waiting to clean it up there given it's unlikely anyone will bother taking it over. It's not exactly something which can't be undone. > > One thing I don't understand: the Gentoo project page for eudev lists 4 > members including the lead, and FWICT they are mostly still active in > other areas of Gentoo (recent commits to the tree in other packages). The > project lead is also an original author of eudev. blueness being the same person who wrote the news item last year saying it's dead and it no longer serves a purpose. > I find it hard to > believe that all 4 of these people have completely lost interest in eudev > in Gentoo. Have any of these 4 maintainers publicly said (anywhere) that > they are not interested in being maintainers anymore (which is fine if > that is the case)? We're not talking here about a lone maintainer of some > peripheral package that's disappeared leaving an orphaned package. > That happened really with the discussion w/ blueness et. al when it was last-rited (or before it was last-rited) originally.
Re: [gentoo-dev] last rites: sys-fs/eudev
"Eddie Chapman" writes: > Sam James wrote: >> >> "Eddie Chapman" writes: >> >>> Sam James wrote: >>>> >>>> Dale writes: >>>> >>>>> orbea wrote: >>>>>> On Mon, 11 Sep 2023 17:29:47 +0200 >>>>>> "Andreas K. Huettel" wrote: >>>>>> >>>>>>> Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: >>>>>>> >>>>>>>> Upstream is maintained still. >>>>>>>> >>>>>>>> https://github.com/eudev-project/eudev >>>>>>>> >>>>>>> No, it's not. >>>>>>> >>>>>> Based on what? It has several commits this year and is currently >>>>>> working on both of my systems. Is there something specific showing >>>>>> why its not maintained? >>>>> >>>>> On the link above it says this: >>>>> >>>>> On 2021-08-20 Gentoo decided to abandon eudev and a new project was >>>>> established on 2021-09-14 by Alpine, Devuan and Gentoo >>>>> contributors (alphabetical order). >>>>> >>>>> It seems to have a upstream that is active but no one is >>>>> maintaining it on Gentoo. Basically, it needs a Gentoo maintainer >>>>> now. It would seem given the time span that no one wants to take >>>>> it. >>>>> >>>>> Like others, I use it but didn't know it wasn't maintained >>>>> anymore. I hope someone will step up but if not, looks like we have >>>>> to use udev. >>>> >>>> No, see the linked bugs. Someone has to actually make it compatible >>>> with the tags API which software is starting to use. >>>> >>> It seems there is work still ongoing to that end: >>> https://github.com/eudev-project/eudev/issues/249 >>> >> That only adds a stub - which isn't guaranteed to work correctly. > > But what that boils down to in practise if it actually turns out to be > true: user's might have to make a choice between installing some > application that uses a new API call not supported by eudev, or installing > eudev. I believe portage can handle that just fine, it regularly tells me > that there is some package or another that cannot be installed at the same > time as some other package. I'm sure I could go and find plenty of other > packages in the tree that can be last rites as well, if the inclusion > criteria for any given package is that it works with every other package > in the tree. > Yes, and then users kept getting confused by it, like https://bugs.gentoo.org/913702 and its duplicates. I doubt you can find many other packages which claim to satisfy a library's API but only do so partially, like in the case here w/ virtual/libudev + eudev. >>> A quick look at the bug list in the original announcement today, they >>> appear to almost all be bugs for Gentoo maintainers to address rather >>> than upstream, and one or two it's questionable if they are actually >>> bugs. >> >> I've improved the mask message. > > Yes that is an improvement. > >>> I think it is a rather large stretch to claim that upstream is dead, >>> the evidence just doesn't show that. >>> >>> So what's the situation with the current Gentoo maintainers? Have they >>> disappeared? I often see on here packages being offered up for grabs. >>> Why >>> hasn't there been a call to give others the opportunity to volunteer as >>> maintainers rather than going straight tolast riting the package? Or >>> has that happened and I've missed it, in which case I apologise. >> >> There was a year ago or so and nothing really came out of it. But see >> above wrt 'tags'. > > A year is a long time, there might well now be people willing to take over > maintaining it that were not willing to 1 year ago, if that is what is > required. They have a month to step up anyway, although that will involve upstream activity too.
Re: [gentoo-dev] last rites: sys-fs/eudev
orbea writes: > On Mon, 11 Sep 2023 22:50:13 +0100 > Sam James wrote: > >> orbea writes: >> >> > On Mon, 11 Sep 2023 22:21:21 +0100 >> > Sam James wrote: >> > >> >> orbea writes: >> >> >> >> > On Mon, 11 Sep 2023 21:31:30 +0100 >> >> > Sam James wrote: >> >> > >> >> >> Dale writes: >> >> >> >> >> >> > orbea wrote: >> >> >> >> On Mon, 11 Sep 2023 17:29:47 +0200 >> >> >> >> "Andreas K. Huettel" wrote: >> >> >> >> >> >> >> >>> Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: >> >> >> >>> >> >> >> >>>> Upstream is maintained still. >> >> >> >>>> >> >> >> >>>> https://github.com/eudev-project/eudev >> >> >> >>>> >> >> >> >>> No, it's not. >> >> >> >>> >> >> >> >>> >> >> >> >> Based on what? It has several commits this year and is >> >> >> >> currently working on both of my systems. Is there something >> >> >> >> specific showing why its not maintained? >> >> >> >> >> >> >> >> . >> >> >> >> >> >> >> > >> >> >> > On the link above it says this: >> >> >> > >> >> >> > >> >> >> > On 2021-08-20 Gentoo decided to abandon eudev and a new >> >> >> > project was established on 2021-09-14 by Alpine, Devuan and >> >> >> > Gentoo contributors (alphabetical order). >> >> >> > >> >> >> > >> >> >> > It seems to have a upstream that is active but no one is >> >> >> > maintaining it on Gentoo. Basically, it needs a Gentoo >> >> >> > maintainer now. It would seem given the time span that no one >> >> >> > wants to take it. >> >> >> > >> >> >> > Like others, I use it but didn't know it wasn't maintained >> >> >> > anymore. I hope someone will step up but if not, looks like we >> >> >> > have to use udev. >> >> >> >> >> >> No, see the linked bugs. Someone has to actually make it >> >> >> compatible with the tags API which software is starting to use. >> >> >> >> >> > >> >> > I think its only a matter of time. >> >> > >> >> > https://github.com/eudev-project/eudev/pull/253 >> >> > >> >> > I'll apply the patch and test the builds if it helps, but I don't >> >> > know about testing the runtime functionality of libgudev. >> >> >> >> Someone has to then bother reviewing it, merging it, releasing it, >> >> and ideally updating eudev for other stuff like this. >> >> >> >> Also note that the PR is a hack rather than a full implementation >> >> of the functionality anyway, which may lead to runtime >> >> misbehaviour. >> > >> > According to upstream it implement's systemd's fallback path as >> > explained in this comment. >> > >> > https://github.com/eudev-project/eudev/issues/249#issuecomment-1675520914 >> > >> >> That same comment goes on to say it's the "quick-n-dirty" fix and may >> break applications. > > Slibtool also has no-op compatibility fixes that potentially could > cause issues too, I don't see this being a problem there. If eudev was > entirely broken or not being used I could understand why to remove it, > but rather this is removing software that mostly works and is being > used. With all due honesty is very disappointing to see this, I started > to use Gentoo because it offered choices. "mostly works" is generally not a great thing we want to endorse. slibtool is also a complete rewrite of libtool rather than a fork which is out of date and missing features that consumers start to expect from development. We also, importantly, don't drag in slibtool on user systems unless they explicitly request it and it doesn't wrongly satisfy dependencies on libtool itself. Someone being disappointed doesn't get work done. > >> >> > >> > However its fully possible to use Gentoo without requiring >> > sticky-tags so I don't really see the urgency that requires >> > removing software that has users that find it works for them. We >> > even have the most recent upstream release which came out only a >> > few months ago. >> >> >> >> > >> >> >> >> >> >> > >> >> >> > Dale >> >> >> > >> >> >> > :-) :-) >> >> >> >> >> >> >> >> >> >> >> >>
Re: [gentoo-dev] last rites: sys-fs/eudev
Alexe Stefan writes: > Must eudev be 100% compatible with all the garbage that gets shoved > into udev to stay in ::gentoo? I don't see mdev being held to that > standard. Please don't top-post. mdev is not a provider of virtual/libudev and doesn't pretend to be via its pkgconfig file. > > On 9/12/23, Alexey Sokolov wrote: >> 11.09.2023 22:35, Sam James пишет: >>> >>> Alexey Sokolov writes: >>> >>>> 11.09.2023 22:21, Sam James пишет: >>>>> orbea writes: >>>>> >>>>>> On Mon, 11 Sep 2023 21:31:30 +0100 >>>>>> Sam James wrote: >>>>>> >>>>>>> Dale writes: >>>>>>> >>>>>>>> orbea wrote: >>>>>>>>> On Mon, 11 Sep 2023 17:29:47 +0200 >>>>>>>>> "Andreas K. Huettel" wrote: >>>>>>>>> >>>>>>>>>> Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: >>>>>>>>>> >>>>>>>>>>> Upstream is maintained still. >>>>>>>>>>> >>>>>>>>>>> https://github.com/eudev-project/eudev >>>>>>>>>>> >>>>>>>>>> No, it's not. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Based on what? It has several commits this year and is currently >>>>>>>>> working on both of my systems. Is there something specific showing >>>>>>>>> why its not maintained? >>>>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>>> >>>>>>>> On the link above it says this: >>>>>>>> >>>>>>>> >>>>>>>> On 2021-08-20 Gentoo decided to abandon eudev and a new project was >>>>>>>> established on 2021-09-14 by Alpine, Devuan and Gentoo contributors >>>>>>>> (alphabetical order). >>>>>>>> >>>>>>>> >>>>>>>> It seems to have a upstream that is active but no one is >>>>>>>> maintaining it on Gentoo. Basically, it needs a Gentoo maintainer >>>>>>>> now. It would seem given the time span that no one wants to take >>>>>>>> it. >>>>>>>> >>>>>>>> Like others, I use it but didn't know it wasn't maintained anymore. >>>>>>>>I hope someone will step up but if not, looks like we have to use >>>>>>>> udev. >>>>>>> >>>>>>> No, see the linked bugs. Someone has to actually make it compatible >>>>>>> with the tags API which software is starting to use. >>>>>> >>>>>> I think its only a matter of time. >>>>>> >>>>>> https://github.com/eudev-project/eudev/pull/253 >>>>>> >>>>>> I'll apply the patch and test the builds if it helps, but I don't know >>>>>> about testing the runtime functionality of libgudev. >>>>> Someone has to then bother reviewing it, merging it, releasing it, >>>>> and >>>>> ideally updating eudev for other stuff like this. >>>> >>>> Of course. Just like any other PR to any other project :) What's your >>>> point? >>> >>> I don't know what you mean. My point is none of that has been happening. >>> >> >> I see, ok. I would agree with you, however, the author of that PR is a >> member of eudev org, so I wouldn't say it's dead just yet. >> >>>> >>>>> Also note that the PR is a hack rather than a full implementation >>>>> of the functionality anyway, which may lead to runtime misbehaviour. >>>> >>>> And that's fine for programs which don't make use of the new API. >>>> >>> >>> and? Someone has to actually check that? >>> >>> >>> >> >> -- >> Best regards, >> Alexey "DarthGandalf" Sokolov >> >> >>
Re: [gentoo-dev] last rites: sys-fs/eudev
orbea writes: > On Mon, 11 Sep 2023 22:21:21 +0100 > Sam James wrote: > >> orbea writes: >> >> > On Mon, 11 Sep 2023 21:31:30 +0100 >> > Sam James wrote: >> > >> >> Dale writes: >> >> >> >> > orbea wrote: >> >> >> On Mon, 11 Sep 2023 17:29:47 +0200 >> >> >> "Andreas K. Huettel" wrote: >> >> >> >> >> >>> Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: >> >> >>> >> >> >>>> Upstream is maintained still. >> >> >>>> >> >> >>>> https://github.com/eudev-project/eudev >> >> >>>> >> >> >>> No, it's not. >> >> >>> >> >> >>> >> >> >> Based on what? It has several commits this year and is currently >> >> >> working on both of my systems. Is there something specific >> >> >> showing why its not maintained? >> >> >> >> >> >> . >> >> >> >> >> > >> >> > On the link above it says this: >> >> > >> >> > >> >> > On 2021-08-20 Gentoo decided to abandon eudev and a new project >> >> > was established on 2021-09-14 by Alpine, Devuan and Gentoo >> >> > contributors (alphabetical order). >> >> > >> >> > >> >> > It seems to have a upstream that is active but no one is >> >> > maintaining it on Gentoo. Basically, it needs a Gentoo >> >> > maintainer now. It would seem given the time span that no one >> >> > wants to take it. >> >> > >> >> > Like others, I use it but didn't know it wasn't maintained >> >> > anymore. I hope someone will step up but if not, looks like we >> >> > have to use udev. >> >> >> >> No, see the linked bugs. Someone has to actually make it compatible >> >> with the tags API which software is starting to use. >> > >> > I think its only a matter of time. >> > >> > https://github.com/eudev-project/eudev/pull/253 >> > >> > I'll apply the patch and test the builds if it helps, but I don't >> > know about testing the runtime functionality of libgudev. >> >> Someone has to then bother reviewing it, merging it, releasing it, and >> ideally updating eudev for other stuff like this. >> >> Also note that the PR is a hack rather than a full implementation >> of the functionality anyway, which may lead to runtime misbehaviour. > > According to upstream it implement's systemd's fallback path as > explained in this comment. > > https://github.com/eudev-project/eudev/issues/249#issuecomment-1675520914 That same comment goes on to say it's the "quick-n-dirty" fix and may break applications. > > However its fully possible to use Gentoo without requiring sticky-tags > so I don't really see the urgency that requires removing software that > has users that find it works for them. We even have the most recent > upstream release which came out only a few months ago. > >> >> > >> >> >> >> > >> >> > Dale >> >> > >> >> > :-) :-) >> >> >> >> >> >>
Re: [gentoo-dev] last rites: sys-fs/eudev
"Eddie Chapman" writes: > Sam James wrote: >> >> Dale writes: >> >>> orbea wrote: >>>> On Mon, 11 Sep 2023 17:29:47 +0200 >>>> "Andreas K. Huettel" wrote: >>>> >>>>> Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: >>>>> >>>>>> Upstream is maintained still. >>>>>> >>>>>> https://github.com/eudev-project/eudev >>>>>> >>>>> No, it's not. >>>>> >>>> Based on what? It has several commits this year and is currently >>>> working on both of my systems. Is there something specific showing why >>>> its not maintained? >>> >>> On the link above it says this: >>> >>> On 2021-08-20 Gentoo decided to abandon eudev and a new project was >>> established on 2021-09-14 by Alpine, Devuan and Gentoo contributors >>> (alphabetical order). >>> >>> It seems to have a upstream that is active but no one is maintaining it >>> on Gentoo. Basically, it needs a Gentoo maintainer now. It would >>> seem given the time span that no one wants to take it. >>> >>> Like others, I use it but didn't know it wasn't maintained anymore. I >>> hope someone will step up but if not, looks like we have to use udev. >> >> No, see the linked bugs. Someone has to actually make it compatible >> with the tags API which software is starting to use. >> > > It seems there is work still ongoing to that end: > https://github.com/eudev-project/eudev/issues/249 That only adds a stub - which isn't guaranteed to work correctly. > > A quick look at the bug list in the original announcement today, they > appear to almost all be bugs for Gentoo maintainers to address rather than > upstream, and one or two it's questionable if they are actually bugs. I've improved the mask message. > > I think it is a rather large stretch to claim that upstream is dead, the > evidence just doesn't show that. > > So what's the situation with the current Gentoo maintainers? Have they > disappeared? I often see on here packages being offered up for grabs. Why > hasn't there been a call to give others the opportunity to volunteer as > maintainers rather than going straight to last riting the package? Or has > that happened and I've missed it, in which case I apologise. There was a year ago or so and nothing really came out of it. But see above wrt 'tags'.
Re: [gentoo-dev] last rites: sys-fs/eudev
Alexey Sokolov writes: > 11.09.2023 22:21, Sam James пишет: >> orbea writes: >> >>> On Mon, 11 Sep 2023 21:31:30 +0100 >>> Sam James wrote: >>> >>>> Dale writes: >>>> >>>>> orbea wrote: >>>>>> On Mon, 11 Sep 2023 17:29:47 +0200 >>>>>> "Andreas K. Huettel" wrote: >>>>>> >>>>>>> Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: >>>>>>> >>>>>>>> Upstream is maintained still. >>>>>>>> >>>>>>>> https://github.com/eudev-project/eudev >>>>>>>> >>>>>>> No, it's not. >>>>>>> >>>>>>> >>>>>> Based on what? It has several commits this year and is currently >>>>>> working on both of my systems. Is there something specific showing >>>>>> why its not maintained? >>>>>> >>>>>> . >>>>>> >>>>> >>>>> On the link above it says this: >>>>> >>>>> >>>>> On 2021-08-20 Gentoo decided to abandon eudev and a new project was >>>>> established on 2021-09-14 by Alpine, Devuan and Gentoo contributors >>>>> (alphabetical order). >>>>> >>>>> >>>>> It seems to have a upstream that is active but no one is >>>>> maintaining it on Gentoo. Basically, it needs a Gentoo maintainer >>>>> now. It would seem given the time span that no one wants to take >>>>> it. >>>>> >>>>> Like others, I use it but didn't know it wasn't maintained anymore. >>>>> I hope someone will step up but if not, looks like we have to use >>>>> udev. >>>> >>>> No, see the linked bugs. Someone has to actually make it compatible >>>> with the tags API which software is starting to use. >>> >>> I think its only a matter of time. >>> >>> https://github.com/eudev-project/eudev/pull/253 >>> >>> I'll apply the patch and test the builds if it helps, but I don't know >>> about testing the runtime functionality of libgudev. >> Someone has to then bother reviewing it, merging it, releasing it, >> and >> ideally updating eudev for other stuff like this. > > Of course. Just like any other PR to any other project :) What's your point? I don't know what you mean. My point is none of that has been happening. > >> Also note that the PR is a hack rather than a full implementation >> of the functionality anyway, which may lead to runtime misbehaviour. > > And that's fine for programs which don't make use of the new API. > and? Someone has to actually check that?
Re: [gentoo-dev] last rites: sys-fs/eudev
orbea writes: > On Mon, 11 Sep 2023 21:31:30 +0100 > Sam James wrote: > >> Dale writes: >> >> > orbea wrote: >> >> On Mon, 11 Sep 2023 17:29:47 +0200 >> >> "Andreas K. Huettel" wrote: >> >> >> >>> Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: >> >>> >> >>>> Upstream is maintained still. >> >>>> >> >>>> https://github.com/eudev-project/eudev >> >>>> >> >>> No, it's not. >> >>> >> >>> >> >> Based on what? It has several commits this year and is currently >> >> working on both of my systems. Is there something specific showing >> >> why its not maintained? >> >> >> >> . >> >> >> > >> > On the link above it says this: >> > >> > >> > On 2021-08-20 Gentoo decided to abandon eudev and a new project was >> > established on 2021-09-14 by Alpine, Devuan and Gentoo contributors >> > (alphabetical order). >> > >> > >> > It seems to have a upstream that is active but no one is >> > maintaining it on Gentoo. Basically, it needs a Gentoo maintainer >> > now. It would seem given the time span that no one wants to take >> > it. >> > >> > Like others, I use it but didn't know it wasn't maintained anymore. >> > I hope someone will step up but if not, looks like we have to use >> > udev. >> >> No, see the linked bugs. Someone has to actually make it compatible >> with the tags API which software is starting to use. > > I think its only a matter of time. > > https://github.com/eudev-project/eudev/pull/253 > > I'll apply the patch and test the builds if it helps, but I don't know > about testing the runtime functionality of libgudev. Someone has to then bother reviewing it, merging it, releasing it, and ideally updating eudev for other stuff like this. Also note that the PR is a hack rather than a full implementation of the functionality anyway, which may lead to runtime misbehaviour. > >> >> > >> > Dale >> > >> > :-) :-) >> >>
Re: [gentoo-dev] games-emulation/jgemu keywording request
orbea writes: > On Mon, 11 Sep 2023 16:21:43 -0400 > Mike Gilbert wrote: > >> On Mon, Sep 11, 2023 at 4:11 PM orbea wrote: >> > >> > On Mon, 11 Sep 2023 20:38:48 +0100 >> > Sam James wrote: >> > >> > > orbea writes: >> > > >> > > > On Mon, 11 Sep 2023 19:18:45 +0100 >> > > > Sam James wrote: >> > > > >> > > >> orbea writes: >> > > >> >> > > >> > Hi, >> > > >> > >> > > >> > Several months ago I made this issue for keywording the >> > > >> > games-emulation/jgemu meta package which is a collection of >> > > >> > minimal emulators for the command-line games-emulation/jgrf >> > > >> > frontend with a focus on accuracy. >> > > >> > >> > > >> >> > > >> You've not populated the package list and no arches are CC'd, >> > > >> but we don't keyword things for no reason either on (very) >> > > >> niche arches. >> > > >> >> > > >> Please select a reasonable set of architectures. >> > > >> >> > > >> > https://bugs.gentoo.org/891201 >> > > >> >> > > >> >> > > > >> > > > Apologies, I wasn't aware I needed to do that and in retrospect >> > > > I should of thought of it. Just to be clear you mean add an >> > > > issue for each issue and then use them as blockers for the >> > > > games-emulation/jgemu issue? >> > > >> > > No, one bug is okay if you populate the package list field in >> > > Bugzilla. >> > > >> > > Just keep in mind that keywording isn't the same as upstreaam CI >> > > either and we generally want to only keyword on arches where >> > > someone is likely to use it. >> > > >> > >> > Apologies, I now understand what you meant... >> > >> > The goal is to hopefully entice real world testers on systems that >> > jgemu may be used. This is not something a CI would be able to >> > accomplish. >> >> This is not an appropriate use of Gentoo arch testing. We keyword >> things based on user demand, not to satisfy the urges of upstream >> developers. >> > > Its a common occurrence that upstreams refuse to consider distros and > leave them hanging, but I honestly did not expect the inverse where the > distro is unwilling while the upstream is That doesn't mean we're able to start acting as CI. We already have enough test failures and build failures to handle for packages where people want to use them on alt-arches.
Re: [gentoo-dev] last rites: sys-fs/eudev
Dale writes: > orbea wrote: >> On Mon, 11 Sep 2023 17:29:47 +0200 >> "Andreas K. Huettel" wrote: >> >>> Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: >>> Upstream is maintained still. https://github.com/eudev-project/eudev >>> No, it's not. >>> >>> >> Based on what? It has several commits this year and is currently >> working on both of my systems. Is there something specific showing why >> its not maintained? >> >> . >> > > On the link above it says this: > > > On 2021-08-20 Gentoo decided to abandon eudev and a new project was > established on 2021-09-14 by Alpine, Devuan and Gentoo contributors > (alphabetical order). > > > It seems to have a upstream that is active but no one is maintaining it > on Gentoo. Basically, it needs a Gentoo maintainer now. It would seem > given the time span that no one wants to take it. > > Like others, I use it but didn't know it wasn't maintained anymore. I > hope someone will step up but if not, looks like we have to use udev. No, see the linked bugs. Someone has to actually make it compatible with the tags API which software is starting to use. > > Dale > > :-) :-)
Re: [gentoo-dev] games-emulation/jgemu keywording request
orbea writes: > On Mon, 11 Sep 2023 19:18:45 +0100 > Sam James wrote: > >> orbea writes: >> >> > Hi, >> > >> > Several months ago I made this issue for keywording the >> > games-emulation/jgemu meta package which is a collection of minimal >> > emulators for the command-line games-emulation/jgrf frontend with a >> > focus on accuracy. >> > >> >> You've not populated the package list and no arches are CC'd, but we >> don't keyword things for no reason either on (very) niche arches. >> >> Please select a reasonable set of architectures. >> >> > https://bugs.gentoo.org/891201 >> >> > > Apologies, I wasn't aware I needed to do that and in retrospect I > should of thought of it. Just to be clear you mean add an issue for > each issue and then use them as blockers for the games-emulation/jgemu > issue? No, one bug is okay if you populate the package list field in Bugzilla. Just keep in mind that keywording isn't the same as upstreaam CI either and we generally want to only keyword on arches where someone is likely to use it.
Re: [gentoo-dev] games-emulation/jgemu keywording request
orbea writes: > Hi, > > Several months ago I made this issue for keywording the > games-emulation/jgemu meta package which is a collection of minimal > emulators for the command-line games-emulation/jgrf frontend with a > focus on accuracy. > You've not populated the package list and no arches are CC'd, but we don't keyword things for no reason either on (very) niche arches. Please select a reasonable set of architectures. > https://bugs.gentoo.org/891201
Re: [gentoo-dev] [PATCH 2/2] x11-libs/wxGTK: egl USE flag for OpenGL on Wayland
Rafael Kitover writes:
> EGL is the only available OpenGL support on Wayland, so add the egl USE
> flag and do not add --disable-glcanvasegl to configure args if it is
> enabled.
>
> Explain the rationale for GLX being the default and the egl USE flag, as
> well as the upstream issue link to improve the situation in the ebuild
> comments.
>
> PR: https://github.com/gentoo/gentoo/pull/32452
Please tag the kicad bug which kicked this off with Bug:, as well as
any other relevant ones.
We want to try not make the same mistake as the original commits
which caused all this fuss, so more detail in the commit messages
would be good (although yours reads fine, just saying if you can
think of anything else).
>
> Signed-off-by: Rafael Kitover
> ---
> x11-libs/wxGTK/wxGTK-3.2.2.1-r3.ebuild | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/x11-libs/wxGTK/wxGTK-3.2.2.1-r3.ebuild
> b/x11-libs/wxGTK/wxGTK-3.2.2.1-r3.ebuild
> index 1411650e6df9..b6d95a3df4a5 100644
> --- a/x11-libs/wxGTK/wxGTK-3.2.2.1-r3.ebuild
> +++ b/x11-libs/wxGTK/wxGTK-3.2.2.1-r3.ebuild
> @@ -21,7 +21,7 @@ S="${WORKDIR}/wxWidgets-${PV}"
> LICENSE="wxWinLL-3 GPL-2 doc? ( wxWinFDL-3 )"
> SLOT="${WXRELEASE}"
> KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~mips ~ppc ~ppc64
> ~riscv ~sparc ~x86 ~amd64-linux ~x86-linux"
> -IUSE="+X curl doc debug keyring gstreamer libnotify +lzma opengl pch sdl
> +spell test tiff wayland webkit"
> +IUSE="+X curl doc debug keyring gstreamer libnotify +lzma opengl egl pch sdl
> +spell test tiff wayland webkit"
> REQUIRED_USE="test? ( tiff ) tiff? ( X ) spell? ( X ) keyring? ( X )"
> RESTRICT="!test? ( test )"
>
> @@ -146,8 +146,19 @@ multilib_src_configure() {
> --libdir='${prefix}'/$(get_libdir)
> )
>
> - # Switch to wxGLCanvas GLX instead of EGL, resolves many OpenGL issues.
> - myeconfargs+=( "--disable-glcanvasegl" )
> + # By default, we now build with the GLX GLCanvas because some software
> like
> + # PrusaSlicer does not yet support EGL. However, under Wayland EGL is
> the
> + # only working OpenGL implementation, so we allow the user to specify
> the
> + # egl USE flag to override this behavior and not disable the EGL
> GLCanvas.
> + #
> + # Upstream issue to improve this situation by instantiating the GLX
> + # GLCanvas under X11 dynamically:
> + #
> + # https://github.com/wxWidgets/wxWidgets/issues/23833
> + #
> + if ! use egl; then
> + myeconfargs+=( "--disable-glcanvasegl" )
> + fi
>
> # debug in >=2.9
> # there is no longer separate debug libraries (gtk2ud)
Re: [gentoo-dev] [PATCH v2 1/4] eclass/tests: Add initial tests for verify-sig
Michał Górny writes:
> Signed-off-by: Michał Górny
The lot lgtm with Bug/Closes tags for https://bugs.gentoo.org/913394.
> ---
> eclass/tests/verify-sig.sh | 65 ++
> 1 file changed, 65 insertions(+)
> create mode 100755 eclass/tests/verify-sig.sh
>
> diff --git a/eclass/tests/verify-sig.sh b/eclass/tests/verify-sig.sh
> new file mode 100755
> index ..fcd2ee7480a2
> --- /dev/null
> +++ b/eclass/tests/verify-sig.sh
> @@ -0,0 +1,65 @@
> +#!/bin/bash
> +# Copyright 2023 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=8
> +source tests-common.sh || exit
> +
> +inherit verify-sig
> +
> +TMP=$(mktemp -d)
> +trap 'rm -rf "${TMP}"' EXIT
> +cd "${TMP}" || die
> +> empty || die
> +> fail || die
> +echo "The quick brown fox jumps over the lazy dog." > text || die
> +
> +testit() {
> + local expect=${1}
> + shift
> +
> + tbegin "${*@Q}"
> + ( "${@}" )
> + [[ ${?} -eq ${expect} ]]
> + tend "${?}"
> +}
> +
> +test_verify_unsigned_checksums() {
> + local format=${1}
> +
> + testit 0 verify-sig_verify_unsigned_checksums checksums.txt "${format}"
> empty
> + testit 0 verify-sig_verify_unsigned_checksums checksums.txt "${format}"
> "empty text"
> + testit 1 verify-sig_verify_unsigned_checksums checksums.txt "${format}"
> other
> + testit 1 verify-sig_verify_unsigned_checksums checksums.txt "${format}"
> "empty other"
> + testit 1 verify-sig_verify_unsigned_checksums checksums.txt "${format}"
> fail
> + testit 1 verify-sig_verify_unsigned_checksums checksums.txt "${format}"
> "empty fail"
> +}
> +
> +einfo "Testing coreutils format."
> +eindent
> +
> +cat > checksums.txt <<-EOF || die
> + # some junk to test junk protection
> + b47cc0f104b62d4c7c30bcd68fd8e67613e287dc4ad8c310ef10cbadea9c4380 empty
> junk line
> + b47cc0f104b62d4c7c30bcd68gd8e67613e287dc4ad8c310ef10cbadea9c4380 empty
> +
> + # sha1sums
> + da39a3ee5e6b4b0d3255bfef95601890afd80709 empty
> + 9c04cd6372077e9b11f70ca111c9807dc7137e4btext
> + 9c04cd6372077e9b11f70ca111c9807dc7137e4b fail
> +
> + # sha256sums
> + e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 empty
> + b47cc0f104b62d4c7c30bcd68fd8e67613e287dc4ad8c310ef10cbadea9c4380
> text
> + b47cc0f104b62d4c7c30bcd68fd8e67613e287dc4ad8c310ef10cbadea9c4380 fail
> +
> + # sha512sums
> +
> cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
> empty
> +
> 020da0f4d8a4c8bfbc98274027740061d7df52ee07091ed6595a083e0f45327bbe59424312d86f218b74ed2e25507abaf5c7a5fcf4cafcf9538b705808fd55ec
> text
> +
> 020da0f4d8a4c8bfbc98274027740061d7df52ee07091ed6595a083e0f45327bbe59424312d86f218b74ed2e25507abaf5c7a5fcf4cafcf9538b705808fd55ec
> fail
> +EOF
> +
> +test_verify_unsigned_checksums sha256
> +eoutdent
> +
> +texit
[gentoo-dev] Last rites: dev-python/tweedledum
# Sam James (2023-08-30) # Used to be a dependency of dev-python/qiskit-aer but is now being phased # out. Fails to build with modern setuptools and >= Python 3.11. No upstream # activity. # Removal on 2023-09-29. Bug #911840, bug #896900. dev-python/tweedledum
[gentoo-dev] Last rites: net-im/ricochet
# Sam James (2023-08-29) # Obsolete as of September 2021 when legacy Tor hidden services stopped # working. Now fails to build with latest protobuf too. No upstream activity # since 2017. Alternatives (unvetted) are 'cwtch' and 'ricochet-refreshed' but # neither are packaged. # Removal on 2023-09-28. Bug #830477, bug #913004. net-im/ricochet
[gentoo-dev] Last rites: sci-biology/express
# Sam James (2023-08-29) # Fails to build with new protobuf. Deprecated by upstream which recommend # sci-biology/kallisto as a replacement. # Removal on 2023-09-28. Bug #912828. sci-biology/express
[gentoo-dev] [PATCH] tree-sitter-grammar.eclass: force use of local parser.h
There shouldn't be a system-wide copy of parser.h and upstream plan on
dropping this from dev-libs/tree-sitter as it can cause issues if there's
a mismatch between the version used for the bundled generated parser
vs the header used to build the library.
Force use of the correct one in the dist tarball at src/tree_sitter/parser.h
instead. Drop the dependency on dev-libs/tree-sitter given we were only
depending
on it for this header.
Bug: https://github.com/tree-sitter/tree-sitter-bash/issues/199
Bug: https://bugs.gentoo.org/912716
Signed-off-by: Sam James
---
eclass/tree-sitter-grammar.eclass | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/eclass/tree-sitter-grammar.eclass
b/eclass/tree-sitter-grammar.eclass
index e74d18653b8ad..b2563220cfc27 100644
--- a/eclass/tree-sitter-grammar.eclass
+++ b/eclass/tree-sitter-grammar.eclass
@@ -24,9 +24,6 @@
SRC_URI="https://github.com/tree-sitter/${PN}/archive/${TS_PV:-v${PV}}.tar.gz
-> ${P}.tar.gz"
S="${WORKDIR}"/${PN}-${TS_PV:-${PV}}/src
-# Needed for tree_sitter/parser.h
-DEPEND="dev-libs/tree-sitter"
-
BDEPEND+=" test? ( dev-util/tree-sitter-cli )"
IUSE+=" test"
RESTRICT+=" !test? ( test )"
@@ -61,8 +58,10 @@ tree-sitter-grammar_src_compile() {
# or scanner.cc.
tc-export CC CXX
- export CFLAGS="${CFLAGS} -fPIC"
- export CXXFLAGS="${CXXFLAGS} -fPIC"
+ # We want to use the bundled parser.h, not anything lurking on the
system, hence -I
+ # See
https://github.com/tree-sitter/tree-sitter-bash/issues/199#issuecomment-1694416505
+ export CFLAGS="${CFLAGS} -fPIC -I. -Itree_sitter"
+ export CXXFLAGS="${CXXFLAGS} -fPIC -I. -Itree_sitter"
local objects=( parser.o )
if [[ -f "${S}"/scanner.c || -f "${S}"/scanner.cc ]]; then
--
2.42.0
Re: [gentoo-dev] [PATCH] cmake.eclass: Remove duplicate eninja call from cmake_build
Michał Górny writes:
> Signed-off-by: Michał Górny
> ---
> eclass/cmake.eclass | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
> index fb3f9b6352be..d0f6d0b4bd91 100644
> --- a/eclass/cmake.eclass
> +++ b/eclass/cmake.eclass
> @@ -661,7 +661,6 @@ cmake_build() {
> OFF) NINJA_VERBOSE=OFF eninja "$@" ;;
> *) eninja "$@" ;;
> esac
> - eninja "$@"
> ;;
> esac
Maybe add a `Fixes: ...`, but lgtm, thanks.
[gentoo-dev] Last rites: app-emulation/libvirt-snmp
# Sam James (2023-08-22) # Broken with new net-analyzer/net-snmp, no reverse dependencies in Gentoo, # no other distros package this, and upstream have discontinued development. # Removal on 2023-09-21. Bug #912582. app-emulation/libvirt-snmp
[gentoo-dev] [PATCH] cmake.eclass: add CMAKE_SKIP_TESTS
From: Alfred Persson Forsberg
Signed-off-by: Alfred Persson Forsberg
Closes: https://github.com/gentoo/gentoo/pull/27052
Signed-off-by: Sam James
---
eclass/cmake.eclass | 7 +++
1 file changed, 7 insertions(+)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 16b3e300ccae0..fb3f9b6352be2 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -125,6 +125,12 @@ fi
# read-only. This is a user flag and should under _no circumstances_ be set in
# the ebuild. Helps in improving QA of build systems that write to source tree.
+# @ECLASS_VARIABLE: CMAKE_SKIP_TESTS
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Array of tests that should be skipped when running CTest.
+
[[ ${CMAKE_MIN_VERSION} ]] && die "CMAKE_MIN_VERSION is banned; if necessary,
set BDEPEND=\">=dev-util/cmake-${CMAKE_MIN_VERSION}\" directly"
[[ ${CMAKE_BUILD_DIR} ]] && die "The ebuild must be migrated to BUILD_DIR"
[[ ${CMAKE_REMOVE_MODULES} ]] && die "CMAKE_REMOVE_MODULES is banned, set
CMAKE_REMOVE_MODULES_LIST array instead"
@@ -681,6 +687,7 @@ cmake_src_test() {
[[ -e CTestTestfile.cmake ]] || { echo "No tests found. Skipping.";
return 0 ; }
[[ -n ${TEST_VERBOSE} ]] && myctestargs+=( --extra-verbose
--output-on-failure )
+ [[ -n ${CMAKE_SKIP_TESTS} ]] && myctestargs+=( -E '('$( IFS='|'; echo
"${CMAKE_SKIP_TESTS[*]}")')' )
set -- ctest -j "$(makeopts_jobs "${MAKEOPTS}" 999)" \
--test-load "$(makeopts_loadavg)" "${myctestargs[@]}" "$@"
--
2.41.0
Re: [gentoo-dev] Massive Github PR Queue
Joonas Niilola writes: > [[PGP Signed Part:Undecided]] > On 11.8.2023 17.07, orbea wrote: >> Hi, >> >> Currently the Gentoo Github PR queue is at 577 open PRs that even >> includes one that has been left open in 2018 and neglected since 2021. > > That's a bit misleading. The PR in question is opened by a Gentoo > developer, and labeled as "do-not-merge". So maybe they lost interest, > or forgot? Ping in the PR if you want to see it finished. But there are > indeed tons of PRs open from 2020. > > >> >> While not trying to be rude before contributing to Gentoo I was involved >> with Slackbuilds.org for Slackware where everything gets reviewed once >> a week with only a handful of maintainers doing the reviewing process. > > We also have 32,000 PRs closed, while slackbuild is at 3000. And here > also only handful of members are putting effort in general PR review. So > I'd say we're doing pretty good in that regard. > juippis' whole email nails the issue, but I'd just like to add that there's kind of a baseline at ~400/~450 or so where everything below that is PRs for new packages or long-obsolete stuff nobody closed yet, or where we're waiting on the submitter. It's just that going ahead and going over those is time-consuming and means we're spending less time on active PRs which need looking at. as for bz: it's far harder to review something on bz and if everyone did that for their contributions, any backlog (which you can't easily measure on bz either) would be far larger. > [...]
Re: [gentoo-dev] [PATCH] cargo.eclass: use CARGO_CRATE_URIS if already available
Michał Górny writes:
> On Mon, 2023-07-31 at 12:41 +0200, Florian Schmaus wrote:
>> With 59dbfb80f748 ("cargo.eclass: Add variable alternative to
>> $(cargo_crate_uris)") the _cargo_set_crate_uris function was
>> introduced. This function runs when the elcass is inherited and sets
>> CARGO_CRATE_URIS.
>>
>> Ebuilds that use $(cargo_crate_uris) in SRC_URI will again invoke this
>> function, even though CARGO_CRATE_URIS is already set. Avoiding this
>> unnecessary computation reduces the ebuild source time of
>> app-shells/nushell-0.83.0 from 21 ms to 14 ms.
>>
>> This is a significant reduction when compared to the variable-setting
>> alternative that the commit 59dbfb80f748 ("cargo.eclass: Add variable
>> alternative to $(cargo_crate_uris)") introduced. Using the
>> variable-setting approach would reduce the ebuild source time only by a
>> little bit more than one millisecond.
>>
>> Using
>>
>> pk pkg source --bench 10s '=app-shells/nushell-0.83.0'
>>
>> as benchmark, yields
>>
>> > | Cached CARGO_CRATE_URIS | Non-Cached
>> > CARGO_CRATE_URIS |
>> > ---+-+-|
>> > $(cargo_crate_uris) | mean: 14.189ms | mean: 21.445ms
>> >|
>> > variable-setting approach | mean: 12.822ms | mean: 12.852ms
>> >|
>>
>> full benchmark output
>>
>> > | Cached CARGO_CRATE_URIS (this commit)
>> > | Non-Cached CARGO_CRATE_URIS
>> > |
>> > ---+--+--|
>> > $(cargo_crate_uris) | mean: 14.189ms, min: 13.646ms, max: 15.103ms,
>> > σ = 149µs, N = 705 | mean: 21.445ms, min: 20.79ms, max: 22.832ms, σ =
>> > 228µs, N = 467 |
>> > variable-setting approach | mean: 12.822ms, min: 12.41ms, max: 13.909ms,
>> > σ = 165µs, N = 780 | mean: 12.852ms, min: 12.367ms, max: 15.437ms, σ =
>> > 227µs, N = 779 |
>>
>> Signed-off-by: Florian Schmaus
>> ---
>> eclass/cargo.eclass | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
>> index 70b6008d9cd8..5d6911801097 100644
>> --- a/eclass/cargo.eclass
>> +++ b/eclass/cargo.eclass
>> @@ -240,6 +240,14 @@ _cargo_set_crate_uris "${CRATES}"
>> # Constructs a list of crates from its arguments.
>> # If no arguments are provided, it uses the CRATES variable.
>> cargo_crate_uris() {
>> +# Use already existing value for CARGO_CRATE_URIS, computed by
>> +# _cargo_set_crate_uris, when this function is invoked without
>> +# arguments.
>> +if [[ $# -eq 0 && -n "${CARGO_CRATE_URIS}" ]]; then
>> +echo "${CARGO_CRATE_URIS}"
>> +return
>> +fi
>> +
>> local crates=${*-${CRATES}}
>> if [[ -z ${crates} ]]; then
>> eerror "CRATES variable is not defined and nothing passed as
>> argument"
>
> This incorrectly assumes that the value of CRATES did not change which
> isn't guaranteed anywhere.
Ah, thanks! Now I remember - we discussed it before and rejected it for
this reason.
Re: [gentoo-dev] [PATCH] cargo.eclass: use CARGO_CRATE_URIS if already available
Florian Schmaus writes:
> With 59dbfb80f748 ("cargo.eclass: Add variable alternative to
> $(cargo_crate_uris)") the _cargo_set_crate_uris function was
> introduced. This function runs when the elcass is inherited and sets
> CARGO_CRATE_URIS.
(I would've CC'd mgorny given presumably you want his input as the
author.)
> Ebuilds that use $(cargo_crate_uris) in SRC_URI will again invoke this
> function, even though CARGO_CRATE_URIS is already set. Avoiding this
> unnecessary computation reduces the ebuild source time of
> app-shells/nushell-0.83.0 from 21 ms to 14 ms.
>
> This is a significant reduction when compared to the variable-setting
> alternative that the commit 59dbfb80f748 ("cargo.eclass: Add variable
> alternative to $(cargo_crate_uris)") introduced. Using the
> variable-setting approach would reduce the ebuild source time only by a
> little bit more than one millisecond.
>
> Using
>
> pk pkg source --bench 10s '=app-shells/nushell-0.83.0'
>
> as benchmark, yields
>
> | | Cached CARGO_CRATE_URIS | Non-Cached
> CARGO_CRATE_URIS |
> |---+-+-|
> | $(cargo_crate_uris) | mean: 14.189ms | mean: 21.445ms
> |
> | variable-setting approach | mean: 12.822ms | mean: 12.852ms
> |
>
> full benchmark output
>
> | | Cached CARGO_CRATE_URIS (this commit)
> | Non-Cached CARGO_CRATE_URIS
> |
> |---+--+--|
> | $(cargo_crate_uris) | mean: 14.189ms, min: 13.646ms, max: 15.103ms, σ
> = 149µs, N = 705 | mean: 21.445ms, min: 20.79ms, max: 22.832ms, σ = 228µs, N
> = 467 |
> | variable-setting approach | mean: 12.822ms, min: 12.41ms, max: 13.909ms, σ
> = 165µs, N = 780 | mean: 12.852ms, min: 12.367ms, max: 15.437ms, σ = 227µs, N
> = 779 |
>
Anyway, nice work, this seems reasonable, and it's consistent with the
kind of thing I've done for Ruby. But let's see what mgorny says as
well.
> Signed-off-by: Florian Schmaus
> ---
> eclass/cargo.eclass | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index 70b6008d9cd8..5d6911801097 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -240,6 +240,14 @@ _cargo_set_crate_uris "${CRATES}"
> # Constructs a list of crates from its arguments.
> # If no arguments are provided, it uses the CRATES variable.
> cargo_crate_uris() {
> + # Use already existing value for CARGO_CRATE_URIS, computed by
> + # _cargo_set_crate_uris, when this function is invoked without
> + # arguments.
> + if [[ $# -eq 0 && -n "${CARGO_CRATE_URIS}" ]]; then
> + echo "${CARGO_CRATE_URIS}"
> + return
> + fi
> +
> local crates=${*-${CRATES}}
> if [[ -z ${crates} ]]; then
> eerror "CRATES variable is not defined and nothing passed as
> argument"
Re: [gentoo-dev] [PATCH 1/7] eclass/nuget.eclass: introduce new eclass
Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > On 31/07/2023 11.32, Sam James wrote: >> Florian Schmaus writes: >> >>> [[PGP Signed Part:Undecided]] >>> On 31/07/2023 07.02, Michał Górny wrote: >>>> On Sun, 2023-07-30 at 22:19 +0200, Florian Schmaus wrote: >>>>> Which problem are we solving by moving away from this towards a slightly >>>>> more verbose construct? >>>> The problem was that cargo.eclass ebuilds were taking significant >>>> time >>>> during cache regeneration and slowing down tools noticeably. No fancy >>>> loops required, contrary to your great theory. >>> >>> Removing the $()/fork from go-modules.eclass reduced the source time >>> of a package from 2400 milliseconds to 236 milliseconds. >>> >>> Changing, for example net-p2p/arti-1.1.6, to use _cargo_set_crate_uris >>> reduces the source time from 44 milliseconds to 24 milliseconds. >>> >>> That is a win in relative reduction, but absolute its just 20 >>> milliseconds. Cache regeneration is an embarrassingly parallel >>> problem. Therefore such a reduction should not matter much, assuming >>> you have some parallelism on the hardware level. >> Consistency matters > > Sure, I would be in favor of consistently using $(foo_uris). Too late for that. Please don't reopen the cargo.eclass issue unnecessarily. > > Especially since the performance gains of the variable-setting > approach are even lower than I first assumed. The cargo.eclass runs > the function that computes CARGO_CRATE_URIS now twice, which adds > significantly more overhead than the fork of $(foo_uris). See my patch > to the ML. > >> and I already raised the point last week as well. > > Here on the mailing list, or somewhere else? > Here on the mailing list.
Re: [gentoo-dev] [PATCH 1/7] eclass/nuget.eclass: introduce new eclass
Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > On 31/07/2023 07.02, Michał Górny wrote: >> On Sun, 2023-07-30 at 22:19 +0200, Florian Schmaus wrote: >>> Which problem are we solving by moving away from this towards a slightly >>> more verbose construct? >> The problem was that cargo.eclass ebuilds were taking significant >> time >> during cache regeneration and slowing down tools noticeably. No fancy >> loops required, contrary to your great theory. > > Removing the $()/fork from go-modules.eclass reduced the source time > of a package from 2400 milliseconds to 236 milliseconds. > > Changing, for example net-p2p/arti-1.1.6, to use _cargo_set_crate_uris > reduces the source time from 44 milliseconds to 24 milliseconds. > > That is a win in relative reduction, but absolute its just 20 > milliseconds. Cache regeneration is an embarrassingly parallel > problem. Therefore such a reduction should not matter much, assuming > you have some parallelism on the hardware level. Consistency matters and I already raised the point last week as well.
Re: [gentoo-dev] [PATCH 1/3] multiprocessing.eclass: search also GNUMAKEFLAGS for --load-average
Florian Schmaus writes:
> [[PGP Signed Part:Undecided]]
> On 25/07/2023 10.32, Michał Górny wrote:
>> On Tue, 2023-07-25 at 08:26 +0200, Florian Schmaus wrote:
>>> On 25/07/2023 06.50, Michał Górny wrote:
On Mon, 2023-07-24 at 20:57 +0200, Florian Schmaus wrote:
> Since --load-average may not be found in other Make implementations
> besides GNU MAKE, it is potentially found in GNUMAKEFLAGS and not in
> MAKEOPTS.
>
> Signed-off-by: Florian Schmaus
> ---
>eclass/multiprocessing.eclass | 6 +++---
>1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
> index e55be636a02c..6489ecbb44a6 100644
> --- a/eclass/multiprocessing.eclass
> +++ b/eclass/multiprocessing.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2022 Gentoo Authors
> +# Copyright 1999-2023 Gentoo Authors
># Distributed under the terms of the GNU General Public License v2
> # @ECLASS: multiprocessing.eclass
> @@ -86,7 +86,7 @@ makeopts_jobs() {
># @FUNCTION: makeopts_loadavg
># @USAGE: [${MAKEOPTS}] [${inf:-999}]
># @DESCRIPTION:
> -# Searches the arguments (defaults to ${MAKEOPTS}) and extracts the
> value set
> +# Searches the arguments (defaults to ${MAKEOPTS} ${GNUMAKEFLAGS}) and
> extracts the value set
># for load-average. For make and ninja based builds this will mean new
> jobs are
># not only limited by the jobs-value, but also by the current load -
> which might
># get excessive due to I/O and not just due to CPU load.
> @@ -95,7 +95,7 @@ makeopts_jobs() {
># If no limit is specified or --load-average is used without a number,
> ${inf}
># (defaults to 999) is returned.
>makeopts_loadavg() {
> - [[ $# -eq 0 ]] && set -- "${MAKEOPTS}"
> + [[ $# -eq 0 ]] && set -- "${MAKEOPTS} ${GNUMAKEFLAGS}"
> # This assumes the first .* will be more greedy than the second
> .*
> # since POSIX doesn't specify a non-greedy match (i.e. ".*?").
> local lavg=$(echo " $* " | sed -r -n \
I'm pretty sure [GNU]MAKEFLAGS has incompatible format, in particular it
makes hyphens optional.
>>>
>>> Yes, hyphens are optional in GNUMAKEFLAGS.
>>>
>>> However, makeopts_loadavg() would still be able to extract the
>>> hyphen-prefixed short (-l) and long (--load-average) options from
>>> GNUMAKEFLAGS. Hence having makeopts_loadavg() also inspect GNUMAKEFLAGS
>>> seems like an improvement over the current situation.
>>>
>> Also, shouldn't you handle MAKEFLAGS then as well? If we're to
>> support
>> arbitrary variables used by build systems.
>
> We could.
>
> But GNUMAKEFLAGS was not arbitrary chosen. The idea is that portage
> may set --load-average via GNUMAKEFLAGS if the user did not set
> MAKEOPTS and GNUMAKEFLAGS.
>
> See https://github.com/gentoo/portage/pull/1072
>
> I first put --load-average into MAKEOPTS, but --load-average is not a
> portable make option, that is, some Make implementation do not support
> it. Adding it to GNUMAKEFLAGS, a variable already set by portage, we
> avoid passing this option to a make implementation that does not
> support it.
>
> Hence, just adding GNUMAKEFLAGS is sufficient for the purpose of
> propagating portage's potential new default into
> multiprocessing.eclass & Co.
But this exposed a problem in that we're missing other variables
that make recognises, so we need to handle the other case too.
Re: [gentoo-dev] [RFC PATCH] metadata: Add gnome package stabilization groups
Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > On 19/07/2023 18.10, Matt Turner wrote: >> Signed-off-by: Matt Turner >> --- >> Feel free to bikeshed the location, structure, file-format, etc. >> metadata/stabilization-groups/gnome/evolution | 3 +++ >> metadata/stabilization-groups/gnome/glib | 3 +++ >> metadata/stabilization-groups/gnome/gnome-shell | 4 >> metadata/stabilization-groups/gnome/gobject-introspection | 2 ++ >> metadata/stabilization-groups/gnome/sysprof | 3 +++ >> metadata/stabilization-groups/gnome/vala | 2 ++ >> metadata/stabilization-groups/gnome/vte | 3 +++ >> 7 files changed, 20 insertions(+) >> create mode 100644 metadata/stabilization-groups/gnome/evolution >> create mode 100644 metadata/stabilization-groups/gnome/glib >> create mode 100644 metadata/stabilization-groups/gnome/gnome-shell >> create mode 100644 >> metadata/stabilization-groups/gnome/gobject-introspection >> create mode 100644 metadata/stabilization-groups/gnome/sysprof >> create mode 100644 metadata/stabilization-groups/gnome/vala >> create mode 100644 metadata/stabilization-groups/gnome/vte >> diff --git a/metadata/stabilization-groups/gnome/evolution >> b/metadata/stabilization-groups/gnome/evolution >> new file mode 100644 >> index ..21bbcf804e94 >> --- /dev/null >> +++ b/metadata/stabilization-groups/gnome/evolution >> @@ -0,0 +1,3 @@ >> +gnome-extra/evolution-data-server >> +gnome-extra/evolution-ews >> +mail-client/evolution >> diff --git a/metadata/stabilization-groups/gnome/glib >> b/metadata/stabilization-groups/gnome/glib >> new file mode 100644 >> index ..51a5659dd725 >> --- /dev/null >> +++ b/metadata/stabilization-groups/gnome/glib >> @@ -0,0 +1,3 @@ >> +dev-libs/glib >> +dev-util/gdbus-codegen >> +dev-util/glib-utils >> diff --git a/metadata/stabilization-groups/gnome/gnome-shell >> b/metadata/stabilization-groups/gnome/gnome-shell >> new file mode 100644 >> index ..ddf76f8f88f4 >> --- /dev/null >> +++ b/metadata/stabilization-groups/gnome/gnome-shell >> @@ -0,0 +1,4 @@ >> +gnome-base/gnome-shell >> +gnome-extra/gnome-shell-extensions >> +gnome-extra/gnome-shell-frippery >> +x11-wm/mutter >> diff --git a/metadata/stabilization-groups/gnome/gobject-introspection >> b/metadata/stabilization-groups/gnome/gobject-introspection >> new file mode 100644 >> index ..8baf4ae59124 >> --- /dev/null >> +++ b/metadata/stabilization-groups/gnome/gobject-introspection >> @@ -0,0 +1,2 @@ >> +dev-libs/gobject-introspection >> +dev-libs/gobject-introspection-common >> diff --git a/metadata/stabilization-groups/gnome/sysprof >> b/metadata/stabilization-groups/gnome/sysprof >> new file mode 100644 >> index ..66a338916039 >> --- /dev/null >> +++ b/metadata/stabilization-groups/gnome/sysprof >> @@ -0,0 +1,3 @@ >> +dev-util/sysprof >> +dev-util/sysprof-capture >> +dev-util/sysprof-common >> diff --git a/metadata/stabilization-groups/gnome/vala >> b/metadata/stabilization-groups/gnome/vala >> new file mode 100644 >> index ..2e4d5a33748d >> --- /dev/null >> +++ b/metadata/stabilization-groups/gnome/vala >> @@ -0,0 +1,2 @@ >> +dev-lang/vala >> +dev-libs/vala-common >> diff --git a/metadata/stabilization-groups/gnome/vte >> b/metadata/stabilization-groups/gnome/vte >> new file mode 100644 >> index ..ce25ab265262 >> --- /dev/null >> +++ b/metadata/stabilization-groups/gnome/vte >> @@ -0,0 +1,3 @@ >> +gui-libs/vte >> +gui-libs/vte-common >> +x11-libs/vte > > > Couldn't stabilization groups be package sets? For example, instead of > > metadata/stabilization-groups/gnome/vte > > you have > > sets/stable-group-gnome-vte > > with the exact same content (may requires that :;gentoo declares a > sets.conf). This then ends up polluting users' list of sets, e.g. when they run `emerge --list-sets`, or `emerge @`, and so on. It had occurred to me but I decided not to suggest it for this reason. Also, these groups aren't necessarily going to be things users should emerge directly at all (e.g. related libraries). signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 4/6] kernel-install.eclass: kernel-install_get_qemu_arch: port to sparc
Ulrich Mueller writes:
> [[PGP Signed Part:Undecided]]
>>>>>> On Fri, 21 Jul 2023, Sam James wrote:
>
>> @@ -162,6 +162,12 @@ kernel-install_get_qemu_arch() {
>> ppc64)
>> echo ppc64
>> ;;
>> +sparc)
>> +echo sparc
>> +;;
>> +sparc64)
>> +echo sparc64
>> +;;
>> riscv)
>> echo riscv
>> ;;
>
> Looks like the case patterns are in alphabetical order everywhere else,
> so why not here?
It was late and I forgot the alphabet ;)
I'll fix that locally.
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH 6/6] virtual/dist-kernel: keyword ~sparc
Signed-off-by: Sam James
---
virtual/dist-kernel/dist-kernel-5.15.120.ebuild | 2 +-
virtual/dist-kernel/dist-kernel-6.1.39.ebuild | 2 +-
virtual/dist-kernel/dist-kernel-6.4.4.ebuild| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/virtual/dist-kernel/dist-kernel-5.15.120.ebuild
b/virtual/dist-kernel/dist-kernel-5.15.120.ebuild
index 5fe06a3498482..eab6f8597102c 100644
--- a/virtual/dist-kernel/dist-kernel-5.15.120.ebuild
+++ b/virtual/dist-kernel/dist-kernel-5.15.120.ebuild
@@ -9,7 +9,7 @@ SRC_URI=""
LICENSE=""
SLOT="0/${PV}"
-KEYWORDS="amd64 ~arm arm64 ~hppa ~ppc ppc64 x86"
+KEYWORDS="amd64 ~arm arm64 ~hppa ~ppc ppc64 ~sparc x86"
RDEPEND="
|| (
diff --git a/virtual/dist-kernel/dist-kernel-6.1.39.ebuild
b/virtual/dist-kernel/dist-kernel-6.1.39.ebuild
index d3f0fa8764cf5..8012e544096f9 100644
--- a/virtual/dist-kernel/dist-kernel-6.1.39.ebuild
+++ b/virtual/dist-kernel/dist-kernel-6.1.39.ebuild
@@ -9,7 +9,7 @@ SRC_URI=""
LICENSE=""
SLOT="0/${PV}"
-KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~riscv ~x86"
+KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~riscv ~sparc ~x86"
RDEPEND="
|| (
diff --git a/virtual/dist-kernel/dist-kernel-6.4.4.ebuild
b/virtual/dist-kernel/dist-kernel-6.4.4.ebuild
index d3f0fa8764cf5..8012e544096f9 100644
--- a/virtual/dist-kernel/dist-kernel-6.4.4.ebuild
+++ b/virtual/dist-kernel/dist-kernel-6.4.4.ebuild
@@ -9,7 +9,7 @@ SRC_URI=""
LICENSE=""
SLOT="0/${PV}"
-KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~riscv ~x86"
+KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~riscv ~sparc ~x86"
RDEPEND="
|| (
--
2.41.0
[gentoo-dev] [PATCH 5/6] sys-kernel/gentoo-kernel: port to sparc
Signed-off-by: Sam James
---
profiles/arch/sparc/package.use.mask | 5 +
.../gentoo-kernel/gentoo-kernel-5.15.120.ebuild | 11 +--
sys-kernel/gentoo-kernel/gentoo-kernel-6.1.39.ebuild | 12 +---
sys-kernel/gentoo-kernel/gentoo-kernel-6.4.4.ebuild | 12 +---
4 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/profiles/arch/sparc/package.use.mask
b/profiles/arch/sparc/package.use.mask
index 666be07eea63a..0d1e5ce3fb0fd 100644
--- a/profiles/arch/sparc/package.use.mask
+++ b/profiles/arch/sparc/package.use.mask
@@ -1,6 +1,11 @@
# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
+# Sam James (2023-07-21)
+# Requires dev-util/pahole.
+sys-kernel/gentoo-kernel debug
+sys-kernel/vanilla-kernel debug
+
# Sam James (2023-06-18)
# Qt 5 not keyworded here
app-text/ansifilter gui
diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.120.ebuild
b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.120.ebuild
index 5e46267db599c..b6589cdcbf677 100644
--- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.120.ebuild
+++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.120.ebuild
@@ -42,9 +42,13 @@ SRC_URI+="
S=${WORKDIR}/${MY_P}
LICENSE="GPL-2"
-KEYWORDS="amd64 ~arm arm64 ~hppa ~ppc ppc64 x86"
+KEYWORDS="amd64 ~arm arm64 ~hppa ~ppc ppc64 ~sparc x86"
IUSE="debug hardened"
-REQUIRED_USE="arm? ( savedconfig )"
+REQUIRED_USE="
+ arm? ( savedconfig )
+ hppa? ( savedconfig )
+ sparc? ( savedconfig )
+"
RDEPEND="
!sys-kernel/gentoo-kernel-bin:${SLOT}
@@ -95,6 +99,9 @@ src_prepare() {
cp
"${DISTDIR}/kernel-ppc64le-fedora.config.${CONFIG_VER}" .config || die
biendian=true
;;
+ sparc)
+ return
+ ;;
x86)
cp "${DISTDIR}/kernel-i686-fedora.config.${CONFIG_VER}"
.config || die
;;
diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-6.1.39.ebuild
b/sys-kernel/gentoo-kernel/gentoo-kernel-6.1.39.ebuild
index c338d2cfc68f0..7e128b87c8f2c 100644
--- a/sys-kernel/gentoo-kernel/gentoo-kernel-6.1.39.ebuild
+++ b/sys-kernel/gentoo-kernel/gentoo-kernel-6.1.39.ebuild
@@ -43,11 +43,14 @@ SRC_URI+="
S=${WORKDIR}/${MY_P}
LICENSE="GPL-2"
-KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~riscv ~x86"
+KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~riscv ~sparc ~x86"
IUSE="debug hardened"
-REQUIRED_USE="arm? ( savedconfig )
+REQUIRED_USE="
+ arm? ( savedconfig )
hppa? ( savedconfig )
- riscv? ( savedconfig )"
+ riscv? ( savedconfig )
+ sparc? ( savedconfig )
+"
RDEPEND="
!sys-kernel/gentoo-kernel-bin:${SLOT}
@@ -101,6 +104,9 @@ src_prepare() {
riscv)
return
;;
+ sparc)
+ return
+ ;;
x86)
cp "${DISTDIR}/kernel-i686-fedora.config.${CONFIG_VER}"
.config || die
;;
diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-6.4.4.ebuild
b/sys-kernel/gentoo-kernel/gentoo-kernel-6.4.4.ebuild
index 5cb60e23b8533..38b5f48b2b817 100644
--- a/sys-kernel/gentoo-kernel/gentoo-kernel-6.4.4.ebuild
+++ b/sys-kernel/gentoo-kernel/gentoo-kernel-6.4.4.ebuild
@@ -44,11 +44,14 @@ SRC_URI+="
S=${WORKDIR}/${MY_P}
LICENSE="GPL-2"
-KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~riscv ~x86"
+KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ppc ~ppc64 ~riscv ~sparc ~x86"
IUSE="debug hardened"
-REQUIRED_USE="arm? ( savedconfig )
+REQUIRED_USE="
+ arm? ( savedconfig )
hppa? ( savedconfig )
- riscv? ( savedconfig )"
+ riscv? ( savedconfig )
+ sparc? ( savedconfig )
+"
RDEPEND="
!sys-kernel/gentoo-kernel-bin:${SLOT}
@@ -102,6 +105,9 @@ src_prepare() {
riscv)
return
;;
+ sparc)
+ return
+ ;;
x86)
cp "${DISTDIR}/kernel-i686-fedora.config.${CONFIG_VER}"
.config || die
;;
--
2.41.0
[gentoo-dev] [PATCH 4/6] kernel-install.eclass: kernel-install_get_qemu_arch: port to sparc
Signed-off-by: Sam James
---
eclass/kernel-install.eclass | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/eclass/kernel-install.eclass b/eclass/kernel-install.eclass
index 49aff35dea0d2..6018abd821513 100644
--- a/eclass/kernel-install.eclass
+++ b/eclass/kernel-install.eclass
@@ -1,4 +1,4 @@
-# Copyright 2020-2022 Gentoo Authors
+# Copyright 2020-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: kernel-install.eclass
@@ -162,6 +162,12 @@ kernel-install_get_qemu_arch() {
ppc64)
echo ppc64
;;
+ sparc)
+ echo sparc
+ ;;
+ sparc64)
+ echo sparc64
+ ;;
riscv)
echo riscv
;;
--
2.41.0
[gentoo-dev] [PATCH 3/6] kernel-build.eclass: add special-case for sparc arch/ directory
Unfortunately, we still have a mess wrt dual-bitness arches.
For sparc, there's arch/sparc, with ARCH=sparc being "whatever the toolchain
is",
ARCH=sparc32 being "give me a 32-bit kernel", and ARCH=sparc64 being "give me
a 64-bit kernel".
You do, seemingly, need to actually pass ARCH=sparc64 to guarantee correct
results,
as various kernel Makefiles check for the ARCH value, even though ARCH=sparc
will
pop out a 64-bit kernel.
(I originally updated toolchain-funcs.eclass's tc-ninja_magic_to_arch, but we
later found that doesn't look particularly sturdy.
Per at the very least 5ba800962a80d4158b73fb91a7779df7b770c750 ("kbuild: update
ARCH alias info for sparc")
upstream, although it seems to go back a fair bit earlier, ARCH=sparc when
building
the kernel means "sparc64" if on a sparc64 host.)
Signed-off-by: Sam James
---
eclass/kernel-build.eclass | 8
1 file changed, 8 insertions(+)
diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index ff615a02d0ebf..276a08a104e0e 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -257,6 +257,14 @@ kernel-build_src_install() {
local kern_arch=$(tc-arch-kernel)
local dir_ver=${PV}${KV_LOCALVERSION}
local kernel_dir=/usr/src/linux-${dir_ver}
+
+ if use sparc ; then
+ # We don't want tc-arch-kernel's sparc64, even though we do
+ # need to pass ARCH=sparc64 to the build system. It's a
quasi-alias
+ # in Kbuild.
+ kern_arch=sparc
+ fi
+
dodir "${kernel_dir}/arch/${kern_arch}"
mv include scripts "${ED}${kernel_dir}/" || die
mv "arch/${kern_arch}/include" \
--
2.41.0
[gentoo-dev] [PATCH 2/6] dist-kernel-utils.eclass: dist-kernel_get_image_path: handle sparc
Same as hppa/ppc*.
Signed-off-by: Sam James
---
eclass/dist-kernel-utils.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/dist-kernel-utils.eclass b/eclass/dist-kernel-utils.eclass
index cb0021f8b3a7e..6668960286699 100644
--- a/eclass/dist-kernel-utils.eclass
+++ b/eclass/dist-kernel-utils.eclass
@@ -77,7 +77,7 @@ dist-kernel_get_image_path() {
arm)
echo arch/arm/boot/zImage
;;
- hppa|ppc|ppc64)
+ hppa|ppc|ppc64|sparc)
#
https://www.kernel.org/doc/html/latest/powerpc/bootwrapper.html
# ./ is required because of ${image_path%/*}
# substitutions in the code
--
2.41.0
[gentoo-dev] [PATCH 1/6] toolchain-funcs.eclass: tc-ninja_magic_to_arch: rename helper function
Signed-off-by: Sam James
---
eclass/toolchain-funcs.eclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index bffbf36f1696c..78ebfe54e41a7 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -666,7 +666,7 @@ tc-has-tls() {
# Parse information from CBUILD/CHOST/CTARGET rather than
# use external variables from the profile.
tc-ninja_magic_to_arch() {
- ninj() { [[ ${type} == "kern" ]] && echo $1 || echo $2 ; }
+ _tc_echo_kernel_alias() { [[ ${type} == "kern" ]] && echo $1 || echo $2
; }
local type=$1
local host=$2
@@ -676,16 +676,16 @@ tc-ninja_magic_to_arch() {
aarch64*) echo arm64;;
alpha*) echo alpha;;
arm*) echo arm;;
- avr*) ninj avr32 avr;;
- bfin*) ninj blackfin bfin;;
+ avr*) _tc_echo_kernel_alias avr32 avr;;
+ bfin*) _tc_echo_kernel_alias blackfin bfin;;
c6x*) echo c6x;;
cris*) echo cris;;
frv*) echo frv;;
hexagon*) echo hexagon;;
- hppa*) ninj parisc hppa;;
+ hppa*) _tc_echo_kernel_alias parisc hppa;;
i?86*) echo x86;;
ia64*) echo ia64;;
- loongarch*) ninj loongarch loong;;
+ loongarch*) _tc_echo_kernel_alias loongarch loong;;
m68*) echo m68k;;
metag*) echo metag;;
microblaze*)echo microblaze;;
@@ -708,11 +708,11 @@ tc-ninja_magic_to_arch() {
riscv*) echo riscv;;
s390*) echo s390;;
score*) echo score;;
- sh64*) ninj sh64 sh;;
+ sh64*) _tc_echo_kernel_alias sh64 sh;;
sh*)echo sh;;
sparc64*) ninj sparc64 sparc;;
sparc*) [[ ${PROFILE_ARCH} == "sparc64" ]] \
- && ninj sparc64 sparc \
+ && _tc_echo_kernel_alias
sparc64 sparc \
|| echo sparc
;;
tile*) echo tile;;
--
2.41.0
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
Sam James writes: > [[PGP Signed Part:Undecided]] > > Florian Schmaus writes: > >> [[PGP Signed Part:Undecided]] >> On 18/07/2023 11.56, Sam James wrote: >>> Mike Gilbert writes: >>> >>>> On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: >>>>>> Haven't we been keeping these because we still need to decide on a >>>>>> policy about what to do with dead acct-*/* packages? >>>>> >>>>> Right. https://bugs.gentoo.org/781881 is still open. Flow could ping >>>>> the QA team and ask if it should be closed, given the opinion there >>>>> seems to be that there's no need to keep them, but I think it's wrong >>>>> to do this pre-empting a policy decision, given it essentially forces >>>>> the "don't keep them" path. >>>> >>>> The bug has been open for several months without comment. If a policy >>>> were going to materialize, I think it would have happened by now. >>>> >>>> Forcing the issue by sending this last rites notice seems acceptable to me. >>> Pinging someone rather than "forcing the issue" as a first-step is >>> customary. >> >> I am sorry, but it seems that I have to clarify something. >> >> First, I have "pinged someone." > > Ping on IRC (in #gentoo-qa, or could PM me), or again on the bug? > > Someone asked the QA team to make a decision. We haven't yet, as I'd > forgot about it. It seems wrong to then just pretend that didn't happen. > > At least try to get it resolved on that end by pinging again / asking us? Just to be super duper clear: it's fine with me if we just move on and don't keep the packages, but I think a quick /msg #gentoo-qa "hey guys, nothing seems to be happening with the bug, do you mind if we just close it?" wouldn't have gone amiss. That is _all_ I'm asking for here. And then when we get onto talk of "incentives" and "illegitimate shadow policies", I become very confused indeed. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > On 18/07/2023 11.56, Sam James wrote: >> Mike Gilbert writes: >> >>> On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: >>>>> Haven't we been keeping these because we still need to decide on a >>>>> policy about what to do with dead acct-*/* packages? >>>> >>>> Right. https://bugs.gentoo.org/781881 is still open. Flow could ping >>>> the QA team and ask if it should be closed, given the opinion there >>>> seems to be that there's no need to keep them, but I think it's wrong >>>> to do this pre-empting a policy decision, given it essentially forces >>>> the "don't keep them" path. >>> >>> The bug has been open for several months without comment. If a policy >>> were going to materialize, I think it would have happened by now. >>> >>> Forcing the issue by sending this last rites notice seems acceptable to me. >> Pinging someone rather than "forcing the issue" as a first-step is >> customary. > > I am sorry, but it seems that I have to clarify something. > > First, I have "pinged someone." Ping on IRC (in #gentoo-qa, or could PM me), or again on the bug? Someone asked the QA team to make a decision. We haven't yet, as I'd forgot about it. It seems wrong to then just pretend that didn't happen. At least try to get it resolved on that end by pinging again / asking us? > > As of writing this, I was the last to comment on the QA bug about five > months ago, asking why we would want to keep unused acct-* packages > [1]. Since then, this has not been answered, and there have been zero > other replies. That signaled me that there was no interest in pursuing > the matter further. In addition, we have already removed acct-* > packages in the past. > I'm sorry that somebody missed a ping in a FOSS project. But this is probably not the first time it's happened to you. > Secondly, nobody immediately forces anything. > I'm saying that speaking to someone works better than committing something and then asking for discussion. > Sam, I am afraid, but I believe that the situation is different from > how you frame it. > > > The proponents of keeping obsolete acct-* packages have the inventive > to establish their preferred policy. It's a bit aggressive to take action, without pinging before doing so (you did several months ago, that's not really the same thing), to "incentivise" someone. > > Accusing me of not facilitating a QA bug that deals with establishing > a policy I do not favor seems unfair. > I'm not sure I'm doing that. I'm saying that doing this preempts a decision and that a ping would've been polite. > Do you think that a QA bug that has not seen progress in nearly five > months should be able to establish an illegitimate shadow policy? > Come on. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
Mike Gilbert writes: > On Mon, Jul 17, 2023 at 4:27 PM Sam James wrote: >> > Haven't we been keeping these because we still need to decide on a >> > policy about what to do with dead acct-*/* packages? >> >> Right. https://bugs.gentoo.org/781881 is still open. Flow could ping >> the QA team and ask if it should be closed, given the opinion there >> seems to be that there's no need to keep them, but I think it's wrong >> to do this pre-empting a policy decision, given it essentially forces >> the "don't keep them" path. > > The bug has been open for several months without comment. If a policy > were going to materialize, I think it would have happened by now. > > Forcing the issue by sending this last rites notice seems acceptable to me. Pinging someone rather than "forcing the issue" as a first-step is customary. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages
Matt Turner writes: > On Mon, Jul 17, 2023 at 3:43 PM Florian Schmaus wrote: >> >> # Florian Schmaus (2023-07-17) >> # Obsolete acct-* packages which became leaf packages. >> # Removal on 2023-08-17. >> acct-user/artifactory >> acct-group/artifactory >> acct-user/cinder >> acct-group/cinder >> acct-user/glance >> acct-group/glance >> acct-user/heat >> acct-group/heat >> acct-user/keystone >> acct-group/keystone >> acct-user/litecoin >> acct-group/litecoin >> acct-user/logcheck >> acct-group/logcheck >> acct-user/minbif >> acct-group/minbif >> acct-user/minio >> acct-group/minio >> acct-user/netbox >> acct-group/netbox >> acct-user/neutron >> acct-group/neutron >> acct-user/nova >> acct-group/nova >> acct-user/placement >> acct-group/placement >> acct-user/quagga >> acct-group/quagga >> acct-user/rplayd >> acct-group/rplayd >> acct-user/rstudio-server >> acct-group/rstudio-server >> acct-user/rundeck >> acct-group/rundeck >> acct-user/sguil >> acct-group/sguil >> acct-user/sigh >> acct-group/sigh >> acct-user/smokeping >> acct-group/smokeping >> acct-user/sobby >> acct-group/sobby >> acct-user/spread >> acct-group/spread >> acct-user/stg >> acct-group/stg >> acct-user/swift >> acct-group/swift >> acct-user/thttpd >> acct-group/thttpd >> acct-group/gpio >> acct-group/simplevirt >> acct-group/spi > > Haven't we been keeping these because we still need to decide on a > policy about what to do with dead acct-*/* packages? Right. https://bugs.gentoo.org/781881 is still open. Flow could ping the QA team and ask if it should be closed, given the opinion there seems to be that there's no need to keep them, but I think it's wrong to do this pre-empting a policy decision, given it essentially forces the "don't keep them" path. signature.asc Description: PGP signature
Re: [gentoo-dev] Package stabilization groups
Matt Turner writes: > Hello, > > Many of us have started using `pkgdev bugs` to file stabilization > bugs. It works well (Thanks Arthur!) and I encourage everyone to give > it a try. > > Where possible, it files one stabilization bug per package. This makes > arch testers' jobs easier and makes the task easier to automate. > > But sometimes we do want to stabilize packages together. For example > major versions of x11-wm/mutter and gnome-base/gnome-shell are tied > together. If a new mutter is stabilized without the new gnome-shell, > the tree will still be consistent, but emerge -u @world will warn > users that the mutter upgrade is blocked. > Big fan of the idea & very much in support of it. This also serves to give us logical groupings of packages which are closely related and should be bumped together. > There was some brief discussion on IRC about how to document these > groupings, and two main ideas were suggested: > > - add a field to metadata.xml to specify the group by an arbitrary name. > E.g. > Each package in the group would specify the same value of name="..." > > - maintain the groups in a separate place (similar to portage @sets). > > Can anyone think of particular advantages or disadvantages to one > solution versus the other? Any other (better) ideas? > When we discussed this a few months ago on IRC, I also brought up a related point: [2023-05-02T18:38:51+0100] <@sam_> do we want to repeat the group members in each member, or do tools need to scan for each thing? [2023-05-02T18:39:07+0100] <@sam_> i.e. does each member have ..., or do we do signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 6/7] dev-dotnet/dotnet-sdk-bin: update packaging mechanism
Maciej Barć writes: > Bug: https://bugs.gentoo.org/900597 > Bug: https://github.com/gentoo/gentoo/pull/29309 > Signed-off-by: Maciej Barć > --- > dev-dotnet/dotnet-sdk-bin/Manifest| 36 ++ > .../dotnet-sdk-bin-6.0.402-r3.ebuild | 65 ++ > .../dotnet-sdk-bin-6.0.404-r1.ebuild | 65 ++ > .../dotnet-sdk-bin-7.0.200-r1.ebuild | 66 +++ > .../dotnet-sdk-bin-7.0.203.ebuild | 66 +++ > dev-dotnet/dotnet-sdk-bin/metadata.xml| 6 +- > 6 files changed, 287 insertions(+), 17 deletions(-) > create mode 100644 dev-dotnet/dotnet-sdk-bin/dotnet-sdk-bin-6.0.402-r3.ebuild > create mode 100644 dev-dotnet/dotnet-sdk-bin/dotnet-sdk-bin-6.0.404-r1.ebuild > create mode 100644 dev-dotnet/dotnet-sdk-bin/dotnet-sdk-bin-7.0.200-r1.ebuild > create mode 100644 dev-dotnet/dotnet-sdk-bin/dotnet-sdk-bin-7.0.203.ebuild > > diff --git a/dev-dotnet/dotnet-sdk-bin/Manifest > b/dev-dotnet/dotnet-sdk-bin/Manifest > index 0db1365533..34d9d16893 100644 > --- a/dev-dotnet/dotnet-sdk-bin/Manifest > +++ b/dev-dotnet/dotnet-sdk-bin/Manifest > @@ -1,12 +1,24 @@ > -DIST dotnet-sdk-6.0.404-linux-arm.tar.gz 181563995 BLAKE2B > ff359d26264f0298d6210a2b7ae8cd0f1b577bf9937aaff09805f361e54349bdab5338182b674c81c8cb330c90f7a17a601ccce899e63f2e837a90bfd02c3726 > SHA512 > 1b9b5e0c45f90a4c752bf6990e5dda4110403a62392dc78abf9145c69b1d329b2630945a88cb4d7756322b188b7f4a9334bfc376067edff5dcfabfd85098d7d8 > -DIST dotnet-sdk-6.0.404-linux-arm64.tar.gz 180324700 BLAKE2B > 33780337294f427da0b8d44d8a3819c4276c0b01ffefe5a846cc5524039a5af203a231fe5893c63dce5b1557cd1288c4cb3e1d93505320a49eeccd4fd22cefe7 > SHA512 > 7c58595aa57b655ff5a268ae4fc680ff3fb15a84dcc0ce84ae7eb25ba27bf66f0c5273c985f15034583f5b05437a5354db68c4064953030dc4caebb11339ac76 > -DIST dotnet-sdk-6.0.404-linux-musl-arm.tar.gz 182613890 BLAKE2B > f0475535f703a80c23a881ef578eeac87923586b27bcc7ed018b75aa88dccc84dcbd9e20543b1e502e0e800b947afd8e6bbc3a44b4101ad786674d0ad2fb196a > SHA512 > d7818ea567db81832cfeed5057c42255d2f19750a741a2cbc57e2d7134267a27e9937f86846b30f393c6f0ad2dbf0f4c73a902ed78b0de56138f077f62f34686 > -DIST dotnet-sdk-6.0.404-linux-musl-arm64.tar.gz 180323728 BLAKE2B > ff32a89653f265df2fda39dc0bb2ff6853e6fced029fb1a16096436a7876ad061e55a1d45fd29f395e4d6585f67cde2e5d95b0c0c2bbaec2b073cfd2785c87e5 > SHA512 > 999220f7247881d44c7f5a429b25c04d31044a1b91af5ede3f899df142af2d9f056a4ac6058c9e56f14b014a479f3a7455bd499f42f8e0f9b4fcacfeabc023b5 > -DIST dotnet-sdk-6.0.404-linux-musl-x64.tar.gz 185037621 BLAKE2B > 0ff97d56c4d061cb5f227c745afb34cf462c286f4c0347224885360cec861dfd59f90a6ef85571c49aa79b12d558111b07a29ac48451739f721e5b13d45f94c1 > SHA512 > 5313d8cbb41e27f462a141914f852e3d3e729886ce063be82778e1444df2d44dadcd2829f60ae97ae300d19798fab9d3b3932a7d9b9d00e948a80ccebbf5e106 > -DIST dotnet-sdk-6.0.404-linux-x64.tar.gz 185546757 BLAKE2B > ce8447f82b93880c6491e06fd35d556b880f59403fd7c6161d228271de6bffc6c74810e5ec5d834e35a715b9bc6173cb028aeb443bd28717a2d8838b543eec9f > SHA512 > 7a0f4b308d3fe98df9b426b0f8f8fb7bd7247244af3570e867a3969349c62c7ea4c6da81a1a2280788e300784167a2933db523f461985aef0681e0cf14bf8f0d > -DIST dotnet-sdk-7.0.200-linux-arm.tar.gz 192996891 BLAKE2B > 43c271a53d2eeebfbbeb7702e0c7a203960b57246f4b1f557d78391abdf10d0cca87c7ee364a37151f8e9e91df53e427df077a7cc25e1ccce5ac5d37fc73bc3a > SHA512 > 7b1072c8080a0f38946d207945417dbeea4cbb688c2ea2dba1cb31330da15652da0823d8571c063a08830fe2157dbacb635eb2a8c7f20033cd1b8a35a9cfde36 > -DIST dotnet-sdk-7.0.200-linux-arm64.tar.gz 193106712 BLAKE2B > 5db6eab8bf56a85a15e6107bd4bca0dd4669d9eb2b3db287b8aa7621e38e07ce213c8e2446add010623b78b7092c0658d17bf4c90a059440778519e5aa117a9e > SHA512 > 2990b7d2b23adb2b2621786ba774450e8cf73bf872173ab57026d7658599accdb5a4cefb5292945e264408f833503210621ed787c8d77eb467d3b204da8073a8 > -DIST dotnet-sdk-7.0.200-linux-musl-arm.tar.gz 192955116 BLAKE2B > 5b5549e158ebc7059b123d601566efddaacd04aa6ee531699b3c70327b2f2005ed11cbb7dea7b9a8a9c5f792fcc7461ea34b0a33a81828b4085327f219224d19 > SHA512 > 1e4f9160cb93ca9704015e787491bf78c5850c2a0aa7f5794b35f607f6f342903c9d8aa182593133d6609d5b9aded9bed769855213e0464311f357a65df0a640 > -DIST dotnet-sdk-7.0.200-linux-musl-arm64.tar.gz 192893152 BLAKE2B > ea793eebc9d414f5f8dd0c4a1b2c0330bf762db8fb1626aaa97d84b8fffe2a6b8d85f8cf735467dd49d6f588cd17254dad7ced926410f7e26488da08e0bb593a > SHA512 > 63c568b1e0014e2039def200fde47d932e5366ba794fcd89f0efbcfd845e8b8b1c0ede6406a518f366356f5b566df2d0a1b53e6fdc9b58a26a59bdaa89e0ce32 > -DIST dotnet-sdk-7.0.200-linux-musl-x64.tar.gz 197209986 BLAKE2B > 4219149ed4f682ecb3d2c00cb2ed24f5352153ca0a5063bf07e7d42ddce95a5d3b4924e257bc166e1a1ca779dd9fb1d8e52d7a17a37ae73a596f3b5f4ed98c5b > SHA512 > e907c96e7f1c7a3497f8726176b1fad9e93050b7b5f30900a634d253c4c5c822c8d729b22b36fa00d5bb2be0834f6c683d47db8c22077fbb191e38ae67e12119 > -DIST dotnet-sdk-7.0.200-linux-x64.tar.gz 197802070 BLAKE2B >
Re: [gentoo-dev] [PATCH 1/1]: profiles/use.desc: add efi global use flag
Andrew Ammerlaan writes: > Hi all, > > Currently we have 7 packages defining the efi flag and an additional 2 > defining the uefi flag. These flags do the same thing, add support for > (U)EFI booting. I therefore propose we introduce efi as a new global > flag and later rename the uefi flag to efi in sys-apps/fwupd and > sys-apps/ipmicfg. > > I don't have a strong preference between the efi or uefi flags, but > since a majority of the packages has chosen efi I suggest we go with > that. Let's do USE=uefi please - UEFI is the modern name for it, and EFI is legacy. I'd like to avoid another USE=ssl situation (where we're stuck with it forever given we have no mechanism for USE flag renames, despite the fact that it's really TLS now). thanks, sam signature.asc Description: PGP signature
[gentoo-dev] Re: [PATCH] ruby-utils.eclass: Simplify _ruby_implementation_depend
Sam James writes: > From: konsolebox > > Closes: https://bugs.gentoo.org/909529 > Signed-off-by: Sam James ftr, while I find the case really repetitive, I'm not sure if this crosses the line into unreadable bash or not, so I feel on the fence. But I wanted it reviewed on ML in any case, rather than us forgetting it on BZ. signature.asc Description: PGP signature
[gentoo-dev] [PATCH] ruby-utils.eclass: Simplify _ruby_implementation_depend
From: konsolebox
Closes: https://bugs.gentoo.org/909529
Signed-off-by: Sam James
---
eclass/ruby-utils.eclass | 52 ++--
1 file changed, 2 insertions(+), 50 deletions(-)
diff --git a/eclass/ruby-utils.eclass b/eclass/ruby-utils.eclass
index c4b6f1502f8a9..8a2b7720c951a 100644
--- a/eclass/ruby-utils.eclass
+++ b/eclass/ruby-utils.eclass
@@ -44,57 +44,9 @@ _ruby_implementation_depend() {
local rubyslot=
case $1 in
- ruby18)
+ ruby1[89]|ruby2[0-7]|ruby3[0-2])
rubypn="dev-lang/ruby"
- rubyslot=":1.8"
- ;;
- ruby19)
- rubypn="dev-lang/ruby"
- rubyslot=":1.9"
- ;;
- ruby20)
- rubypn="dev-lang/ruby"
- rubyslot=":2.0"
- ;;
- ruby21)
- rubypn="dev-lang/ruby"
- rubyslot=":2.1"
- ;;
- ruby22)
- rubypn="dev-lang/ruby"
- rubyslot=":2.2"
- ;;
- ruby23)
- rubypn="dev-lang/ruby"
- rubyslot=":2.3"
- ;;
- ruby24)
- rubypn="dev-lang/ruby"
- rubyslot=":2.4"
- ;;
- ruby25)
- rubypn="dev-lang/ruby"
- rubyslot=":2.5"
- ;;
- ruby26)
- rubypn="dev-lang/ruby"
- rubyslot=":2.6"
- ;;
- ruby27)
- rubypn="dev-lang/ruby"
- rubyslot=":2.7"
- ;;
- ruby30)
- rubypn="dev-lang/ruby"
- rubyslot=":3.0"
- ;;
- ruby31)
- rubypn="dev-lang/ruby"
- rubyslot=":3.1"
- ;;
- ruby32)
- rubypn="dev-lang/ruby"
- rubyslot=":3.2"
+ rubyslot=":${1:4:1}.${1:5}"
;;
ree18)
rubypn="dev-lang/ruby-enterprise"
--
2.41.0
[gentoo-dev] Re: Flow's Manifesto and questions for nominees (was: Re: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
Sam James writes:
> Florian Schmaus writes:
>
>> [[PGP Signed Part:Undecided]]
>> Posted to gentoo-dev@ since we are now entering a technical discussion
>> again.
>>
>> For those who did not follow gentoo-project@, the previous posts include:
>>
>> https://marc.info/?l=gentoo-project=168918875000738=2
>> https://marc.info/?l=gentoo-project=168881103930591=2
>>
>> On 12/07/2023 21.28, Alec Warner wrote:
>>> On Wed, Jul 12, 2023 at 12:07 PM Florian Schmaus wrote:
>>>> Apologies for not replying to everyone individually.
>>>>
>>>> I thank my fellow council candidates who took the time to reply to this
>>>> sensitive and obviously controversial matter. I understand that not
>>>> everyone feels comfortable taking a stance in this discussion.
>>>>
>>>> I asked the other council candidates about their opinion on EGO_SUM.
>>>> Unfortunately, some replies included only a rather shallow answer. A few
>>>> focused on criticism of my actions and how I approach the issue. Which
>>>> is obviously fine. I read it all and have empathy for everyone who feels
>>>> aggravated. You may or may not share the complaints. But let us focus on
>>>> the actual matter for a moment.
>>>>
>>>> Even the voices raised for a restricted reintroduction of EGO_SUM just
>>>> mention an abstract limit [1]. A concrete limit is not mentioned,
>>>> although I asked for it and provided my idea including specific limits.
>>>> Not knowing the concrete figures others have in mind makes it difficult
>>>> to find a compromise. For example, a fellow council candidate postulated
>>>> that it would be quicker for me to implement a limit-check in pkgcheck
>>>> than discuss EGO_SUM. I wish that were the case. Unfortunately it is
>
> I think this misrepresents my point. All I said was that a bound should
> be added matching what's in Portage right now.
>
> Please in future respond to me directly if you're going to claim something
> about what I've said.
>
>> [...]
>> EGO_SUM affects two dimensions that could be limited/restricted:
>> A) the process environment, which may run into the Linux kernel
>>environment limit on exec(3)
>> B) the size of the package directory, where EGO_SUM affects the size of
>>ebuilds and the Manifest
>>
>> [...]
>>
>> A), however, is a different beast. There is undeniably a
>> kernel-enforced limit that we could hit due to an extremely large
>> EGO_SUM (among other things). However, the only bug report I know that
>> runs into this kernel limit was with texlive (bug #719202). The low
>> number of recorded bugs caused by the environment limit matches with
>> the fact that even the ebuild with the most EGO_SUM entries that I
>> ever analyzed, app-containers/cri-o-1.23.1 (2022-02-16) with 2052
>> EGO_SUM entries, does *not* run into the environment limit.
>>
>
> I thought I'd gave you a list before, but maybe it was someone else.
>
> Anyway, a non-exhaustive list (I remember maybe two more but I got bored):
> * https://bugs.gentoo.org/829545 ("app-admin/vault-1.9.1 - find: The
> environment is too large for exec().")
> * https://bugs.gentoo.org/829684 ("app-metrics/prometheus-2.31.1 - find: The
> environment is too large for exec().")
> * https://bugs.gentoo.org/830187 (you're CC'd on this) ("go lang ebuild:
> SRC_URI too long that it causes "Argument list too long" error")
> * https://bugs.gentoo.org/831265 ("sys-cluster/minikube-1.24.0 - find: The
> environment is too large for exec().")
> * a0be89b772474e3336d3de699d71482aa89d2444 ("app-emulation/nerdctl: drop
> 0.14.0")
>
Sorry, as I said this, I came across some more. These are the ones I was
thinking of:
* https://bugs.gentoo.org/830266 ("app-admin/filebeat-7.16.2 fails to compile:
Assertion failed: bc_ctl.arg_max >= LINE_MAX (xargs.c: main: 511)")
* https://bugs.gentoo.org/832964 ("sys-cluster/kops-1.21.0 fails to compile:
Assertion failed: bc_ctl.arg_max >= LINE_MAX (xargs.c: main: 511)")
* https://bugs.gentoo.org/833961 ("net-p2p/go-ipfs-0.11.0 - Assertion failed:
bc_ctl.arg_max >= LINE_MAX (xargs.c: main: 511)")
* https://bugs.gentoo.org/835712 ("dev-util/packer-1.7.9 fails to compile:
Assertion failed: bc_ctl.arg_max >= LINE_MAX (xargs.c: main: 511)")
> Other related bugs (as it's useful as a summary of where we are):
> * https://bugs.gentoo.org/540146 ("sys-apps/portage: limit no of exported
> variables in EAPI 6")
> * https://bugs.gentoo.org/720180 ("sys-apps/portage: add support to delay
> export of "A" variable until last moment")
> * https://bugs.gentoo.org/721088 ("[Future EAPI] Don't export A")
> * https://bugs.gentoo.org/833567 ("[Future EAPI] src_fetch_extra phase the
> runs after src_unpack")
>
> I am not aware of a bug (yet?) for radhermit's suggestion wrt external
> helpers which is related but different to exporting fewer variables.
>
> thanks,
> sam
signature.asc
Description: PGP signature
[gentoo-dev] Re: Flow's Manifesto and questions for nominees (was: Re: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
Florian Schmaus writes:
> [[PGP Signed Part:Undecided]]
> Posted to gentoo-dev@ since we are now entering a technical discussion
> again.
>
> For those who did not follow gentoo-project@, the previous posts include:
>
> https://marc.info/?l=gentoo-project=168918875000738=2
> https://marc.info/?l=gentoo-project=168881103930591=2
>
> On 12/07/2023 21.28, Alec Warner wrote:
>> On Wed, Jul 12, 2023 at 12:07 PM Florian Schmaus wrote:
>>> Apologies for not replying to everyone individually.
>>>
>>> I thank my fellow council candidates who took the time to reply to this
>>> sensitive and obviously controversial matter. I understand that not
>>> everyone feels comfortable taking a stance in this discussion.
>>>
>>> I asked the other council candidates about their opinion on EGO_SUM.
>>> Unfortunately, some replies included only a rather shallow answer. A few
>>> focused on criticism of my actions and how I approach the issue. Which
>>> is obviously fine. I read it all and have empathy for everyone who feels
>>> aggravated. You may or may not share the complaints. But let us focus on
>>> the actual matter for a moment.
>>>
>>> Even the voices raised for a restricted reintroduction of EGO_SUM just
>>> mention an abstract limit [1]. A concrete limit is not mentioned,
>>> although I asked for it and provided my idea including specific limits.
>>> Not knowing the concrete figures others have in mind makes it difficult
>>> to find a compromise. For example, a fellow council candidate postulated
>>> that it would be quicker for me to implement a limit-check in pkgcheck
>>> than discuss EGO_SUM. I wish that were the case. Unfortunately it is
I think this misrepresents my point. All I said was that a bound should
be added matching what's in Portage right now.
Please in future respond to me directly if you're going to claim something
about what I've said.
> [...]
> EGO_SUM affects two dimensions that could be limited/restricted:
> A) the process environment, which may run into the Linux kernel
>environment limit on exec(3)
> B) the size of the package directory, where EGO_SUM affects the size of
>ebuilds and the Manifest
>
> [...]
>
> A), however, is a different beast. There is undeniably a
> kernel-enforced limit that we could hit due to an extremely large
> EGO_SUM (among other things). However, the only bug report I know that
> runs into this kernel limit was with texlive (bug #719202). The low
> number of recorded bugs caused by the environment limit matches with
> the fact that even the ebuild with the most EGO_SUM entries that I
> ever analyzed, app-containers/cri-o-1.23.1 (2022-02-16) with 2052
> EGO_SUM entries, does *not* run into the environment limit.
>
I thought I'd gave you a list before, but maybe it was someone else.
Anyway, a non-exhaustive list (I remember maybe two more but I got bored):
* https://bugs.gentoo.org/829545 ("app-admin/vault-1.9.1 - find: The
environment is too large for exec().")
* https://bugs.gentoo.org/829684 ("app-metrics/prometheus-2.31.1 - find: The
environment is too large for exec().")
* https://bugs.gentoo.org/830187 (you're CC'd on this) ("go lang ebuild:
SRC_URI too long that it causes "Argument list too long" error")
* https://bugs.gentoo.org/831265 ("sys-cluster/minikube-1.24.0 - find: The
environment is too large for exec().")
* a0be89b772474e3336d3de699d71482aa89d2444 ("app-emulation/nerdctl: drop
0.14.0")
Other related bugs (as it's useful as a summary of where we are):
* https://bugs.gentoo.org/540146 ("sys-apps/portage: limit no of exported
variables in EAPI 6")
* https://bugs.gentoo.org/720180 ("sys-apps/portage: add support to delay
export of "A" variable until last moment")
* https://bugs.gentoo.org/721088 ("[Future EAPI] Don't export A")
* https://bugs.gentoo.org/833567 ("[Future EAPI] src_fetch_extra phase the runs
after src_unpack")
I am not aware of a bug (yet?) for radhermit's suggestion wrt external
helpers which is related but different to exporting fewer variables.
thanks,
sam
Re: [gentoo-dev] Possible merge of myspell/hunspell dictionaries
zurabid2...@gmail.com writes: > Hello everyone, > > I am new here, so I'm sorry in advance for any stupid thing I may > say. I want to adopt hunspell for various reasons and what I've > noticed is a plethora of app-dicts/myspell-* packages (for each > language there's one). > > I suggest merging them into one big myspell-dicts package, which will > certainly reduce maintenance burden (the similar thing is done with > libreoffice-l10n, I think). > My only real question is why they're split in the first place and if there's some good reason for that. I've no idea. > Looking forward to hearing your thoughts about my proposal > I think you sent this email a few days ago, fwiw, see https://marc.info/?l=gentoo-dev=168872367517846=2. I'd maybe ask on IRC at #gentoo-dev-help & #gentoo-proxy-maint, as well, where we're focused on helping new contributors. I'd feel a bit better about the merge, I suppose, if I knew someone had checked git history and see if anyone suggested it before on Bugzilla and such. Anyway, it doesn't sound like a crazy idea prima facie. best, sam
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > On 30/06/2023 10.22, Sam James wrote: >> Florian Schmaus writes: >>> [[PGP Signed Part:Undecided]] >>> [in reply to a gentoo-project@ post, but it was asked to continue this >>> on gentoo-dev@] >>> On 28/06/2023 16.46, Sam James wrote: >>>> and questions remain unanswered on the >>>> ML (why not implement a check in pkgcheck similar to what is in Portage, >>>> for example)? >>> >>> On 2023-05-30 [1], I proposed a limit in the range of 2 to 1.5 MiB for >>> the total package-directory size. I only care a little about the tool >>> that checks this limit, but pkgcheck is an obvious choice. I also >>> suggested that we review this policy once the number of Go packages >>> has doubled or two years after this policy was established (whatever >>> comes first). >>> >>> But I fear you may be referring to another kind of check. You may be >>> talking about a check that forbids EGO_SUM in ::gentoo but allows it >>> overlays. >> My position on this has been consistent: > a check is needed to >> statically >> determine when the environment size is too big. Copying the Portage >> check into pkgcheck (in terms of the metrics) would satisfy this. > > It is not as easy as merely copying existing portage code into > pkgcheck (unless I am missing something). > That's why I said "in terms of the metrics". > I've talked to arthurzam, and there appears to be a .environment file > created by pkgcheck, which we could use to approximate the exported > environment. > > Another option would be to have pkgcheck count the EGO_SUM > entries. The tree-sitter API for Bash, which pkgcheck already uses, > seems to allow for that. But that would be different from the check in > portage. Although, IMHO, counting EGO_SUM entries would be sufficient. Right. > > >> That is, regardless of raw size, I'm asking for a calculation based on >> the contents of EGO_SUM where, if exceeded, the package will not be >> installable on some systems. You didn't have an issue implementing this >> for Portage and I've mentioned this a bunch of times since, so I thought >> it was clear what I was hoping to see. > > So pkgcheck counting EGO_SUM entries would be sufficient for the > purpose of having a static check that notices if the ebuild would > likely run into the environment limit? > If you check it actually fires in some of the old broken scenarios (see Bugzilla), then yes. But I'd be interested in your thoughts on radhermit's reply (please reply there). > To find a common compromise, I would possibly invest my time in > developing such a test. Even though I do not deem such a check a > strict prerequisite to reintroduce EGO_SUM. Yes, you've made clear you disagree. > > >>> Intelligibly, EGO_SUM can be considered ugly. Compared to a >>> traditional Gentoo package, EGO_SUM-based ones are larger. The same is >>> true for Rust packages. However, looking at the bigger picture, >>> EGO_SUM's advantages outweigh its disadvantages. >>> >> Again, am on record as being fine with the general EGO_SUM approach, >> even if I wish we didn't need it, as I see it as inevitable for things >> like yarn, .NET, and of course Rust as we already have it. >> Just ideally not huge ones, and certainly not huge ones which then >> aren't even reliably installable because of environment size. > > Talking about "reliably installable" makes it sound to me like there > are cases where installing a EGO_SUM-based package sometimes works and > sometimes not. But the kernel-limit is fixed and not even > configurable, besides, of course patching the source (and in the > absence of architectures with a page size below 4 KiB) [1]. > ulm's reply notes that this is a limitation in the Linux kernel, so I have no idea why musl tinderboxes seemed to disproportionately hit these issues and I assume one of us either missing something or it was just a crazy fluke. > Any developer testing whether or notan ebuild is installable would > become immediately aware if the ebuild runs into the environment > limit, or not. > This clearly didn't happen with the previous examples (see what I said above too), as there were times when they installed for some people, but not in CI/tinderboxes. I don't know why and it merits investigation. signature.asc Description: PGP signature
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
Zoltan Puskas writes: > On Tue, Jul 04, 2023 at 01:13:30AM -0600, Tim Harder wrote: >> On 2023-07-03 Mon 04:17, Florian Schmaus wrote: >> >On 30/06/2023 13.33, Eray Aslan wrote: >> >>On Fri, Jun 30, 2023 at 03:38:11AM -0600, Tim Harder wrote: >> >>>Why do we have to keep exporting the related variables that generally >> >>>cause these size issues to the environment? >> >> >> >>I really do not want to make a +1 response but this is an excellent >> >>question that we need to answer before implementing EGO_SUM. >> > >> >Could you please discuss why you make the reintroduction of EGO_SUM >> >dependent on this question? >> >> Just to be clear, I don't particularly care about EGO_SUM enough to gate >> its reintroduction (and don't have any leverage to do so anyway). I'm >> just tired of the circular discussions around env issues that all seem >> to avoid actual fixes, catering instead to functionality used by a >> vanishingly small subset of ebuilds in the main repo that compels a >> certain design mostly due to how portage functioned before EAPI 0. >> >> Other than that, supporting EGO_SUM (or any other language ecosystem >> trending towards distro-unfriendly releases) is fine as long as devs are >> cognizant how the related global-scope eclass design affects everyone >> running or working on the raw repo. I hope devs continue leveraging the >> relatively recent benchmark tooling (and perhaps more future support) to >> improve their work. Along those lines, it could be nice to see sample >> benchmark data in commit messages for large, global-scope eclass work >> just to reinforce that it was taken into account. >> >> Tim >> > > I've been following the EGO_SUM thread for quite some time now. One other > thing > I did not see mentioned in favour of EGO_SUM so far: reproducibility. > > The problem with external tarballs is that they are gone once the ebuild is > dropped from the tree. Should a user ever want to roll back to a previous > version of an application, either by checking out on older version of the > portage tree or copying said ebuild into their local overlay, they still > cannot > simply run an emerge on the it as they have to somehow recreate the tarball > itself too. I believe Hank's email coves this. signature.asc Description: PGP signature
[gentoo-dev] Up for grabs: Percona DB and friends
Various open bugs for these and bumps pending. mysql@ has very few members now and needs help in general, but doesn't have the resources to maintain these. commit ab270c702a21d69c4ebd099951ff7a79142081d1 Author: Sam James Date: Tue Jul 4 23:20:03 2023 +0100 dev-db/percona-xtrabackup: drop to maintainer-needed Signed-off-by: Sam James commit 632d464008bcaadb49811b5dceef1091db91b99f Author: Sam James Date: Tue Jul 4 23:19:51 2023 +0100 dev-db/percona-toolkit: drop to maintainer-needed Signed-off-by: Sam James commit dbe60f7ea017a23fd79ac3b1828cd5599e4941cd Author: Sam James Date: Tue Jul 4 23:19:34 2023 +0100 dev-db/percona-server: drop to maintainer-needed signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-util/sysdig-kmod
# Holger Hoffstätte (2023-07-04) # Obsolete package, replaced by dev-util/scap-driver. # https://bugs.gentoo.org/907486 # Masked for removal on 2023-08-04. dev-util/sysdig-kmod signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/2] new gradle.eclass
Florian Schmaus writes: > I would like to propose the gradle.eclass for ::gentoo. > > Multiple people have shown interest in an eclass for Gradle, as it would > make it easier to move Gradle-based projects into ::gentoo. For exmaple, > ghidra from ::pentoo. And, as a nice bonus, the addition of the gradle > eclass to ::gentoo would make it easier for overlays to use it. This, in > turn, reduces the friction when migrating Gradle-based projects from > overlays into ::gentoo. > > The second patch shows how gradle.eclass can be used in the openfjx ebuild. > > PR at https://github.com/gentoo/gentoo/pull/28986 Very happy to see this! I've left some remarks on the PR (can echo them here if needed), but it's nothing serious either (i.e. easily fixed, nothing sort of deep wrt design). thanks, sam signature.asc Description: PGP signature
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
Florian Schmaus writes:
> [[PGP Signed Part:Undecided]]
> [in reply to a gentoo-project@ post, but it was asked to continue this
> on gentoo-dev@]
>
> On 28/06/2023 16.46, Sam James wrote:
>> Florian Schmaus writes:
>>> On 17/06/2023 10.37, Arthur Zamarin wrote:
>>>> I also want to nominate people who I feel contribute a lot to Gentoo and
>>>> I have a lot of interaction with (ordered by name, not priority):
>>>> […]
>>>> flow
>>>
>>> I apologize for the late reply, and thank you for the nomination. I am
>>> honored and accept.
>>>
>>> As many of you know, I am spending a lot of time on the EGO_SUM
>>> situation, as it is one of the most critical issues to solve.
>>>
>>> I have used the last few days to carefully consider whether a seat on
>>> the council is more harmful or beneficial to my efforts regarding
>>> EGO_SUM. On the one hand, council work means I have less time to
>>> improve the EGO_SUM situation. On the other hand, a seat in the
>>> council increases the probability of positively influencing Gentoo's
>>> future, also regarding EGO_SUM.
>>>
>> That's fine and it's great to see more people running!
>
> Excellent that we share this view. :)
>
>
>> But with regard to EGO_SUM: you didn't appear at the meeting where we
>> discussed
>> your previous EGO_SUM proposal,
>
> Naively, as I am, I expected that the mailing list would be used for
> discussion and that the council meeting would be used chiefly for
> voting and intra-council discussion. And since the request to the
> council to vote on a concrete proposal was preceded by a
> multiple-week, if not month-long, mailing list discussion, I assumed
> that my presence in the council meeting was optional.
>
> Had I known that my presence was required, or that the absence in the
> meeting would be blamed on me afterward, I would have appeared if
> possible.
I'm not blaming you for anything. But you didn't speak in
#gentoo-council before the meeting (a few days before IIRC) when we
were discussing the problem, I pinged you during the meeting, and you
didn't appear there afterwards.
You also didn't seem to respond to the council decision (or
non-decision) in that meeting either, unless I've missed it.
It seems self-evident that discussion would happen in the meeting before
voting...? What am I misunderstanding?
We regularly discuss things before voting on them. Do you normally
observe council meetings? I don't think what we did in this instance
was at all unusual.
(Also: there's the issue of whether or not the council should really
be voting on overriding an eclass maintainer who would then be forced
to keep something working they don't want to. mgorny raised that.)
>
>
>> and questions remain unanswered on the
>> ML (why not implement a check in pkgcheck similar to what is in Portage,
>> for example)?
>
> On 2023-05-30 [1], I proposed a limit in the range of 2 to 1.5 MiB for
> the total package-directory size. I only care a little about the tool
> that checks this limit, but pkgcheck is an obvious choice. I also
> suggested that we review this policy once the number of Go packages
> has doubled or two years after this policy was established (whatever
> comes first).
>
> But I fear you may be referring to another kind of check. You may be
> talking about a check that forbids EGO_SUM in ::gentoo but allows it
> overlays.
My position on this has been consistent: a check is needed to statically
determine when the environment size is too big. Copying the Portage
check into pkgcheck (in terms of the metrics) would satisfy this.
That is, regardless of raw size, I'm asking for a calculation based on
the contents of EGO_SUM where, if exceeded, the package will not be
installable on some systems. You didn't have an issue implementing this
for Portage and I've mentioned this a bunch of times since, so I thought
it was clear what I was hoping to see.
I would also like (which is not what I was referring to here) some
limit on the size, given that we already have a limit on the size of
${FILESDIR}, but this is less of a concern for me given it's bounded
by the aforementioned environment size check.
>
> Intelligibly, EGO_SUM can be considered ugly. Compared to a
> traditional Gentoo package, EGO_SUM-based ones are larger. The same is
> true for Rust packages. However, looking at the bigger picture,
> EGO_SUM's advantages outweigh its disadvantages.
>
Again, am on record as being fine with the general EGO_SUM approach,
even if I wish we didn't need it, as I see it as inevitable for things
like yarn, .NET, and of course Rust as we already have it.
Just ideally not huge ones, and certainly not huge ones which then
aren't even reliably installable because of environment size.
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] cmake.eclass: workaround S=${WORKDIR} creating builddir above ${WORKDIR}
Ulrich Mueller writes:
>>>>>> On Mon, 26 Jun 2023, Sam James wrote:
>
>> +
>> +# Avoid creating ${WORKDIR}_build (which is above WORKDIR).
>> +# TODO: For EAPI > 8, we should ban S=WORKDIR for CMake.
>> +# See bug #889420.
>> +if [[ ${S} == ${WORKDIR} && ${BUILD_DIR} == ${WORKDIR}_build ]]
>> ; then
>
> I'd suggest adding quotes to the RHS of the expression, to prevent
> globbing.
I'm fine with quoting the RHS, but I don't think it's worth making the
other changes given this works and it's already an edge case.
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH] cmake.eclass: workaround S=${WORKDIR} creating builddir above ${WORKDIR}
When S=${WORKDIR}, cmake.eclass would create its build directory (if
CMAKE_USE_DIR
is unset) above WORKDIR(!) as ${WORKDIR}_build. Creating directories above
WORKDIR is not legal.
Portage has its own bug (bug #889418) in that it doesn't clean up unknown
directories
above WORKDIR in PORTAGE_TMPDIR, so combined, you get a problem where "ebuild
... clean" doesn't
actually clean things up at all, and you get very confusing issues if e.g.
changing
CC between runs.
The explicit S=WORKDIR check isn't truly needed but it makes explicit our
intent here.
Bug: https://bugs.gentoo.org/889418
Closes: https://bugs.gentoo.org/889420
Signed-off-by: Sam James
---
eclass/cmake.eclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 1cdbc123a243..4050beb22ba3 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -293,6 +293,15 @@ _cmake_check_build_dir() {
BUILD_DIR="${CMAKE_USE_DIR}"
else
: "${BUILD_DIR:=${CMAKE_USE_DIR}_build}"
+
+ # Avoid creating ${WORKDIR}_build (which is above WORKDIR).
+ # TODO: For EAPI > 8, we should ban S=WORKDIR for CMake.
+ # See bug #889420.
+ if [[ ${S} == ${WORKDIR} && ${BUILD_DIR} == ${WORKDIR}_build ]]
; then
+ eqawarn "QA notice: S=WORKDIR is deprecated for
cmake.eclass."
+ eqawarn "Please relocate the sources in src_unpack."
+ BUILD_DIR="${WORKDIR}"/${P}_build
+ fi
fi
einfo "Source directory (CMAKE_USE_DIR): \"${CMAKE_USE_DIR}\""
--
2.41.0
Re: [gentoo-dev] [PATCH] acct-user.eclass: include exit status in death message
Mike Gilbert writes:
> On Sun, Jun 25, 2023 at 2:52 PM Michał Górny wrote:
>>
>> I think a better approach would be to always include $? in die messages
>> in Portage.
>
> It's a nice idea, but will not work in the case where die is not
> called immediately after the failing command.
>
> A couple of possible workarounds that could be used to reset $? before
> calling die:
>
> 1. Exit in a subshell: (exit ${status})
> 2. Return from a function: set_status() { return $1; }; set_status ${status}
>
> In any case, I would like to apply the acct-user.eclass patch soonish
> to help with debugging an error during stage building that releng
> reported to me in IRC. We can revisit changing the die function and
> possibly revert this patch later.
lgtm then
signature.asc
Description: PGP signature
Re: [gentoo-dev] Announcing a utility for updating metadata.xml files
"Anna (cybertailor) Vyalkova" writes: > Hi lists, > > You might know about the `app-portage/metagen` utility that generates > metadata.xml files with your name and email. But there was no tool that > autofilled upstream information, so I wrote it. > > Using it is as simple as: > > $ gentle foo-0.1.ebuild > > You can install it as `app-portage/gentle` from the ::guru repository or > download it from PyPI: https://pypi.org/project/gentle-mxml/ Thanks, this sounds pretty useful. I might look at adding Perl (and maybe Ruby) support if nobody else does. Feel free to submit it to ::gentoo. signature.asc Description: PGP signature
Re: [gentoo-dev] Eselect repository feature request
TOMAS FABRIZIO ORSI writes: > 2. Add a way to use the "real" upstream sources instead of our mirrored > ones > > > Isn't this eselect repository's default behaviour? Or am I misunderstanding? > When I run "eselect repository list" I get the source repositories, not the > mirrored ones. > Is it using the mirrored one behind the scenes? (Please don't top-post.) No, it uses the mirrores ones with metadata. > > Best regards, > - Tomas Fabrizio Orsi > El mié, 21 jun 2023 a las 15:44, Sam James () escribió: > > Florian Schmaus writes: > > > [[PGP Signed Part:Undecided]] > > On 21/06/2023 17.56, Mike Gilbert wrote: > >> On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus wrote: > >>> > >>> On 20.06.23 19:26, Mike Gilbert wrote: > >>>> On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus wrote: > >>>>> > >>>>> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote: > >>>>>> Isn't that duplicating the information of metadata/layout.conf's > >>>>>> 'master' key-value pair [1]? > >>>>>> > >>>>>> > >>>>>> Yes, I agree that it would be duplicating that information. As a > matter > >>>>>> of fact, Michał Górny pointed the same thing out. > >>>>>> However, Michał also added, quote: "What's really lacking here is > >>>>>> support for specifying dependencies via |repositories.xml| > >>>>> > >>>>> Do we need to duplicate the information in repositories.xml, with all > >>>>> the drawbacks of duplication? > >>>>> > >>>>> Can't eselect repository add the new repository, then read the > 'masters' > >>>>> value from layout.conf, and add the missing repositories recursively? > >>>> > >>>> That would be a significant change in behavior for eselect repository. > >>> > >>> Right, but it seems to be a desirable behaviour. Cases where the user > >>> wants to add a repo but not immediately sync it are probably rare. > >>> > >>> Furthermore, it would avoid duplicating the information, which avoids > >>> the typical drawbacks of duplication (e.g., the two sets getting out of > >>> sync). > >>> > >>> I've looked at the eselect-repository code, and it seems not hard to > >>> change the behaviour of "eselect repository add" to add and sync a > >>> repository and then, recursively, add and sync further required > >>> repositories. > >>> > >>> I may give it a shot, but ideally I'd know if it has a chance to be > >>> accepted upstream first. Or maybe there is a good reason why > >>> eselect-repository behaves as it currently does that I am missing? > >> I can't speak for "upstream", but here are my concerns: > >> 1. As a developer, I might just want to create the repos.conf config > >> snippet and sync the repo manually. > >> 2. As a user, I might have any arbitrary reason for not wanting to > >> sync immediately. > > > > Would an opt-out switch be enough to alleviate those concerns of you? > > > > > >> 3. eselect-repository does not currently depend on any particular > >> package manager. It writes config files intended for Portage, but it > >> does not actually invoke any Portage commands. That feels like a > >> significant distinction to me. > >> 4. If you start invoking Portage commands, you then have to deal with > >> the possibility of people using alternate package managers. pkgcore > >> can also utilize Portage's repos.conf, and the user might prefer to > >> use pmaint instead of emaint or emerge --sync. > > > > Those two points seem to be based on the same fundamental concern. > > > > The only portage specific code would be the call to "emaint sync -r > > $repo" (remember that "emerge --sync" is just a wrapper for "emaint > > sync --auto"). I think it would be easy to add later 1. add support > > for different package managers (if the need arises), and 2. make the > > "sync command" user configurable. > > While looking at this, it might be worth evaluating 2 other things > which users have mentioned during the migration away from layman: > 1. Adding a way to fully disable the cache fetching; > 2. Add a way to use the "real" upstream sources instead of our mirrored > ones > > best, > sam signature.asc Description: PGP signature
Re: [gentoo-dev] Eselect repository feature request
Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > On 21/06/2023 17.56, Mike Gilbert wrote: >> On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus wrote: >>> >>> On 20.06.23 19:26, Mike Gilbert wrote: On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus wrote: > > On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote: >> Isn't that duplicating the information of metadata/layout.conf's >> 'master' key-value pair [1]? >> >> >> Yes, I agree that it would be duplicating that information. As a matter >> of fact, Michał Górny pointed the same thing out. >> However, Michał also added, quote: "What's really lacking here is >> support for specifying dependencies via |repositories.xml| > > Do we need to duplicate the information in repositories.xml, with all > the drawbacks of duplication? > > Can't eselect repository add the new repository, then read the 'masters' > value from layout.conf, and add the missing repositories recursively? That would be a significant change in behavior for eselect repository. >>> >>> Right, but it seems to be a desirable behaviour. Cases where the user >>> wants to add a repo but not immediately sync it are probably rare. >>> >>> Furthermore, it would avoid duplicating the information, which avoids >>> the typical drawbacks of duplication (e.g., the two sets getting out of >>> sync). >>> >>> I've looked at the eselect-repository code, and it seems not hard to >>> change the behaviour of "eselect repository add" to add and sync a >>> repository and then, recursively, add and sync further required >>> repositories. >>> >>> I may give it a shot, but ideally I'd know if it has a chance to be >>> accepted upstream first. Or maybe there is a good reason why >>> eselect-repository behaves as it currently does that I am missing? >> I can't speak for "upstream", but here are my concerns: >> 1. As a developer, I might just want to create the repos.conf config >> snippet and sync the repo manually. >> 2. As a user, I might have any arbitrary reason for not wanting to >> sync immediately. > > Would an opt-out switch be enough to alleviate those concerns of you? > > >> 3. eselect-repository does not currently depend on any particular >> package manager. It writes config files intended for Portage, but it >> does not actually invoke any Portage commands. That feels like a >> significant distinction to me. >> 4. If you start invoking Portage commands, you then have to deal with >> the possibility of people using alternate package managers. pkgcore >> can also utilize Portage's repos.conf, and the user might prefer to >> use pmaint instead of emaint or emerge --sync. > > Those two points seem to be based on the same fundamental concern. > > The only portage specific code would be the call to "emaint sync -r > $repo" (remember that "emerge --sync" is just a wrapper for "emaint > sync --auto"). I think it would be easy to add later 1. add support > for different package managers (if the need arises), and 2. make the > "sync command" user configurable. While looking at this, it might be worth evaluating 2 other things which users have mentioned during the migration away from layman: 1. Adding a way to fully disable the cache fetching; 2. Add a way to use the "real" upstream sources instead of our mirrored ones best, sam signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 4/5] cargo.eclass: Support separating crate names/versions via slash
Michał Górny writes: > On Fri, 2023-06-16 at 17:48 +0300, Denis Lisov wrote: >> Hello Michał, >> >> On Fri, Jun 16, 2023 at 3:09 PM Michał Górny wrote: >> > Support specifying crate names and versions separated by forward slashes >> > rather than hyphens. Since slashes are not valid in crate names, this >> > makes splitting the tokens trivial and free of regular expressions. >> > Effectively, the slash variant is roughly 180% faster: >> >> As a developer using Rust I want to note that Cargo has a concept of >> "package ID specification"[1] that usually uses pkgname@version >> syntax, but AFAIK there's no prior art for using pkgname/version in >> the ecosystem. Could it make sense to use pkgname@version for >> consistency? >> > > I suppose so. The only reason I've used slash is because that could be > used directly in URL. I think we should do it (@ delimiter) - it looks more natural in a Rust/cargo context. Thanks for the suggestion! signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 10/11] ruby-ng.eclass: use shopt directly, not via estack.eclass
Petr Vaněk writes:
> On Thu, Jun 15, 2023 at 04:52:37PM +0100, Sam James wrote:
>> ulm points out that estack.eclass is particularly inefficient (although
>> it'll get slightly better once https://github.com/gentoo/gentoo/pull/31437
>> is fixed).
>>
>> Let's just manually roll it like llvm.eclass does.
>>
>> Bug: https://bugs.gentoo.org/908465
>> Signed-off-by: Sam James
>> ---
>> eclass/ruby-ng.eclass | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
>> index 14f4414337d6f..8fe26057e7ffe 100644
>> --- a/eclass/ruby-ng.eclass
>> +++ b/eclass/ruby-ng.eclass
>> @@ -163,7 +163,8 @@ _RUBY_ATOMS_SAMELIB_RESULT=""
>> _ruby_atoms_samelib() {
>> _RUBY_ATOMS_SAMELIB_RESULT=""
>>
>> -eshopts_push -o noglob
>> +local shopt_save=$(shopt -p -o noglob)
>^~~~
> Wrong indentation - expanded tab instead of tab
>> +set -f
Thanks!
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 01/11] ruby-ng.eclass: optimize: use pattern for old ruby impls
Hans de Graaff writes: > On Thu, 1970-01-01 at 00:00 +0000, Sam James wrote: >> Not much improvement on a grand scale, but for dev-ruby/sinatra at >> least, we get: > > Reviewed all patches and they look good to me. > > Thanks! And thank you! > > Hans best, sam signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 10/11] ruby-ng.eclass: use shopt directly, not via estack.eclass
Hans de Graaff writes: > On Thu, 1970-01-01 at 00:00 +0000, Sam James wrote: >> ulm points out that estack.eclass is particularly inefficient >> (although >> it'll get slightly better once >> https://github.com/gentoo/gentoo/pull/31437 >> is fixed). >> >> Let's just manually roll it like llvm.eclass does. > > It looks like that was the only use for inhering estack? If so that > inherit can go too, right? Good spot - thanks! > > Hans best, sam signature.asc Description: PGP signature
[gentoo-dev] [PATCH 11/11] ruby-ng.eclass: add _ruby_get_use_targets comment
I don't see us adding a non-ruby* target any time soon so this should be fine.
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index 8fe26057e7ffe..043e3eefcbd68 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -105,6 +105,8 @@ ruby_implementation_depend() {
_ruby_get_all_impls() {
_RUBY_GET_ALL_IMPLS=()
+ # XXX: Please update _ruby_get_use_targets if adding a non-'ruby*'
+ # target.
local i found_valid_impl
for i in ${USE_RUBY}; do
case ${i} in
@@ -350,6 +352,7 @@ _ruby_get_use_targets() {
_ruby_set_globals_invalidate_if_stale
local impls="${_RUBY_GET_ALL_IMPLS[@]}"
+ # XXX: This assumes all targets begin with 'ruby'.
_RUBY_GET_USE_TARGETS="${impls//ruby/ruby_targets_ruby}"
}
--
2.41.0
[gentoo-dev] [PATCH 10/11] ruby-ng.eclass: use shopt directly, not via estack.eclass
ulm points out that estack.eclass is particularly inefficient (although
it'll get slightly better once https://github.com/gentoo/gentoo/pull/31437
is fixed).
Let's just manually roll it like llvm.eclass does.
Bug: https://bugs.gentoo.org/908465
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index 14f4414337d6f..8fe26057e7ffe 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -163,7 +163,8 @@ _RUBY_ATOMS_SAMELIB_RESULT=""
_ruby_atoms_samelib() {
_RUBY_ATOMS_SAMELIB_RESULT=""
- eshopts_push -o noglob
+local shopt_save=$(shopt -p -o noglob)
+ set -f
local token
local atoms=" RUBYTARGET? ("
for token in $*; do
@@ -177,7 +178,7 @@ _ruby_atoms_samelib() {
esac
done
atoms+=" ) "
- eshopts_pop
+ ${shopt_save}
_ruby_set_globals_invalidate_if_stale
local _ruby_implementation
--
2.41.0
[gentoo-dev] [PATCH 09/11] ruby-ng.eclass: cater to USE_RUBY conditional calls
Packages may try to restrict their test dependencies to ease
bootstrapping/porting
if they're not yet available for a newer Ruby implementation by setting
USE_RUBY="" ruby_add_bdepend ...
For example, dev-ruby/parallel does:
```
# Rails isn't yet ruby32-ready in Gentoo
USE_RUBY="ruby27 ruby30 ruby31" ruby_add_bdepend "
test? ( dev-ruby/activerecord[sqlite] )
```
This isn't ideal, but we don't have a ruby_gen_cond_dep right now, so
cater to this usecase by invalidating the caches we've previously added
if we've detected USE_RUBY changed.
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 40
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index 3269ed52cafe0..14f4414337d6f 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -102,8 +102,9 @@ ruby_implementation_depend() {
# @DESCRIPTION:
# Return a list of valid implementations in USE_RUBY, skipping the old
# implementations that are no longer supported.
-_RUBY_GET_ALL_IMPLS=()
_ruby_get_all_impls() {
+ _RUBY_GET_ALL_IMPLS=()
+
local i found_valid_impl
for i in ${USE_RUBY}; do
case ${i} in
@@ -132,6 +133,8 @@ _ruby_get_all_impls() {
ruby_samelib() {
debug-print-function ${FUNCNAME} "${@}"
+ _ruby_set_globals_invalidate_if_stale
+
local res=
for _ruby_implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
has -${_ruby_implementation} $@ || \
@@ -176,6 +179,7 @@ _ruby_atoms_samelib() {
atoms+=" ) "
eshopts_pop
+ _ruby_set_globals_invalidate_if_stale
local _ruby_implementation
for _ruby_implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
_RUBY_ATOMS_SAMELIB_RESULT+="${atoms//RUBYTARGET/ruby_targets_${_ruby_implementation}}"
@@ -227,6 +231,7 @@ ruby_add_rdepend() {
;;
esac
+ _ruby_set_globals_invalidate_if_stale
_ruby_atoms_samelib "$1"
RDEPEND+=" ${_RUBY_ATOMS_SAMELIB_RESULT}"
@@ -274,6 +279,7 @@ ruby_add_bdepend() {
;;
esac
+ _ruby_set_globals_invalidate_if_stale
_ruby_atoms_samelib "$1"
case ${EAPI} in
@@ -300,6 +306,7 @@ ruby_add_depend() {
*) die "bad number of arguments to $0" ;;
esac
+ _ruby_set_globals_invalidate_if_stale
_ruby_atoms_samelib "$1"
DEPEND+=" ${_RUBY_ATOMS_SAMELIB_RESULT}"
@@ -311,6 +318,8 @@ ruby_add_depend() {
ruby_get_use_implementations() {
debug-print-function ${FUNCNAME} "${@}"
+ _ruby_set_globals_invalidate_if_stale
+
local i implementation
for implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
use ruby_targets_${implementation} && i+=" ${implementation}"
@@ -324,6 +333,7 @@ ruby_get_use_implementations() {
ruby_get_use_targets() {
debug-print-function ${FUNCNAME} "${@}"
+ _ruby_set_globals_invalidate_if_stale
_ruby_get_use_targets
echo "${_RUBY_GET_USE_TARGETS}"
}
@@ -336,6 +346,8 @@ _RUBY_GET_USE_TARGETS=""
_ruby_get_use_targets() {
debug-print-function ${FUNCNAME} "${@}"
+ _ruby_set_globals_invalidate_if_stale
+
local impls="${_RUBY_GET_ALL_IMPLS[@]}"
_RUBY_GET_USE_TARGETS="${impls//ruby/ruby_targets_ruby}"
}
@@ -360,11 +372,14 @@ _RUBY_IMPLEMENTATIONS_DEPEND=""
ruby_implementations_depend() {
debug-print-function ${FUNCNAME} "${@}"
+ _ruby_set_globals_invalidate_if_stale
_ruby_implementations_depend
echo "${_RUBY_IMPLEMENTATIONS_DEPEND}"
}
_ruby_implementations_depend() {
+ _ruby_set_globals_invalidate_if_stale
+
local depend _ruby_implementation
for _ruby_implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
depend="${depend}${depend+
}ruby_targets_${_ruby_implementation}? ( $(ruby_implementation_depend
$_ruby_implementation) )"
@@ -372,9 +387,24 @@ _ruby_implementations_depend() {
_RUBY_IMPLEMENTATIONS_DEPEND="${depend}"
}
-_ruby_get_all_impls
-_ruby_get_use_targets
-_ruby_implementations_depend
+_ruby_set_globals() {
+ _RUBY_SET_GLOBALS_USE_RUBY="${USE_RUBY}"
+ _ruby_get_all_impls
+ _ruby_get_use_targets
+ _ruby_implementations_depend
+}
+
+_ruby_set_globals_invalidate_if_stale() {
+ # Packages may try to restrict their test dependencies to ease
bootstrapping/porting
+ # if they're not yet available for a newer Ruby implementation by
setting
+ # USE_RUBY="" ruby_add_bdepend ...
+ if [[ ${_RUBY_SET_GLOBALS_USE_RUBY} != ${USE_RUBY} &
[gentoo-dev] [PATCH 08/11] ruby-ng.eclass: drop no-op RDEPEND assignment
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index f10c987ac44a7..3269ed52cafe0 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -280,7 +280,6 @@ ruby_add_bdepend() {
6) DEPEND+=" ${_RUBY_ATOMS_SAMELIB_RESULT}" ;;
*) BDEPEND+=" ${_RUBY_ATOMS_SAMELIB_RESULT}" ;;
esac
- RDEPEND="${RDEPEND}"
}
# @FUNCTION: ruby_add_depend
--
2.41.0
[gentoo-dev] [PATCH 07/11] ruby-ng.eclass: use bash tests
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index b20c3b4629155..f10c987ac44a7 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -392,7 +392,7 @@ fi
_ruby_invoke_environment() {
old_S=${S}
- if [ -z "${RUBY_S}" ]; then
+ if [[ -z ${RUBY_S} ]]; then
sub_S=${P}
else
sub_S=${RUBY_S}
@@ -728,7 +728,7 @@ ruby-ng_rspec() {
# Explicitly pass the expected spec directory since the versioned
# rspec wrappers don't handle this automatically.
- if [ ${#@} -eq 0 ]; then
+ if [[ $# -eq 0 ]]; then
files="spec"
fi
--
2.41.0
[gentoo-dev] [PATCH 06/11] ruby-ng.eclass: use bash +=
Easier to read.
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index 6c5666ddeabb0..b20c3b4629155 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -229,13 +229,13 @@ ruby_add_rdepend() {
_ruby_atoms_samelib "$1"
- RDEPEND="${RDEPEND} ${_RUBY_ATOMS_SAMELIB_RESULT}"
+ RDEPEND+=" ${_RUBY_ATOMS_SAMELIB_RESULT}"
# Add the dependency as a test-dependency since we're going to
# execute the code during test phase.
case ${EAPI} in
- 6) DEPEND="${DEPEND} test? ( ${_RUBY_ATOMS_SAMELIB_RESULT} )" ;;
- *) BDEPEND="${BDEPEND} test? ( ${_RUBY_ATOMS_SAMELIB_RESULT} )"
;;
+ 6) DEPEND+=" test? ( ${_RUBY_ATOMS_SAMELIB_RESULT} )" ;;
+ *) BDEPEND+=" test? ( ${_RUBY_ATOMS_SAMELIB_RESULT} )" ;;
esac
if ! has test "$IUSE"; then
IUSE+=" test"
@@ -277,8 +277,8 @@ ruby_add_bdepend() {
_ruby_atoms_samelib "$1"
case ${EAPI} in
- 6) DEPEND="${DEPEND} ${_RUBY_ATOMS_SAMELIB_RESULT}" ;;
- *) BDEPEND="${BDEPEND} ${_RUBY_ATOMS_SAMELIB_RESULT}" ;;
+ 6) DEPEND+=" ${_RUBY_ATOMS_SAMELIB_RESULT}" ;;
+ *) BDEPEND+=" ${_RUBY_ATOMS_SAMELIB_RESULT}" ;;
esac
RDEPEND="${RDEPEND}"
}
@@ -303,7 +303,7 @@ ruby_add_depend() {
_ruby_atoms_samelib "$1"
- DEPEND="${DEPEND} ${_RUBY_ATOMS_SAMELIB_RESULT}"
+ DEPEND+=" ${_RUBY_ATOMS_SAMELIB_RESULT}"
}
# @FUNCTION: ruby_get_use_implementations
@@ -381,12 +381,12 @@ IUSE+=" ${_RUBY_GET_USE_TARGETS}"
# If you specify RUBY_OPTIONAL you also need to take care of
# ruby useflag and dependency.
if [[ ${RUBY_OPTIONAL} != yes ]]; then
- DEPEND="${DEPEND} ${_RUBY_IMPLEMENTATIONS_DEPEND}"
- RDEPEND="${RDEPEND} ${_RUBY_IMPLEMENTATIONS_DEPEND}"
+ DEPEND+=" ${_RUBY_IMPLEMENTATIONS_DEPEND}"
+ RDEPEND+=" ${_RUBY_IMPLEMENTATIONS_DEPEND}"
REQUIRED_USE+=" || ( ${_RUBY_GET_USE_TARGETS} )"
case ${EAPI} in
6) ;;
- *) BDEPEND="${BDEPEND} ${_RUBY_IMPLEMENTATIONS_DEPEND}" ;;
+ *) BDEPEND+=" ${_RUBY_IMPLEMENTATIONS_DEPEND}" ;;
esac
fi
--
2.41.0
[gentoo-dev] [PATCH 05/11] ruby-ng.eclass: optimize: avoid subshells for ruby_implementations_depend, ruby_get_use_targets
We go from 2.5s -> 1.9s to source dev-ruby/*.
Bug: https://bugs.gentoo.org/908465
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index cf66fcec2f05d..6c5666ddeabb0 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -325,9 +325,20 @@ ruby_get_use_implementations() {
ruby_get_use_targets() {
debug-print-function ${FUNCNAME} "${@}"
- _ruby_get_all_impls
+ _ruby_get_use_targets
+ echo "${_RUBY_GET_USE_TARGETS}"
+}
+
+# @FUNCTION: _ruby_get_use_targets
+# @INTERNAL
+# @DESCRIPTION:
+# Gets an array of ruby use targets that the ebuild sets
+_RUBY_GET_USE_TARGETS=""
+_ruby_get_use_targets() {
+ debug-print-function ${FUNCNAME} "${@}"
+
local impls="${_RUBY_GET_ALL_IMPLS[@]}"
- echo "${impls//ruby/ruby_targets_ruby}"
+ _RUBY_GET_USE_TARGETS="${impls//ruby/ruby_targets_ruby}"
}
# @FUNCTION: ruby_implementations_depend
@@ -346,27 +357,36 @@ ruby_get_use_targets() {
# ...
# DEPEND="ruby? ( $(ruby_implementations_depend) )"
# RDEPEND="${DEPEND}"
+_RUBY_IMPLEMENTATIONS_DEPEND=""
ruby_implementations_depend() {
debug-print-function ${FUNCNAME} "${@}"
+ _ruby_implementations_depend
+ echo "${_RUBY_IMPLEMENTATIONS_DEPEND}"
+}
+
+_ruby_implementations_depend() {
+ local depend _ruby_implementation
for _ruby_implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
depend="${depend}${depend+
}ruby_targets_${_ruby_implementation}? ( $(ruby_implementation_depend
$_ruby_implementation) )"
done
- echo "${depend}"
+ _RUBY_IMPLEMENTATIONS_DEPEND="${depend}"
}
_ruby_get_all_impls
+_ruby_get_use_targets
+_ruby_implementations_depend
-IUSE+=" $(ruby_get_use_targets)"
+IUSE+=" ${_RUBY_GET_USE_TARGETS}"
# If you specify RUBY_OPTIONAL you also need to take care of
# ruby useflag and dependency.
if [[ ${RUBY_OPTIONAL} != yes ]]; then
- DEPEND="${DEPEND} $(ruby_implementations_depend)"
- RDEPEND="${RDEPEND} $(ruby_implementations_depend)"
- REQUIRED_USE+=" || ( $(ruby_get_use_targets) )"
+ DEPEND="${DEPEND} ${_RUBY_IMPLEMENTATIONS_DEPEND}"
+ RDEPEND="${RDEPEND} ${_RUBY_IMPLEMENTATIONS_DEPEND}"
+ REQUIRED_USE+=" || ( ${_RUBY_GET_USE_TARGETS} )"
case ${EAPI} in
6) ;;
- *) BDEPEND="${BDEPEND} $(ruby_implementations_depend)" ;;
+ *) BDEPEND="${BDEPEND} ${_RUBY_IMPLEMENTATIONS_DEPEND}" ;;
esac
fi
--
2.41.0
[gentoo-dev] [PATCH 04/11] ruby-ng.eclass: optimize: avoid subshells for _ruby_atoms_samelib*
- Inline ruby_atoms_samelib (only used by one caller)
- Avoid repeated (subshell) calls to _ruby_atoms_samelib_generic by using a
result
variable instead.
We go from 3.5s -> 2.5s to source dev-ruby/*.
Thanks to mgorny for the ideas here.
Bug: https://bugs.gentoo.org/908465
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 57 ++-
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index ee2e6b89edb41..cf66fcec2f05d 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -141,23 +141,6 @@ ruby_samelib() {
echo "[${res%,}]"
}
-_ruby_atoms_samelib_generic() {
- eshopts_push -o noglob
- echo "RUBYTARGET? ("
- for token in $*; do
- case "$token" in
- "||" | "(" | ")" | *"?")
- echo "${token}" ;;
- *])
- echo "${token%[*}[RUBYTARGET(-),${token/*[}" ;;
- *)
- echo "${token}[RUBYTARGET(-)]" ;;
- esac
- done
- echo ")"
- eshopts_pop
-}
-
# @FUNCTION: ruby_implementation_command
# @RETURN: the path to the given ruby implementation
# @DESCRIPTION:
@@ -173,11 +156,29 @@ ruby_implementation_command() {
echo $(type -p ${_ruby_name} 2>/dev/null)
}
+_RUBY_ATOMS_SAMELIB_RESULT=""
_ruby_atoms_samelib() {
- local atoms=$(_ruby_atoms_samelib_generic "$*")
+ _RUBY_ATOMS_SAMELIB_RESULT=""
+
+ eshopts_push -o noglob
+ local token
+ local atoms=" RUBYTARGET? ("
+ for token in $*; do
+ case "${token}" in
+ "||" | "(" | ")" | *"?")
+ atoms+=" ${token}" ;;
+ *])
+ atoms+=" ${token%[*}[RUBYTARGET(-),${token/*[}"
;;
+ *)
+ atoms+=" ${token}[RUBYTARGET(-)]" ;;
+ esac
+ done
+ atoms+=" ) "
+ eshopts_pop
+ local _ruby_implementation
for _ruby_implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
- echo "${atoms//RUBYTARGET/ruby_targets_${_ruby_implementation}}"
+
_RUBY_ATOMS_SAMELIB_RESULT+="${atoms//RUBYTARGET/ruby_targets_${_ruby_implementation}}"
done
}
@@ -226,15 +227,15 @@ ruby_add_rdepend() {
;;
esac
- local dependency=$(_ruby_atoms_samelib "$1")
+ _ruby_atoms_samelib "$1"
- RDEPEND="${RDEPEND} $dependency"
+ RDEPEND="${RDEPEND} ${_RUBY_ATOMS_SAMELIB_RESULT}"
# Add the dependency as a test-dependency since we're going to
# execute the code during test phase.
case ${EAPI} in
- 6) DEPEND="${DEPEND} test? ( ${dependency} )" ;;
- *) BDEPEND="${BDEPEND} test? ( ${dependency} )" ;;
+ 6) DEPEND="${DEPEND} test? ( ${_RUBY_ATOMS_SAMELIB_RESULT} )" ;;
+ *) BDEPEND="${BDEPEND} test? ( ${_RUBY_ATOMS_SAMELIB_RESULT} )"
;;
esac
if ! has test "$IUSE"; then
IUSE+=" test"
@@ -273,11 +274,11 @@ ruby_add_bdepend() {
;;
esac
- local dependency=$(_ruby_atoms_samelib "$1")
+ _ruby_atoms_samelib "$1"
case ${EAPI} in
- 6) DEPEND="${DEPEND} $dependency" ;;
- *) BDEPEND="${BDEPEND} $dependency" ;;
+ 6) DEPEND="${DEPEND} ${_RUBY_ATOMS_SAMELIB_RESULT}" ;;
+ *) BDEPEND="${BDEPEND} ${_RUBY_ATOMS_SAMELIB_RESULT}" ;;
esac
RDEPEND="${RDEPEND}"
}
@@ -300,9 +301,9 @@ ruby_add_depend() {
*) die "bad number of arguments to $0" ;;
esac
- local dependency=$(_ruby_atoms_samelib "$1")
+ _ruby_atoms_samelib "$1"
- DEPEND="${DEPEND} $dependency"
+ DEPEND="${DEPEND} ${_RUBY_ATOMS_SAMELIB_RESULT}"
}
# @FUNCTION: ruby_get_use_implementations
--
2.41.0
[gentoo-dev] [PATCH 03/11] ruby-ng.eclass: optimize: avoid subshell for ruby_get_all_impls
We go from ~4s -> ~3.5s for sourcing dev-ruby/*.
For sinatra:
```
$ pk pkg source $(pkg) --repo ~/g/ --bench 5s # before
dev-ruby/sinatra-2.2.3::/home/sam/g/: mean: 66.68ms, min: 56.938ms, max:
74.248ms, σ = 4.832ms, N = 75
dev-ruby/sinatra-3.0.6::/home/sam/g/: mean: 73.618ms, min: 60.153ms, max:
77.978ms, σ = 3.195ms, N = 68
dev-ruby/sinatra-3.0.5::/home/sam/g/: mean: 72.069ms, min: 58.736ms, max:
78.223ms, σ = 3.277ms, N = 70
dev-ruby/sinatra-3.0.5-r1::/home/sam/g/: mean: 73.265ms, min: 60.738ms, max:
81.06ms, σ = 3.227ms, N = 69
$ pk pkg source $(pkg) --repo ~/g/ --bench 5s # after
dev-ruby/sinatra-3.0.5-r1::/home/sam/g/: mean: 59.677ms, min: 49.141ms, max:
63.282ms, σ = 2.511ms, N = 84
dev-ruby/sinatra-3.0.6::/home/sam/g/: mean: 59.693ms, min: 48.637ms, max:
62.862ms, σ = 2.628ms, N = 84
dev-ruby/sinatra-3.0.5::/home/sam/g/: mean: 56.697ms, min: 46.782ms, max:
60.367ms, σ = 2.822ms, N = 89
dev-ruby/sinatra-2.2.3::/home/sam/g/: mean: 54.915ms, min: 45.832ms, max:
59.513ms, σ = 3.52ms, N = 92
```
Bug: https://bugs.gentoo.org/908465
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index 2bf1885d38031..ee2e6b89edb41 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -102,6 +102,7 @@ ruby_implementation_depend() {
# @DESCRIPTION:
# Return a list of valid implementations in USE_RUBY, skipping the old
# implementations that are no longer supported.
+_RUBY_GET_ALL_IMPLS=()
_ruby_get_all_impls() {
local i found_valid_impl
for i in ${USE_RUBY}; do
@@ -111,7 +112,8 @@ _ruby_get_all_impls() {
;;
*)
found_valid_impl=1
- echo ${i};;
+ _RUBY_GET_ALL_IMPLS+=( ${i} )
+ ;;
esac
done
@@ -131,7 +133,7 @@ ruby_samelib() {
debug-print-function ${FUNCNAME} "${@}"
local res=
- for _ruby_implementation in $(_ruby_get_all_impls); do
+ for _ruby_implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
has -${_ruby_implementation} $@ || \
res="${res}ruby_targets_${_ruby_implementation}(-)?,"
done
@@ -174,7 +176,7 @@ ruby_implementation_command() {
_ruby_atoms_samelib() {
local atoms=$(_ruby_atoms_samelib_generic "$*")
- for _ruby_implementation in $(_ruby_get_all_impls); do
+ for _ruby_implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
echo "${atoms//RUBYTARGET/ruby_targets_${_ruby_implementation}}"
done
}
@@ -310,7 +312,7 @@ ruby_get_use_implementations() {
debug-print-function ${FUNCNAME} "${@}"
local i implementation
- for implementation in $(_ruby_get_all_impls); do
+ for implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
use ruby_targets_${implementation} && i+=" ${implementation}"
done
echo $i
@@ -322,8 +324,8 @@ ruby_get_use_implementations() {
ruby_get_use_targets() {
debug-print-function ${FUNCNAME} "${@}"
-
- local impls="$(_ruby_get_all_impls)"
+ _ruby_get_all_impls
+ local impls="${_RUBY_GET_ALL_IMPLS[@]}"
echo "${impls//ruby/ruby_targets_ruby}"
}
@@ -346,13 +348,14 @@ ruby_get_use_targets() {
ruby_implementations_depend() {
debug-print-function ${FUNCNAME} "${@}"
- local depend
- for _ruby_implementation in $(_ruby_get_all_impls); do
+ for _ruby_implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
depend="${depend}${depend+
}ruby_targets_${_ruby_implementation}? ( $(ruby_implementation_depend
$_ruby_implementation) )"
done
echo "${depend}"
}
+_ruby_get_all_impls
+
IUSE+=" $(ruby_get_use_targets)"
# If you specify RUBY_OPTIONAL you also need to take care of
# ruby useflag and dependency.
@@ -412,7 +415,7 @@ _ruby_invoke_environment() {
_ruby_each_implementation() {
local invoked=no
- for _ruby_implementation in $(_ruby_get_all_impls); do
+ for _ruby_implementation in "${_RUBY_GET_ALL_IMPLS[@]}"; do
# only proceed if it's requested
use ruby_targets_${_ruby_implementation} || continue
@@ -435,7 +438,7 @@ _ruby_each_implementation() {
if [[ ${invoked} == "no" ]]; then
eerror "You need to select at least one compatible Ruby
installation target via RUBY_TARGETS in make.conf."
- eerror "Compatible targets for this package are:
$(_ruby_get_all_impls)"
+ eerror "Compatible targets for this package are:
${_RUBY_GET_ALL_IMPLS[@]}"
eerror
eerror "See
https://www.gentoo.org/proj/en/prog_lang/ruby/index.xml#doc_chap3 for more
information."
eerror
--
2.41.0
[gentoo-dev] [PATCH 02/11] ruby-ng.eclass: optimize: use pattern substitution
We can save a little bit (consistently a few ms) by using patsubs in some
obvious cases.
Not really any difference globally, but for sinatra:
```
$ pk pkg source $(pkg) --repo ~/g/ --bench 5s # before
dev-ruby/sinatra-3.0.5::/home/sam/g/: mean: 76.25ms, min: 59.23ms, max:
83.674ms, σ = 4.247ms, N = 66
dev-ruby/sinatra-3.0.5-r1::/home/sam/g/: mean: 77.465ms, min: 61.782ms, max:
85.127ms, σ = 3.592ms, N = 65
dev-ruby/sinatra-3.0.6::/home/sam/g/: mean: 80.192ms, min: 60.922ms, max:
84.951ms, σ = 3.899ms, N = 63
dev-ruby/sinatra-2.2.3::/home/sam/g/: mean: 80.389ms, min: 56.818ms, max:
86.915ms, σ = 4.508ms, N = 63
$ pk pkg source $(pkg) --repo ~/g/ --bench 5s # after
dev-ruby/sinatra-2.2.3::/home/sam/g/: mean: 66.68ms, min: 56.938ms, max:
74.248ms, σ = 4.832ms, N = 75
dev-ruby/sinatra-3.0.6::/home/sam/g/: mean: 73.618ms, min: 60.153ms, max:
77.978ms, σ = 3.195ms, N = 68
dev-ruby/sinatra-3.0.5::/home/sam/g/: mean: 72.069ms, min: 58.736ms, max:
78.223ms, σ = 3.277ms, N = 70
dev-ruby/sinatra-3.0.5-r1::/home/sam/g/: mean: 73.265ms, min: 60.738ms, max:
81.06ms, σ = 3.227ms, N = 69
```
Bug: https://bugs.gentoo.org/908465
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index 5a6edb1bf6080..2bf1885d38031 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -183,11 +183,11 @@ _ruby_wrap_conditions() {
local conditions="$1"
local atoms="$2"
- for condition in $conditions; do
+ for condition in ${conditions}; do
atoms="${condition}? ( ${atoms} )"
done
- echo "$atoms"
+ echo "${atoms}"
}
# @FUNCTION: ruby_add_rdepend
@@ -322,11 +322,9 @@ ruby_get_use_implementations() {
ruby_get_use_targets() {
debug-print-function ${FUNCNAME} "${@}"
- local t implementation
- for implementation in $(_ruby_get_all_impls); do
- t+=" ruby_targets_${implementation}"
- done
- echo $t
+
+ local impls="$(_ruby_get_all_impls)"
+ echo "${impls//ruby/ruby_targets_ruby}"
}
# @FUNCTION: ruby_implementations_depend
--
2.41.0
[gentoo-dev] [PATCH 01/11] ruby-ng.eclass: optimize: use pattern for old ruby impls
Not much improvement on a grand scale, but for dev-ruby/sinatra at least, we
get:
```
$ pk pkg source $(pkg) --repo ~/g/ --bench 5s # before
dev-ruby/sinatra-3.0.5::/home/sam/g/: mean: 76.25ms, min: 59.23ms, max:
83.674ms, σ = 4.247ms, N = 66
dev-ruby/sinatra-3.0.5-r1::/home/sam/g/: mean: 77.465ms, min: 61.782ms, max:
85.127ms, σ = 3.592ms, N = 65
dev-ruby/sinatra-3.0.6::/home/sam/g/: mean: 80.192ms, min: 60.922ms, max:
84.951ms, σ = 3.899ms, N = 63
dev-ruby/sinatra-2.2.3::/home/sam/g/: mean: 80.389ms, min: 56.818ms, max:
86.915ms, σ = 4.508ms, N = 63
$ pk pkg source $(pkg) --repo ~/g/ --bench 5s # after
dev-ruby/sinatra-3.0.6::/home/sam/g/: mean: 72.761ms, min: 58.627ms, max:
76.161ms, σ = 3.276ms, N = 69
dev-ruby/sinatra-3.0.5-r1::/home/sam/g/: mean: 72.967ms, min: 60.127ms, max:
76.75ms, σ = 3.176ms, N = 69
dev-ruby/sinatra-3.0.5::/home/sam/g/: mean: 69.004ms, min: 58.344ms, max:
73.661ms, σ = 3.3ms, N = 73
dev-ruby/sinatra-2.2.3::/home/sam/g/: mean: 71.061ms, min: 55.144ms, max:
74.563ms, σ = 3.848ms, N = 71
```
A tiny, but seemingly consistent improvement.
Thanks to mgorny for the idea.
Bug: https://bugs.gentoo.org/908465
Signed-off-by: Sam James
---
eclass/ruby-ng.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index 8befa086ef020..5a6edb1bf6080 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -107,7 +107,7 @@ _ruby_get_all_impls() {
for i in ${USE_RUBY}; do
case ${i} in
# removed implementations
-
ruby19|ruby20|ruby21|ruby22|ruby23|ruby24|ruby25|ruby26|ruby27|jruby)
+ ruby19|ruby2[0-7]|jruby)
;;
*)
found_valid_impl=1
--
2.41.0
Re: [gentoo-dev] What happened to gcc-12.3.0?
Joshua Kinard writes: > Noticing that the ebuild for gcc-12.3.0 got dropped with little > explanation. It is the upstream stable release. I am eyeballing > #906310 as what may have triggered the drop, but I find it a bit of a > stretch that an upstream stable release got dropped over a single, > optional package that has a history of quirky behavior (FWIW, I never > had luck with ccache, especially on MIPS). Please see https://bugs.gentoo.org/908258. There were miscompilations even fixed after 12.3.0 was tagged. (Also, ccache really isn't a "package with quirky behaviour" in terms of whether or not it causes gcc to ICE. It has nothing to do with what ccache itself does at runtime.) >> > Under qemu, it takes about 4 hours to build the single-ABI variant of > gcc and 7 hours for the multilib variant. So I avoid rebuilding the > compiler as much as possible, as with six chroots, that's virtually an > entire day across all six just for gcc, minus distractions (seriously, > the build times on gcc are getting waaay out of hand, regardless > of arch). It should get a bit better as of recent 13 as we backported a change to help parallel builds at least (and reduce resource consumption). (Also, added toolchain@ to CC...) signature.asc Description: PGP signature
Re: [gentoo-dev] A problem with updating my key (again)
Andrey Grozin writes: > Hi *, > > My key was going to expire soon. So, as usual, I have prolonged it for > the next year (several days ago). I've sent it to the Gentoo > keyserver. I've checked that the fingerpring of my key in LDAP > coinsides with the fingerprint I see locally. > > Today I've tried to bump dev-lisp/sbcl to 2.3.5. But I got > > remote: *** None of your keys comply with GLEP 63. > remote: Please update the keys into conformance if you wish to > continue > remote: using them. If not, please remove unused keys from LDAP. > remote: FATAL: VREF/proj-gentoo-02-gpg: helper program exit status 256 > remote: 53D4ABFA88DD61C4 [Andrey Grozin (science) ] > [E] expire:short Expiration date is too close, please renew (is > 2023-06-17 15:32:53, less than 14 days) > remote: 53D4ABFA88DD61C4:3AFFCE974D34BD8C [Andrey Grozin (science) > ] [E] expire:short Expiration date is too close, > please renew (is 2023-06-17 15:34:59, less than 14 days) > remote: error: hook declined to update refs/heads/master > To git.gentoo.org:repo/gentoo.git > ! [remote rejected] master -> master (hook declined) > error: failed to push some refs to 'git.gentoo.org:repo/gentoo.git' > > It seems that the remote git has ignored the fact that my key has been > prolonged about 3 days ago. One year ago I had the same situation. Is > there any reliable way to inform this git hook about the prolongation > of my key? > > Every year the same problem :-( You should ping in #gentoo-infra on IRC if you're having trouble, or file a bug in the Gentoo Infrastructure component. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] go-module.eclass: inline _go-module_gomod_encode()
Florian Schmaus writes:
> The only call site of _go-module_gomod_encode() was using $() in a loop
> over EGO_SUM. This caused bash to fork() for every loop iteration, which
> significantly affected the time it takes to "source" an ebuild using
> EGO_SUM.
>
> For example, "pkg pkg source =sys-cluster/k3s-1.23.3_p1" previously took
> 2.4 seconds. Inlining _go-module_gomod_encode() reduces this to
> 236 milliseconds.
>
> This also adds missing 'local' declarations for some variables.
Nice one & lgtm, thanks!
But please remember to CC eclass maintainers (done now). If you did and
I missed it, apologies.
>
> Signed-off-by: Florian Schmaus
> ---
> eclass/go-module.eclass | 44 +++--
> 1 file changed, 16 insertions(+), 28 deletions(-)
>
> diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> index f97b69f591c8..6c58d7f26f07 100644
> --- a/eclass/go-module.eclass
> +++ b/eclass/go-module.eclass
> @@ -262,7 +262,22 @@ go-module_set_globals() {
> continue
> fi
>
> - _dir=$(_go-module_gomod_encode "${module}")
> + # Encode the name(path) of a Golang module in the format
> expected by Goproxy.
> + # Upper letters are replaced by their lowercase version with a
> '!' prefix.
> + # The transformed result of 'module' is stored in the '_dir'
> variable.
> + #
> + ## Python:
> + # return re.sub('([A-Z]{1})', r'!\1', s).lower()
> + ## Sed:
> + ## This uses GNU Sed extension \l to downcase the match
> + # echo "${module}" |sed 's,[A-Z],!\l&,g'
> + local re _dir lower
> + _dir="${module}"
> + re='(.*)([A-Z])(.*)'
> + while [[ ${_dir} =~ ${re} ]]; do
> + lower='!'"${BASH_REMATCH[2],}"
> + _dir="${BASH_REMATCH[1]}${lower}${BASH_REMATCH[3]}"
> + done
>
> for _ext in "${exts[@]}" ; do
> # Relative URI within a GOPROXY for a file
> @@ -496,33 +511,6 @@ go-module_live_vendor() {
> popd >& /dev/null || die
> }
>
> -# @FUNCTION: _go-module_gomod_encode
> -# @DEPRECATED: none
> -# @DESCRIPTION:
> -# Encode the name(path) of a Golang module in the format expected by Goproxy.
> -#
> -# Upper letters are replaced by their lowercase version with a '!' prefix.
> -#
> -_go-module_gomod_encode() {
> - ## Python:
> - # return re.sub('([A-Z]{1})', r'!\1', s).lower()
> -
> - ## Sed:
> - ## This uses GNU Sed extension \l to downcase the match
> - #echo "${module}" |sed 's,[A-Z],!\l&,g'
> - #
> - # Bash variant:
> - debug-print-function "${FUNCNAME}" "$@"
> - #local re input lower
> - re='(.*)([A-Z])(.*)'
> - input="${1}"
> - while [[ ${input} =~ ${re} ]]; do
> - lower='!'"${BASH_REMATCH[2],}"
> - input="${BASH_REMATCH[1]}${lower}${BASH_REMATCH[3]}"
> - done
> - echo "${input}"
> -}
> -
> fi
>
> if [[ ! ${GO_OPTIONAL} ]]; then
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: dev-ruby/ruby-gtk2
# Sam James (2023-06-12) # Installs no files with newer versions because GTK 2 support was dropped upstream. # Removal on 2023-07-12. Bug #908378. dev-ruby/ruby-gtk2 signature.asc Description: PGP signature
Re: [gentoo-dev] www-client/chromium needs a new maintainer
Alexe Stefan writes: > I don't use chromium and I don't know what release cycle it has, but can't > those interested in running chromium use an > ebuild that tracks the git tree and updates after every change. > The maintenance burden would be minimal, and any patches could be applied > with /etc/portage/patches. > If something like this isn't suitable for ::gentoo, it can be added to a > personal overlay. > If the upstream release cycle is too fast, someone could fork the repo and > update the fork as slow as desired. > Maybe something like this: > # Copyright 1999-2023 Gentoo Authors No, this misses the point about what's hard - keeping things building. Let's try to keep speculation down, please. This is already a complicated topic without guessing. signature.asc Description: PGP signature
Re: [gentoo-dev] www-client/chromium needs a new maintainer
Jeff Gazso writes: > That does sound painful. > >> - Across the 3 channels, you are looking at roughly 12 releases per month. >> That's a lot of churn. > > * Why build unstable stuff, why not build only stable releases and fix the > problems once? The idea is that you end up fixing stuff before you have a big mountain of things to fix in stable. I don't know if that's necessary nowadays or not, but that's the concept, I think. > > * Looking at chromium-browser-official and the GitHub mirror, it's unclear to > me which release is stable. How is that sorted out? > The chrome release blog announces the changes. >> - Upstream likes to use modern C++ features, and they write C++ code that >> tends to break or is unsupported on stable releases of GCC and LLVM. > > * How common of a problem is the C++ issue? > Depends on if we want to keep GCC working. > * I don't know C++, is that a major obstacle? > You will need to know at least a little bit (or learn it) to fix problems. >> - Upstream bundles many libraries. The Gentoo ebuild has some logic to >> unbundle a number of these, but maintaining it is a pain. > > * What tends to go wrong? > >> - Using the bundled libraries sometimes is problematic, especially on >> non-x86-64 targets which upstream doesn't support well. > > * What tends to break here? > https://bugs.gentoo.org/904850 was an example of an arm64-only bug, although it was an easy fix. > * Is the upstream likely to take patches or are we stuck maintaining a patch > set for pretty much all non-x86-64 targets? > > * Is this why Sam maintains a bunch of PPC64 patches? Do these ever make > their way upstream? I don't maintain those - that's somebody else. The PPC64 patches originate from Raptor who produce PPC64 workstations and I think the community helps maintain them. Upstream tend to not want patches for things they can't test in CI. (Also, please don't top-post - quote and reply underneath an email.) >k signature.asc Description: PGP signature
Re: [gentoo-dev] www-client/chromium needs a new maintainer
Toralf Förster writes: > [[PGP Signed Part:Undecided]] > On 6/7/23 15:09, Jeff Gazso wrote: >> Can you give me a list >> of common pain points? > > My wish would be a -bin package. > Even with -j12 it takes here 5-6 hours compile time, which is a pain. That's more work for the maintainer, not less. We've just last-rited chromium-bin because manually building it is too much hassle. Jeff is asking what makes maintaining chromium hard. signature.asc Description: PGP signature
