Re: [gentoo-dev] GCC 14 unleashed
Sam James writes: Oh, and: > * The code was broken before (badly) [...] ... and therefore you should be revbumping for fixes. signature.asc Description: PGP signature
[gentoo-dev] GCC 14 unleashed
Hi, As we discussed a bunch in #gentoo-toolchain over the last few weeks, GCC 14 is now in ~arch. We've spent the last > 2 years working on this and fixing lots of packages, but kind of reached the limit of how much a handful of people can do. This is kind of the analogue of the Clang post I made a while ago [0]. It makes a lot of dangerous, broken C constructs errors by default. We have a writeup at https://wiki.gentoo.org/wiki/Modern_C_porting. See also https://gcc.gnu.org/gcc-14/porting_to.html. Advice: * Please ask us in #gentoo-toolchain if you need help understanding how to fix a bug. You may have users submitting patches, but please ask if you're unsure if they're correct. * Please only add casts if you're sure they're right. Otherwise, they're just suppressing it. * Report upstream immediately if you see an issue, even if you don't yet have time to try fix it yourself. This means upstream can work on it in the background and other distros and folks may end up sharing their patches. * Similarly, it's paramount that patches get submitted upstream so they can be reviewed and other distros can benefit. We have benefitted a lot from others doing that, and vice-versa. * The code was broken before (badly) and this just surfaces that. -Wno-error=* and friends are not an option. The wiki page covers that but I can explain it more if needed. The tracker bugs are: * https://bugs.gentoo.org/870412 (c99-porting) * https://bugs.gentoo.org/906027 (implicit-in-configure) * https://bugs.gentoo.org/914580 (gcc-14, general; only use for other issues) The implicit-in-configure issues are more important than c99-porting because of the risk of a misconfigured build. [0] https://public-inbox.gentoo.org/gentoo-dev/87tu4c8z49@mop.mail-host-address-is-not-set/ thanks, sam signature.asc Description: PGP signature
[gentoo-dev] Last rites: sci-libs/beagle
# Eli Schwartz (2024-05-17) # Last updated in 2007, has no reverse dependencies, is unmaintained upstream # (in 2010 a version 4 alpha was released using cmake, the project has seen no # other activity upstream). Fails to build with dash, lto. # Bug #862669, #890423. # Removal on 2024-06-16. sci-libs/beagle
Re: [gentoo-dev] [PATCH 0/2] edo.eclass: enhace edob for usage with nosiy commands
Florian Schmaus writes: > The motivation for this change is to allow edob to be used with noisy > commands, i.e., commands that produce a lot of output, in cases where > the output is in general not of interest. However, if the command > fails, the output should be shown and appear in build.log. > > We do this by simply redirecting the output to a file in $T, and show > this file if the command returned a non-zero exit status. > > We already have a few cases in ::gentoo where such output is simply > redirected to /dev/null, hindering post-mortem analysis. Those could > be converted to edob with its new behavior. > > PR at https://github.com/gentoo/gentoo/pull/36117 > LGTM. I agree there's value in it. > Florian Schmaus (2): > edo.eclass: enhace edob for usage with nosiy commands s/nosiy/noisy/ > eftmutil-sys: use edob > > eclass/edo.eclass| 54 > eclass/texlive-common.eclass | 8 -- > 2 files changed, 53 insertions(+), 9 deletions(-)
Re: [gentoo-portage-dev] [PATCH 0/2] Minor documentation fixups
Bryan Gardiner writes: > Just fixes for a couple of small documentation issues I found. Applied - thanks! > > Bryan Gardiner (2): > depgraph.py: Fix the URL for the changed-deps wiki page > ebuild.5: Escape carats which are special to groff > > lib/_emerge/depgraph.py | 2 +- > man/ebuild.5| 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-)
Re: [gentoo-dev] [PATCH] cargo.eclass: Optimize crate unpacking
Michał Górny writes:
> Unpack crates in parallel using xargs to utilize multicore systems
> better. Perform checksumming via a single sha256sum invocation.
>
> For dev-python/watchfiles, this speeds up unpacking on my machine
> from 2.6 s to 0.75 s (warm cache).
>
> Signed-off-by: Michał Górny
For completeness (acked on PR), lgtm. I assume tested by building
all cargo inheritees (nearly said 'heirs' but.. lol)?
Give a chance for others to look though.
Also, thank you!
> ---
> eclass/cargo.eclass | 56 ++---
> 1 file changed, 33 insertions(+), 23 deletions(-)
>
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index 0f2da982f60c..5a16d3a30528 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -329,40 +329,50 @@ _cargo_gen_git_config() {
> cargo_src_unpack() {
> debug-print-function ${FUNCNAME} "$@"
>
> - mkdir -p "${ECARGO_VENDOR}" || die
> - mkdir -p "${S}" || die
> + mkdir -p "${ECARGO_VENDOR}" "${S}" || die
>
> local archive shasum pkg
> + local crates=()
> for archive in ${A}; do
> case "${archive}" in
> *.crate)
> - # when called by pkgdiff-mg, do not unpack
> crates
> - [[ ${PKGBUMPING} == ${PVR} ]] && continue
> -
> - ebegin "Loading ${archive} into Cargo registry"
> - tar -xf "${DISTDIR}"/${archive} -C
> "${ECARGO_VENDOR}/" || die
> - # generate sha256sum of the crate itself as
> cargo needs this
> - shasum=$(sha256sum "${DISTDIR}"/${archive} |
> cut -d ' ' -f 1)
> - pkg=$(basename ${archive} .crate)
> - cat <<- EOF >
> ${ECARGO_VENDOR}/${pkg}/.cargo-checksum.json
> - {
> - "package": "${shasum}",
> - "files": {}
> - }
> - EOF
> - # if this is our target package we need it in
> ${WORKDIR} too
> - # to make ${S} (and handle any revisions too)
> - if [[ ${P} == ${pkg}* ]]; then
> - tar -xf "${DISTDIR}"/${archive} -C
> "${WORKDIR}" || die
> - fi
> - eend $?
> + crates+=( "${archive}" )
> ;;
> *)
> - unpack ${archive}
> + unpack "${archive}"
> ;;
> esac
> done
>
> + if [[ ${PKGBUMPING} != ${PVR} ]]; then
> + pushd "${DISTDIR}" >/dev/null || die
> +
> + ebegin "Unpacking crates"
> + printf '%s\0' "${crates[@]}" |
> + xargs -0 -P "$(makeopts_jobs)" -n 1 -- \
> + tar -x -C "${ECARGO_VENDOR}" -f
> + assert
> + eend $?
> +
> + while read -d '' -r shasum archive; do
> + pkg=${archive%.crate}
> + cat <<- EOF >
> ${ECARGO_VENDOR}/${pkg}/.cargo-checksum.json || die
> + {
> + "package": "${shasum}",
> + "files": {}
> + }
> + EOF
> +
> + # if this is our target package we need it in
> ${WORKDIR} too
> + # to make ${S} (and handle any revisions too)
> + if [[ ${P} == ${pkg}* ]]; then
> + tar -xf "${archive}" -C "${WORKDIR}" || die
> + fi
> + done < <(sha256sum -z "${crates[@]}" || die)
> +
> + popd >/dev/null || die
> + fi
> +
> cargo_gen_config
> }
Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
Martin Dummer writes: > Am 09.05.24 um 14:13 schrieb Sam James: > > Martin Dummer writes: > > > Maybe we can agree that the qa-warnings in vdr-eclass make more sense if i > change them to "eawarn" or "einfo"? > > > Sure, make them eqawarn. > > Hmm - current state of vdr-plugin-2.eclass is: there are many "eqawarn" in > there. > > > In my opinion, most plugins in the vdr context will practically not develop > any further anyway. It is more > important to > keep the current status of vdr-software in the ecosystem up to date as well > as possible. > > So I need a practical useful approach instead of a fundamental discussion > please. > > > My point is that the QA warnings should exist, and you can worry about > making them "developer-only" in future. Right now, they seem useful, and > the things they flag need to be addressed. > > Basically yes, but here (vdr-plugins) the qawarn are used more in a way "to > remind the plugin developers to adapt their > sources to newer vdr build environment" or "the way i18n implemented has > changed" > > The eclass fixes these problems with standardized quirks, the "equawarn" > messages show when these quirks are applied. > > IMHO its not necessary to tell that to any user, only for interested > packagers when they are bored and look out for some > extra work. That's why I made the warnings conditional, printed out when the > variable "VDR_MAINTAINTER_MODE" is set to a > not-empty value. > > Finally, I am interested in an opinion whether this is acceptable or not, > otherwise I tend to remove the warnings at all. It sounds like maybe you want to turn these into log messages (einfo - https://devmanual.gentoo.org/ebuild-writing/messages/index.html), and drop the "QA notice" prefix.
Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
Martin Dummer writes: > Am 03.05.24 um 06:39 schrieb Sam James: > > > What we really need is: > a) https://bugs.gentoo.org/162450 to avoid scaring users; > b) possibly some level of QA notice to distinguish between "check this > out" (think e.g. qa-vdb LHS where it _might_ be unused, but not > necessarily), and "this is definitely wrong" > > I am convinced we need a), I am not-at-all convinced we need b) - at > least not in terms of whether bugs are reported. > > AFAIS https://bugs.gentoo.org/162450 is not implemented. Right, that's why I didn't say "we can just use". > > Maybe we can agree that the qa-warnings in vdr-eclass make more sense if i > change them to "eawarn" or "einfo"? > Sure, make them eqawarn. > In my opinion, most plugins in the vdr context will practically not develop > any further anyway. It is more important to > keep the current status of vdr-software in the ecosystem up to date as well > as possible. > > So I need a practical useful approach instead of a fundamental discussion > please. My point is that the QA warnings should exist, and you can worry about making them "developer-only" in future. Right now, they seem useful, and the things they flag need to be addressed.
[gentoo-dev] Last rites: net-irc/ninja
# Eli Schwartz (2024-05-08) # Fails to configure with GCC 14, fails to install with older # gcc, unmaintained, upstream website vanished. # Bug #731180, #861461, #888577, #889930. # Removal on 2024-06-08. net-irc/ninja signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-perl/Net-Twitter
# Sam James (2024-05-06) # Long-deprecated upstream, replaced by (unpackaged) Twitter::API. # Twitter's API has changed at least once since the last release of Net::Twitter. # Removal on 2024-06-05. Bug #931295. dev-perl/Net-Twitter signature.asc Description: PGP signature
[gentoo-dev] Last rites: media-libs/lastfmlib
# Sam James (2024-05-06) # Incompatible with latest last.fm APIs, hence useless. # Removal on 2024-06-05. Bug #928115. media-libs/lastfmlib signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2] 2024-05-03-wireplumber-0_5-bump: add news item
James Calligeros writes: > Signed-off-by: James Calligeros > --- > .../2024-05-03-wireplumber-0_5-bump.en.txt| 25 +++ > 1 file changed, 25 insertions(+) > create mode 100644 > 2024-05-03-wireplumber-0_5-bump/2024-05-03-wireplumber-0_5-bump.en.txt > > diff --git > a/2024-05-03-wireplumber-0_5-bump/2024-05-03-wireplumber-0_5-bump.en.txt > b/2024-05-03-wireplumber-0_5-bump/2024-05-03-wireplumber-0_5-bump.en.txt > new file mode 100644 > index 000..22f2314 > --- /dev/null > +++ b/2024-05-03-wireplumber-0_5-bump/2024-05-03-wireplumber-0_5-bump.en.txt > @@ -0,0 +1,25 @@ > +Title: media-video/wireplumber-0.5.2 may break on upgrade > +Author: James Calligeros > +Posted: 2024-05-03 > +Revision: 1 > +News-Item-Format: 2.0 > +Display-If-Installed: media-video/wireplumber > + > +As some will be aware, WirePlumber 0.5.0 introduced a significant > +breaking change to its entire configuration system, eliminating the use > +of Lua scripts for configuration purposes. This also came with a > +complete rework of how Lua scripts are registered with WirePlumber > +for execution. > + > +Most typical desktop users, including EasyEffects users, should not > +notice any change to their system. That said, it was not uncommon for > +people to suggest or implement configuration changes using the Lua API. > + > +Any custom functionality which relies on WirePlumber's Lua API will > +break upon upgrade. > + > +If you rely on this functionality, please review the WirePlumber > +documentation on porting your Lua scripts to the new API and > +registering them with the system before upgrading: > + > +https://pipewire.pages.freedesktop.org/wireplumber/daemon/configuration/migration.html LGTM. Let's give it the standard 48 hours then let's ship it. If you feel it'd be useful to commit pw+wp masked before then, we can, but my gut is that it isn't. Thanks again for working on this. best, sam
Re: [gentoo-dev] [PATCH 1/2] gnuconfig.eclass: add GNUCONFIG_DEPEND
Arsen Arsenović writes: > Sam James writes: > >> The motivation here is to allow autotools.eclass consumers setting >> AUTOTOOLS_AUTO_DEPEND=no to not have a useless gnuconfig dependency. > > series looks ok to me thanks!
Re: [gentoo-dev] [PATCH 1/2] gnuconfig.eclass: add GNUCONFIG_DEPEND
Ulrich Mueller writes:
>>>>>> On Fri, 03 May 2024, Sam James wrote:
>
>> +case ${EAPI} in
>> +5|6) DEPEND=${GNUCONFIG_DEPEND} ;;
>> +*) BDEPEND=${GNUCONFIG_DEPEND} ;;
>> +esac
>
> Drop EAPI 5 while at it?
Good point, done & pushed, thanks.
[gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: drop EAPI 5 support
autotools.eclass hasn't had EAPI 5 support for ~2 years since
50710f3d0e8f19fab5571d9596c336314e96b5cf so this wasn't being used
anyway (non-autotools.eclass use of gnuconfig.eclass is very niche).
Signed-off-by: Sam James
---
eclass/gnuconfig.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/gnuconfig.eclass b/eclass/gnuconfig.eclass
index df3c748676082..fb73087aeacf4 100644
--- a/eclass/gnuconfig.eclass
+++ b/eclass/gnuconfig.eclass
@@ -6,7 +6,7 @@
# Sam James
# @AUTHOR:
# Will Woods
-# @SUPPORTED_EAPIS: 5 6 7 8
+# @SUPPORTED_EAPIS: 6 7 8
# @BLURB: Refresh bundled gnuconfig files (config.guess, config.sub)
# @DESCRIPTION:
# This eclass is used to automatically update files that typically come with
@@ -17,7 +17,7 @@
#
case ${EAPI:-0} in
- 5|6|7|8) ;;
+ 6|7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -39,7 +39,7 @@ GNUCONFIG_DEPEND="sys-devel/gnuconfig"
: "${GNUCONFIG_AUTO_DEPEND:=yes}"
if [[ ${GNUCONFIG_AUTO_DEPEND} != "no" ]] ; then
case ${EAPI} in
- 5|6) DEPEND=${GNUCONFIG_DEPEND} ;;
+ 6) DEPEND=${GNUCONFIG_DEPEND} ;;
*) BDEPEND=${GNUCONFIG_DEPEND} ;;
esac
fi
@@ -122,7 +122,7 @@ gnuconfig_findnewest() {
local prefix
case ${EAPI} in
- 5|6)
+ 6)
prefix="${EPREFIX}"
;;
*)
--
2.45.0
[gentoo-dev] [PATCH v2 2/3] autotools.eclass: conditionalize gnuconfig dependency
Use newly-added GNUCONFIG_DEPEND so that AUTOTOOLS_AUTO_DEPEND=no doesn't
result in a useless dependency on gnuconfig.
Signed-off-by: Sam James
---
eclass/autotools.eclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 1ced771c5345f..a456e9b9f5898 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -33,6 +33,7 @@ _AUTOTOOLS_ECLASS=1
[[ ${EAPI} == 6 ]] && inherit eqawarn
+GNUCONFIG_AUTO_DEPEND=no
inherit gnuconfig libtool
# @ECLASS_VARIABLE: WANT_AUTOCONF
@@ -164,9 +165,12 @@ fi
# @DESCRIPTION:
# Contains the combination of requested automake/autoconf/libtool
# versions in *DEPEND format.
-AUTOTOOLS_DEPEND="${_automake_atom}
+AUTOTOOLS_DEPEND="
+ ${GNUCONFIG_DEPEND}
+ ${_automake_atom}
${_autoconf_atom}
- ${_libtool_atom}"
+ ${_libtool_atom}
+"
RDEPEND=""
# @ECLASS_VARIABLE: AUTOTOOLS_AUTO_DEPEND
--
2.45.0
[gentoo-dev] [PATCH v2 1/3] gnuconfig.eclass: add GNUCONFIG_DEPEND
The motivation here is to allow autotools.eclass consumers setting
AUTOTOOLS_AUTO_DEPEND=no to not have a useless gnuconfig dependency.
Signed-off-by: Sam James
---
eclass/gnuconfig.eclass | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/eclass/gnuconfig.eclass b/eclass/gnuconfig.eclass
index 0791798632cdb..df3c748676082 100644
--- a/eclass/gnuconfig.eclass
+++ b/eclass/gnuconfig.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: gnuconfig.eclass
@@ -24,9 +24,25 @@ esac
if [[ -z ${_GNUCONFIG_ECLASS} ]] ; then
_GNUCONFIG_CLASS=1
-BDEPEND="sys-devel/gnuconfig"
+# @ECLASS_VARIABLE: GNUCONFIG_DEPEND
+# @OUTPUT_VARIABLE
+# @DESCRIPTION:
+# Contains dependency on gnuconfig in *DEPEND format.
+GNUCONFIG_DEPEND="sys-devel/gnuconfig"
-[[ ${EAPI} == [56] ]] && DEPEND="${BDEPEND}"
+# @ECLASS_VARIABLE: GNUCONFIG_AUTO_DEPEND
+# @PRE_INHERIT
+# @DESCRIPTION:
+# Set to 'no' to disable automatically adding to DEPEND. This lets
+# ebuilds form conditional depends by using ${GNUCONFIG_DEPEND} in
+# their own DEPEND string.
+: "${GNUCONFIG_AUTO_DEPEND:=yes}"
+if [[ ${GNUCONFIG_AUTO_DEPEND} != "no" ]] ; then
+ case ${EAPI} in
+ 5|6) DEPEND=${GNUCONFIG_DEPEND} ;;
+ *) BDEPEND=${GNUCONFIG_DEPEND} ;;
+ esac
+fi
# @FUNCTION: gnuconfig_update
# @USAGE: [file1 file2 ...]
--
2.45.0
[gentoo-dev] [PATCH 2/2] autotools.eclass: conditionalize gnuconfig dependency
Use newly-added GNUCONFIG_DEPEND so that AUTOTOOLS_AUTO_DEPEND=no doesn't
result in a useless dependency on gnuconfig.
Signed-off-by: Sam James
---
eclass/autotools.eclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 1ced771c5345f..a456e9b9f5898 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -33,6 +33,7 @@ _AUTOTOOLS_ECLASS=1
[[ ${EAPI} == 6 ]] && inherit eqawarn
+GNUCONFIG_AUTO_DEPEND=no
inherit gnuconfig libtool
# @ECLASS_VARIABLE: WANT_AUTOCONF
@@ -164,9 +165,12 @@ fi
# @DESCRIPTION:
# Contains the combination of requested automake/autoconf/libtool
# versions in *DEPEND format.
-AUTOTOOLS_DEPEND="${_automake_atom}
+AUTOTOOLS_DEPEND="
+ ${GNUCONFIG_DEPEND}
+ ${_automake_atom}
${_autoconf_atom}
- ${_libtool_atom}"
+ ${_libtool_atom}
+"
RDEPEND=""
# @ECLASS_VARIABLE: AUTOTOOLS_AUTO_DEPEND
--
2.45.0
[gentoo-dev] [PATCH 1/2] gnuconfig.eclass: add GNUCONFIG_DEPEND
The motivation here is to allow autotools.eclass consumers setting
AUTOTOOLS_AUTO_DEPEND=no to not have a useless gnuconfig dependency.
Signed-off-by: Sam James
---
eclass/gnuconfig.eclass | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/eclass/gnuconfig.eclass b/eclass/gnuconfig.eclass
index 0791798632cdb..df3c748676082 100644
--- a/eclass/gnuconfig.eclass
+++ b/eclass/gnuconfig.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: gnuconfig.eclass
@@ -24,9 +24,25 @@ esac
if [[ -z ${_GNUCONFIG_ECLASS} ]] ; then
_GNUCONFIG_CLASS=1
-BDEPEND="sys-devel/gnuconfig"
+# @ECLASS_VARIABLE: GNUCONFIG_DEPEND
+# @OUTPUT_VARIABLE
+# @DESCRIPTION:
+# Contains dependency on gnuconfig in *DEPEND format.
+GNUCONFIG_DEPEND="sys-devel/gnuconfig"
-[[ ${EAPI} == [56] ]] && DEPEND="${BDEPEND}"
+# @ECLASS_VARIABLE: GNUCONFIG_AUTO_DEPEND
+# @PRE_INHERIT
+# @DESCRIPTION:
+# Set to 'no' to disable automatically adding to DEPEND. This lets
+# ebuilds form conditional depends by using ${GNUCONFIG_DEPEND} in
+# their own DEPEND string.
+: "${GNUCONFIG_AUTO_DEPEND:=yes}"
+if [[ ${GNUCONFIG_AUTO_DEPEND} != "no" ]] ; then
+ case ${EAPI} in
+ 5|6) DEPEND=${GNUCONFIG_DEPEND} ;;
+ *) BDEPEND=${GNUCONFIG_DEPEND} ;;
+ esac
+fi
# @FUNCTION: gnuconfig_update
# @USAGE: [file1 file2 ...]
--
2.45.0
Re: [gentoo-dev] [PATCH] .github: Add pull request template
Ionen Wolkens writes: > On Wed, May 01, 2024 at 03:32:21PM +0200, Michał Górny wrote: >> The idea is to increase awareness of the AI policy, as well as other >> rules, and to inform users before they submit a PR. > > Bit mixed feelings about this given checkboxes feel like unnecessary > churn for routine contributors and is semi-redundant with the > Signed-off-by. > > I think it's great for first-time/occasional contributors though. > > Having a AI-specific checkbox does feel kind of overkill when it won't > concern the majority of contributors, albeit given how how hard the whole > thing is pushed lately and that we have no real way to verify beside the > user being made aware of it and certifying it... > > On a side-note, I have nothing against having .github in the tree. Just > saying given I know not everyone is happy with that. Indeed, the only line for me is if we were solely relying on it, e.g. if we replaced all self-hosted CI with github actions CI or similar. I don't see supplementary files for services we make use of, but don't depend on, as a problem, as long as they're not some minor experiment.
Re: [gentoo-dev] [PATCH] .github: Add pull request template
Michał Górny writes: > Signed-off-by: Michał Górny > --- > .github/pull_request_template.md | 12 > 1 file changed, 12 insertions(+) > create mode 100644 .github/pull_request_template.md > > The idea is to increase awareness of the AI policy, as well as other > rules, and to inform users before they submit a PR. > > Screenshots @ https://github.com/gentoo/gentoo/pull/36503 > > > diff --git a/.github/pull_request_template.md > b/.github/pull_request_template.md > new file mode 100644 > index ..9e6fe061db11 > --- /dev/null > +++ b/.github/pull_request_template.md > @@ -0,0 +1,12 @@ > + > + > +--- > + > +Please check all the boxes that apply: > + > +- [ ] I can submit this contribution in agreement with the [Copyright > Policy](https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin). > +- [ ] This contribution has not been created with the assistance of > Natural Language Processing artificial intelligence tools, in > accordance with [AI > policy](https://wiki.gentoo.org/wiki/Project:Council/AI_policy). > +- [ ] I have certified the above via adding a `Signed-off-by` line to > *every* commit in the pull request. > +- [ ] I have run `pkgcheck scan --commits --net` to check for issues with my > commits. > + > +Please note that all boxes must be checked for the pull request to be merged. I'm OK with the proposal as-is, but would be interested in hearing suggestions to alleviate ulm's concern of developers feeling they must tick every single box as well. But that might not be doable. xgqt's comments wrt testing are interesting but maybe better with us linking to a checklist instead, rather than something users have to declare in the github PR. Not sure. Anyway, thanks for this, I've wanted this for a while anyway as it's more elegant than the Larry bot method. Glad you came around ;) thanks, sam
Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
Eli Schwartz writes: > On 5/1/24 10:10 AM, Martin Dummer wrote: >> Since Agostino's tinderbox tests now report qa warning, the group >> v...@gentoo.org has 101 open bugs assigned, most of them caused by qa >> warnings from vdr-plugin-2.eclass. >> >> Many vdr plugins need small adjustments because API or makefile changes >> in upstream media-video/vdr which can be easily fixed with small changes. >> >> These warnings are only useful for the vdr plugin maintainers, so I >> propose they should (only) be reported as QA-warnings when the global >> variable >> VDR_MAINTAINER_MODE="1" >> is set in make.conf >> >> This patch is also put to github in >> https://github.com/gentoo/gentoo/pull/36504 >> >> The PR is lacking many many "Closes: " tags, which I will fill in soon. >> >> Any comments? > > > What does "only useful for the vdr plugin maintainers" mean? Why can't > anyone fix them? > > There are lots of QA warnings that a package can generate, and lots of > them are "only" relevant to someone editing the upstream source code. > Why should vdr plugins be special? > > From a quick glance at the warning messages, my inexpert feeling is that > two of them are a bit "wishy-washy" and could be classified as "a > warning to be picky and do best practices": > > - gettext handling > - old Makefile handling > > The others seem like worrisome issues that should very much be reported > in tinderboxes and get fixed. What we really need is: a) https://bugs.gentoo.org/162450 to avoid scaring users; b) possibly some level of QA notice to distinguish between "check this out" (think e.g. qa-vdb LHS where it _might_ be unused, but not necessarily), and "this is definitely wrong" I am convinced we need a), I am not-at-all convinced we need b) - at least not in terms of whether bugs are reported. > > Automatically sed'ing out source code, especially for the one that says > "please recheck", very much looks like the purpose of the qa warning is > that the functionality isn't trusted to be correct, is offered on a > best-effort basis, and needs to be manually reviewed and marked as okay > (by applying as a real patch) in order to squelch the warnings. > > In other words, there are "QA issues" and "QA nitpicks".
Re: [gentoo-dev] time64 ABI fix coming to upstream glibc
Florian Weimer writes: > The and headers had a bug that the on-disk structures > defined there could change size on some targets when _TIME_BITS was set > to 64. This is obviously wrong because the files are not going to > magically change their layout because the application accessing them was > built in a specific way. We're going to fix this in glibc upstream on > the stable release branches, going all the way back to glibc 3.34 (the > first release with this kind of time64 support). After the fix, the > _TIME_BITS definition will no longer impact struct layout. Usually, > that means epoch fields are 32-bits wide, to match co-installable > architectures. > > To extend the usable life-time of these interfaces somewhat, glibc 2.40 > changes epoch fields to unsigned types in these structures. This change > is specific to the upcoming glibc 2.40 release, I do not plan to > backport it. Thank you for the heads-up Florian. We haven't yet started our time64 migration - the plan is to start playing with it over the next few months, so the timing has worked out well for us. We'll make sure the fixes are pulled in before we solidify anything beyond experiments. I'm trying not to wait *too* late to start, just in case we do end up finding any other problems like this, rather than finding them years down the line when it's too late to fix anything. > > Thanks, > Florian thanks, sam
Re: [gentoo-dev] Re: [PATCH 2/3] To build ada we need a c++ compiler too
Alfredo Tupone writes:
> On Fri, 26 Apr 2024 10:29:43 +0200
> Arsen Arsenović wrote:
>
>> > is_ada() {
>> >gcc-lang-supported ada || return 1
>> > - _tc_use_if_iuse ada
>> > + _tc_use_if_iuse cxx && _tc_use_if_iuse ada
>>
>> Is this redundant? Would gcc-lang-supported c++ (called through the
>> ada support check) not suffice?
>
> From what I understand this test is checking that both USE=cxx and
> USE=ada are enabled, and both cxx and ada are supported by gcc.
>
> If not, gcc is built without the ada compiler
It's fine with me if you commit these, just please add detail to the
commit messages first. Thanks.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Subject: [PATCH] toolchain.eclass: ada related changes
Alfredo Tupone writes:
> Having received no comments, I would like to add this changes to
> toolchain.eclass
>
> This is less intrusive.
>
> The compiler check that was in place in the original email maybe is
> distruptive. It was checking that the used compiler is ada and version
> is less or equal.
>
> I saw that some gcc versions can be build with a newer compiler. IIRC
> gcc-13 can build gcc-12 but gcc-11 cannot be built with gcc-12
>
>
I don't really get the point in this change, though, if it's purely
the diff quoted below. I don't see a commit message either.
Please send another version with `git-send-email` with a full commit
message to explain what you're doing here and why?
(added missing toolchain@ CC too)
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index a5d4345e7fbf..23c57353d702 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -288,38 +288,38 @@ if [[ ${PN} != kgcc64 && ${PN} != gcc-* ]] ; then
> IUSE+=" objc-gc" TC_FEATURES+=( objc-gc )
> IUSE+=" libssp objc++"
>
> # Stop forcing openmp on by default in the eclass. Gradually phase it
> out.
> # See bug #890999.
> if tc_version_is_at_least 13.0.0_pre20221218 ; then
> IUSE+=" openmp"
> else
> IUSE+=" +openmp"
> fi
>
> IUSE+=" fixed-point"
> IUSE+=" go"
> IUSE+=" +sanitize" TC_FEATURES+=( sanitize )
> IUSE+=" graphite" TC_FEATURES+=( graphite )
> - IUSE+=" ada"
> IUSE+=" vtv"
> IUSE+=" jit"
> IUSE+=" +pie +ssp pch"
>
> IUSE+=" systemtap" TC_FEATURES+=( systemtap )
>
> tc_version_is_at_least 9.0 && IUSE+=" d" TC_FEATURES+=( d )
> + tc_version_is_at_least 9.0 && IUSE+=" ada" TC_FEATURES+=( ada )
> tc_version_is_at_least 9.1 && IUSE+=" lto"
> tc_version_is_at_least 10 && IUSE+=" cet"
> tc_version_is_at_least 10 && IUSE+=" zstd" TC_FEATURES+=( zstd )
> tc_version_is_at_least 11 && IUSE+=" valgrind" TC_FEATURES+=( valgrind )
> tc_version_is_at_least 11 && IUSE+=" custom-cflags"
> tc_version_is_at_least 12 && IUSE+=" ieee-long-double"
> tc_version_is_at_least 12.2.1_p20221203 ${PV} && IUSE+=" default-znow"
> tc_version_is_at_least 12.2.1_p20221203 ${PV} && IUSE+="
> default-stack-clash-protection"
> tc_version_is_at_least 13.0.0_pre20221218 ${PV} && IUSE+=" modula2"
> # See https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615944.html
> # and
> https://rust-gcc.github.io/2023/04/24/gccrs-and-gcc13-release.html for why
> # it was disabled in 13.
> tc_version_is_at_least 14.0.0_pre20230423 ${PV} && IUSE+=" rust"
> fi
>
> @@ -2495,31 +2495,31 @@ should_we_gcc_config() {
> #
> # Also add a hook so special ebuilds (kgcc64) can control which languages
> # exactly get enabled
> gcc-lang-supported() {
> grep ^language=\"${1}\" "${S}"/gcc/*/config-lang.in > /dev/null ||
> return 1
> [[ -z ${TOOLCHAIN_ALLOWED_LANGS} ]] && return 0
> has $1 ${TOOLCHAIN_ALLOWED_LANGS}
> }
>
> _tc_use_if_iuse() {
> in_iuse $1 && use $1
> }
>
> is_ada() {
> gcc-lang-supported ada || return 1
> - _tc_use_if_iuse ada
> + _tc_use_if_iuse cxx && _tc_use_if_iuse ada
> }
>
> is_cxx() {
> gcc-lang-supported 'c++' || return 1
> _tc_use_if_iuse cxx
> }
>
> is_d() {
> gcc-lang-supported d || return 1
> _tc_use_if_iuse d
> }
>
> is_f77() {
> gcc-lang-supported f77 || return 1
> _tc_use_if_iuse fortran
[gentoo-dev] Up for grabs: Raspberry Pi stack
I don't have the hardware set up at the moment (and haven't for a while) to test this properly. The following packages are up for grabs: * media-libs/raspberrypi-userland-bin * sys-kernel/raspberrypi-image I dropped myself as a co-maintainer on the following: * sys-firmware/raspberrypi-wifi-ucode * media-libs/raspberrypi-userland-bin * sys-boot/raspberrypi-firmware * sys-kernel/raspberrypi-sources * sys-kernel/raspberrypi-image I think anyone interested in these packages should probably consider joining the lot. There's a few outstanding bugs, notably https://bugs.gentoo.org/930269 for Raspberry Pi 5 support, but a bunch of others including bumps being due. thanks, sam
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Eddie Chapman writes: > On 04/04/2024 15:24, Eddie Chapman wrote: >> Since there appears to be some interest I'll put together a single email >> to the list later today detailing everything, as I needed to do more >> things overall in addition to replacing /usr/bin/xz. > > Below is a guide I've written to removing app-arch/xz-utils in case > anyone else wants to do so. Attached is the current version of the > Bash wrapper script I now use in place of /usr/bin/xz > > Comments, corrections on anything technical in the guide or script are > welcome, apart from flames about how this is ridiculous and > unnecessary :-). For an experiment I'm doing (distinct from trying to purge xz-utils, just verification work), I've packaged the following: * app-arch/gxz (pure Go impl.) * app-arch/7zip (7zip upstream are supporting Linux now, app-arch/p7zip was an unofficial port) You might find those useful too. At a glance, it appears https://github.com/fpgaminer/rust-lzma and https://github.com/gendx/lzma-rs don't provide executables - just a library - so I didn't bother looking further. > > Best wishes, > Eddie > > > Guide to removing xz utils on a Gentoo system > > [...] > There is one significant thing that breaks, which is Gemato > (app-portage/gemato). Gemato requires lzma support in core python in > order to do GPG signature verification. This means you will have to > say goodbye (for now) to verifying upstream GPG signatures on > distfiles, and verification of Portage metadata after doing an emerge > --sync. These features have been added to Portage relatively recently > (2022?) so are "nice to have", without them your system is just less No.. much older. It was introduced around the time of the github mirror being hacked. It's not just theatre! Like, this is very much NOT hypothetical. It's not just about metadata, it's about the ebuilds if using rsync, or the whole git checkout if using git. > hardened, but still with the very high level of security that Gentoo > systems have has always had prior to these features, in my > opinion. Personally I can live without them for now. Verifying hashes > in Manifest files still works fine and that's the main thing. You may > disagree in which case, well, don't do this then. I'm going to figure > out an alternative way I can verify Portage metadata soon, as there > are other ways if you are creative. See grobian's reply which should help. > [...] > - Portage binary packages: You cannot use xz compression if you create > Portage binary packages. You will need to use one of bzip2, gzip, > lz4, lzip, lzop, or zstd in BINPKG_COMPRESS in make.conf instead of > xz (if that is what you were using, or is it the default?). I have zstd is the default for "new" installs (since a few years ago), yeah. > [...] > - sys-apps/fwupd might stop working properly (though it will still > build fine) due to what you have to change with dev-libs/libxmlb > below. I'm not sure as I haven't checked yet, I just suspect it > will. So bear that in mind if you need to rely on sys-apps/fwupd at > the moment. But this "might" is temporary, upstream has now decided > to make lzma optional, so this will trickle down to Gentoo soon. Just for completeness, this is https://blogs.gnome.org/hughsie/2024/04/03/fwupd-and-xz-metadata/. > [...]
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Eli Schwartz writes: > On 4/3/24 11:30 AM, Eddie Chapman wrote: >> Just to report I've been able to remove app-arch/xz-utils from my own >> workstation, with 2412 packages installed and running kde. I'm going to >> roll it out to my other gentoo systems which have a lot less stuff on them >> so am confident will be fine. It's not completely trivial but not as >> difficult as I imagined it to be, certainly something an advance Gentoo >> user could do if they wanted, with instructions. It does involve a >> relatively small hack and functionality previously provided by xz-utils is >> replaced by app-arch/p7zip. > > > I'd just like to clarify my previous posts: what you're describing here > is neat and productive and valid to my eyes. Actually, I wish this had > been the topic of the *first* post in this thread. :) Completely agreed. We just prefer shorter text and focusing on technical changes. This sounds fun! > [...] thanks, sam
Re: [gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo
Duncan <1i5t5.dun...@cox.net> writes: > Eddie Chapman posted on Tue, 2 Apr 2024 20:32:41 +0100 as excerpted: > >> Yes, I have no issue with the format at all, just with the xz utils >> project. > > FWIW, feel free to do that bug-fix or package-bump if you'd rather instead > of reading this long thing! I won't complain! =:^) Something's wrong - we're agreeing ;) You're spot on. Tangible real changes and efforts are useful, not "please boil the ocean". > [...] thanks, sam
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
"Eddie Chapman" writes: > Given what we've learnt in the last 24hrs about xz utilities, you could > forgive a paranoid person for seriously considering getting rid entirely > of them from their systems, especially since there are suitable > alternatives available. Some might say that's a bit extreme, xz-utils > will get a thorough audit and it will all be fine. But when a malicious > actor has been a key maintainer of something as complex as a decompression > utility for years, I'm not sure I could ever trust that codebase again. > Maybe a complete rewrite will emerge, but I'm personally unwilling to > continue using xz utils in the meantime for uncompressing anything on my > systems, even if it is done by an unprivileged process. My own view is that there'll be a time for introspection, reflection, and discussion of changes once the crisis is over. We're not there yet. But I don't think us fetching several variants of compression formats and testing & verifying all of them is feasible. I also think it's (and I don't mean this derogatorily towards you) naive for people in general to suggest that this is really specific to xz at all. Unfortunately, there's many. many projects this could've happened to. > > I see that many system package ebuilds unconditionally expect > app-arch/xz-utils to be installed simply to be able to decompress the > source archive in SRC_URI. So simply specifying -lzma on your system isn't > going to get rid of it. > > No one could have been expected to foresee what's happened with xz-utils, > but now that it's here, perhaps Gentoo (and other projects that do) should > consider not relying on a single decompression algorithm for source > archives, even just as an insurance against some other yet unknown > disaster with one algorithm or another in future? I think there's real discussions to be had about relying on dist tarballs and such but I don't really see how we could try to avoid compression algorithms. > > And yes I'm sure there will be individual packages that currently > absolutely need xz-utils installed during the build process, and one or > two that absolutely have to have it available at runtime, but those > bridges can be crossed as and when. > > Eddie thanks, sam
Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: simplify implementation and work in all cases
Eli Schwartz writes:
> It curently uses some magic test to decide whether handcrafted code
> works with or without -latomic. But it can claim that -latomic is not
> needed for that case, while it is still needed for other cases.
>
>> okay so append-atomic-flags does not work for me in this case
>> noise-suppression-for-voice is doing `struct RnNoiseStats { uint32_t a, b,
>> c, d; }; std::atomic m_stats;`
>> not just a single large integer
>
> It is simplest to always add -latomic when an ebuild gets that deep
> feeling that yeah, it would like some atomics please. The downsides to
> listing a linker library are exactly:
>
> - it might be unavailable
> - it might be unneeded
>
> And the former case is trivial to solve -- this function already does so
> -- while the latter case has a sanctioned approach that is already used
> for other intrinsic compiler libraries, but not for atomic "because the
> build system would have a hard time if we had to build atomic early on"
> which isn't a very good reason to break ebuilds which aren't building
> sys-devel/gcc.
>
> As a side benefit, we now handle -latomic such that a package which
> requires it, but only for parts of the installed package, does not
> overlink to libatomic in *all* binaries/libraries, even if the default
> LDFLAGS are overridden and the global -Wl,--as-needed disappears.
>
> Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
> Bug: https://bugs.gentoo.org/820101
> Bug: https://bugs.gentoo.org/925672
> Signed-off-by: Eli Schwartz
LGTM. Thanks.
> ---
> eclass/flag-o-matic.eclass | 80 +-
> 1 file changed, 19 insertions(+), 61 deletions(-)
>
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index 5ce7601fdde2..0e5271c7824f 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -1015,69 +1015,27 @@ test-compile() {
> }
>
> # @FUNCTION: append-atomic-flags
> -# @USAGE: [bytes]
> # @DESCRIPTION:
> -# Attempts to detect if appending -latomic is required to use
> -# a specific-sized atomic intrinsic, and if so, appends it. If the bytesize
> -# is not specified, then check the four most common byte sizes (1, 2, 4, 8).
> -# >=16-byte atomics are not included in this default set and must be
> explicitly
> -# passed if required. This may require you to add a macro definition like
> -# -Duint128_t=__uint128_t to your CFLAGS.
> +# Attempts to detect if appending -latomic works, and does so.
> append-atomic-flags() {
> - # this implementation is as described in bug #820101
> - local code
> -
> - # first, ensure we can compile a trivial program
> - # this is because we can't distinguish if test-compile
> - # fails because -latomic is actually needed or if we have a
> - # broken toolchain (like due to bad FLAGS)
> - read -r -d '' code <<- EOF
> - int main(void)
> - {
> - return 0;
> - }
> - EOF
> -
> - # if toolchain is broken, just return silently. it's better to
> - # let other pieces of the build fail later down the line than to
> - # make people think that something to do with atomic support is the
> - # cause of their problems.
> - test-compile "c+ld" "${code}" || return
> -
> - local bytesizes
> - [[ "${#}" == "0" ]] && bytesizes=( "1" "2" "4" "8" ) || bytesizes="${@}"
> -
> - for bytesize in ${bytesizes[@]}
> - do
> - # this sample program is informed by the great testing from the
> buildroot project:
> - #
> https://github.com/buildroot/buildroot/commit/6856e417da4f3aa77e2a814db2a89429af072f7d
> - read -r -d '' code <<- EOF
> - #include
> - int main(void)
> - {
> - uint$((${bytesize} * 8))_t a = 0;
> - __atomic_add_fetch(, 3, __ATOMIC_RELAXED);
> - __atomic_compare_exchange_n(, , 2, 1,
> __ATOMIC_RELAXED, __ATOMIC_RELAXED);
> - return 0;
> - }
> - EOF
> -
> - # do nothing if test program links fine
> - test-compile "c+ld" "${code}" && continue
> -
> - # ensure that the toolchain supports -latomic
> - test-flags-CCLD "-latomic" &>/dev/null || die "-latomic is
> required but not supported by $(tc-getCC)"
> -
> - append-libs "-latomic"
> -
> - # verify that this did indeed fix the problem
> - test-compile "c+ld" "${code}" || \
> - die "libatomic does not include an implementation of
> ${bytesize}-byte atomics for this toolchain"
> -
> - # if any of the required bytesizes require -latomic, no need to
> continue
> - # checking the others
> - return
> - done
> + # Make sure that the flag is actually valid. If it isn't, then maybe the
> + #
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: make the FHS paths warning easier to read
Eli Schwartz writes:
> * QA Notice: The ebuild is installing to one or more unexpected paths:
> *
> * /var/tmp/portage/sys-cluster/legion-/image/usr/bin/legion_prof_files
> *
> /var/tmp/portage/sys-cluster/legion-/image/usr/bin/serializer_examples
> *
> * Please fix the ebuild to use correct FHS/Gentoo policy paths.
>
> This message is hard to understand. Is it saying that the resulting
> package contains files prefixed with ${D} which would be immensely
> broken? Is it saying that these paths are *directories* and the FHS does
> not approve of directories in /usr/bin/*/?
>
> In fact, it's the latter. Fix this in two ways:
>
> - clarify that it's an unexpected directory, not just some kind of path
>
> - strip ${D} so that people can better visualize what sort of path gets
> installed. This has the downside of not being able to copy/paste the
> path in order to inspect the image directory, but I think this is a
> very small downside. Usually by the time you see this message, portage
> has cleaned up. And if it hasn't, you can still copy/paste that from:
>
> Completed installing sys-cluster/legion- into
> /var/tmp/portage/sys-cluster/legion-/image
>
> Signed-off-by: Eli Schwartz
> ---
LGTM. Thanks.
> metadata/install-qa-check.d/08gentoo-paths | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/metadata/install-qa-check.d/08gentoo-paths
> b/metadata/install-qa-check.d/08gentoo-paths
> index 5b8607fd5f96..0b92a7a1c132 100644
> --- a/metadata/install-qa-check.d/08gentoo-paths
> +++ b/metadata/install-qa-check.d/08gentoo-paths
> @@ -70,9 +70,9 @@ gentoo_path_check() {
> # report
> # --
> if [[ -n ${bad_paths[@]} ]]; then
> - eqawarn "QA Notice: The ebuild is installing to one or more
> unexpected paths:"
> + eqawarn "QA Notice: The ebuild is installing to one or more
> unexpected directories:"
> eqawarn
> - eqatag -v non-gentoo-paths "${bad_paths[@]}"
> + eqatag -v non-gentoo-paths "${bad_paths[@]#${D%/}}"
> eqawarn
> eqawarn "Please fix the ebuild to use correct FHS/Gentoo policy
> paths."
> fi
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: sci-libs/xgks-pmel
# Eli Schwartz (2024-03-24) # Broken with modern compilers, broken with LTO. Upstream website no # longer exists. Unmaintained in Gentoo, no reverse dependencies. # Removal on 2024-04-23. Bug #731942, #863041, #898298. sci-libs/xgks-pmel signature.asc Description: PGP signature
Re: [gentoo-dev] Profile 23.0 testing with stages and binhost (part 2 of 2)
"Andreas K. Huettel" writes: > Hi all, > > the 23.0 profiles are ready for testing, including stage downloads, > binary packages, and update instructions for existing installations, > for all arches. > > [...] > > Note 2: While there are 23.0 split-usr profiles, the *stage* downloads > are *all* of the merged-usr type. Why? Not because I'm a big fan of that, > but because we should try to unify and standardize a bit again - to > avoid too many different build configurations leading to too many Heisenbugs. I don't think this is a good idea. We've promised people that they can keep unmerged-usr if they want, but not having stages means new installs aren't doable, and it also makes testing a pain because you can't easily unmerge. You can easily merge, but you can't easily unmerge. What you can do is provide a limited number of non-merged-usr variants given it's just about saving people rebuilds. (I also think it's the wrong way to do such a change anyway - the releng part should be last after decision-making, not first.) > [...] > Cheers & have fun, thanks, sam signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/future
# Eli Schwartz (2024-03-14) # Deprecated, doesn't work with python 3.12. Unmaintained with last # serious release in 2019, and another release in 2024 that claims # to support python 3.12 but fails tests if you actually do. No # route to making it work with python 3.13 at all, and upstream # explicitly states that future "like Python 2, is now done". The # package is entirely redundant to packages not supporting python # 2 anymore, and the ones that do support it should be using # dev-python/six instead, anyways. Bug #888271 # Removal on 2024-04-13. dev-python/future signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
Matt Jolly writes: >> But where do we draw the line? Are translation tools like DeepL >> allowed? I don't see much of a copyright issue for these. > > I'd also like to jump in and play devil's advocate. There's a fair > chance that this is because I just got back from a > supercomputing/research conf where LLMs were the hot topic in every keynote. > > As mentioned by Sam, this RFC is performative. Any users that are going > to abuse LLMs are going to do it _anyway_, regardless of the rules. We > already rely on common sense to filter these out; we're always going to > have BS/Spam PRs and bugs - I don't really think that the content being > generated by LLM is really any worse. > > This doesn't mean that I think we should blanket allow poor quality LLM > contributions. It's especially important that we take into account the > potential for bias, factual errors, and outright plagarism when these > tools are used incorrectly. We already have methods for weeding out low > quality contributions and bad faith contributors - let's trust in these > and see what we can do to strengthen these tools and processes. > > A bit closer to home for me, what about using a LLMs as an assistive > technology / to reduce boilerplate? I'm recovering from RSI - I don't > know when (if...) I'll be able to type like I used to again. If a model > is able to infer some mostly salvagable boilerplate from its context > window I'm going to use it and spend the effort I would writing that to > fix something else; an outright ban on LLM use will reduce my _ability_ > to contribute to the project. Another person approached me after this RFC and asked whether tooling restricted to the current repo would be okay. For me, that'd be mostly acceptable, given it won't make suggestions based on copyrighted code. I also don't have a problem with LLMs being used to help refine commit messages as long as someone is being sensible about it (e.g. if, as in your situation, you know what you want to say but you can't type much). I don't know how to phrase a policy off the top of my head which allows those two things but not the rest. > > What about using a LLM for code documentation? Some models can do a > passable job of writing decent quality function documentation and, in > production, I _have_ caught real issues in my logic this way. Why should > I type that out (and write what I think the code does rather than what > it actually does) if an LLM can get 'close enough' and I only need to do > light editing? I suppose in that sense, it's the same as blindly listening to any linting tool or warning without understanding what it's flagging and if it's correct. > [...] > As a final not-so-hypothetical, what about a LLM trained on Gentoo docs > and repos, or more likely trained on exclusively open-source > contributions and fine-tuned on Gentoo specifics? I'm in the process of > spinning up several models at work to get a handle on the tech / turn > more electricity into heat - this is a real possibility (if I can ever > find the time). I think that'd be interesting. It also does a good job as a rhetorical point wrt the policy being a bit too blanket here. See https://www.softwareheritage.org/2023/10/19/swh-statement-on-llm-for-code/ too. > > The cat is out of the bag when it comes to LLMs. In my real-world job I > talk to scientists and engineers using these things (for their > strengths) to quickly iterate on designs, to summarise experimental > results, and even to generate testable hypotheses. We're only going to > see increasing use of this technology going forward. > > TL;DR: I think this is a bad idea. We already have effective mechanisms > for dealing with spam and bad faith contributions. Banning LLM use by > Gentoo contributors at this point is just throwing the baby out with the > bathwater. The problem is that in FOSS, a lot of people are getting flooded with AI spam and therefore have little regard for any possibly-good parts of it. I count myself as part of that group - it's very much sludge and I feel tired just seeing it talked about at the moment. Is that super rational? No, but we're also volunteers and it's not unreasonable for said volunteers to then say "well I don't want any more of that". I think this colours a lot of the responses here, and it doesn't invalidate them, but it also explains why nobody is really interested in being open to this for now. Who can blame them (me included)? > > As an alternative I'd be very happy some guidelines for the use of LLMs > and other assistive technologies like "Don't use LLM code snippets > unless you understand them", "Don't blindly copy and paste LLM output", > or, my personal favourite, "Don't be a jerk to our poor bug wranglers". > > A blanket "No completely AI/LLM generated works" might be fine, too. > > Let's see how the legal issues shake out before we start pre-emptively > banning useful tools. There's a lot of ongoing action in this space - at > the very least I'd
[gentoo-dev] Last rites: sci-libs/mpir
# Eli Schwartz (2024-02-29) # Ancient fork of gmp from 2017. Various build issues, fails tests. All # reverse dependencies turned out to be incorrect or preferred gmp # anyways. No path forward to keeping it buildable, no use case for # keeping it around. Bug #812950, #874537, #925308 # Removal on 2024-03-31. sci-libs/mpir signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
Michał Górny writes: > Hello, > > Given the recent spread of the "AI" bubble, I think we really need to > look into formally addressing the related concerns. In my opinion, > at this point the only reasonable course of action would be to safely > ban "AI"-backed contribution entirely. In other words, explicitly > forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to > create ebuilds, code, documentation, messages, bug reports and so on for > use in Gentoo. > > Just to be clear, I'm talking about our "original" content. We can't do > much about upstream projects using it. > I agree with the proposal, just some thoughts below. I'm a bit worried this is slightly performative - which is not a dig at you at all - given we can't really enforce it, and it requires honesty, but that's also not a reason to not try ;) > > Rationale: > > 1. Copyright concerns. At this point, the copyright situation around > generated content is still unclear. What's pretty clear is that pretty > much all LLMs are trained on huge corpora of copyrighted material, and > all fancy "AI" companies don't give shit about copyright violations. > In particular, there's a good risk that these tools would yield stuff we > can't legally use. > It also makes risk for anyone basing products or tools on Gentoo if we're not confident about the integrity / provenance of our work. > 2. Quality concerns. LLMs are really great at generating plausibly > looking bullshit. I suppose they can provide good assistance if you are > careful enough, but we can't really rely on all our contributors being > aware of the risks. > > 3. Ethical concerns. As pointed out above, the "AI" corporations don't > give shit about copyright, and don't give shit about people. The AI > bubble is causing huge energy waste. It is giving a great excuse for > layoffs and increasing exploitation of IT workers. It is driving > enshittification of the Internet, it is empowering all kinds of spam > and scam. > > > Gentoo has always stood out as something different, something that > worked for people for whom mainstream distros were lacking. I think > adding "made by real people" to the list of our advantages would be > a good thing — but we need to have policies in place, to make sure shit > doesn't flow in. > > Compare with the shitstorm at: > https://github.com/pkgxdev/pantry/issues/5358 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
Marek Szuba writes: > On 2024-02-27 14:45, Michał Górny wrote: > >> In my opinion, at this point the only reasonable course of action >> would be to safely ban "AI"-backed contribution entirely. In other >> words, explicitly forbid people from using ChatGPT, Bard, GitHub >> Copilot, and so on, to create ebuilds, code, documentation, messages, >> bug reports and so on for use in Gentoo. > > I very much support this idea, for all the three reasons quoted. > >> 2. Quality concerns. LLMs are really great at generating plausibly >> looking bullshit. I suppose they can provide good assistance if you >> are careful enough, but we can't really rely on all our contributors >> being aware of the risks. > > https://arxiv.org/abs/2211.03622 > >> 3. Ethical concerns. > > ...yeah. Seeing as we failed to condemn the Russian invasion of > Ukraine in 2022, I would probably avoid quoting this as a reason for > banning LLM-generated contributions. Even though I do, as mentioned > above, very much agree with this point. That's not a technical topic and we had an extended discussion about what to do in -core, which included the risks of making life difficult for Russian developers and contributors. I don't think that's a helpful intervention here, sorry.
Re: [gentoo-dev] [PATCH 1/3] meson.eclass: wire up LTO support directly into the meson options
Eli Schwartz writes:
> [[PGP Signed Part:Undecided]]
> On 2/20/24 1:24 AM, Mike Gilbert wrote:
>> I'm afraid I get different results. Build log attached. Happy to help
>> figure this out tomorrow.
>>
>> To test, I applied this patch and ran this:
>>
>> ABI_X86="32 x32 64" CFLAGS="-O2 -pipe -march=amdfam10 -flto=2" ebuild
>> zstd-1.5.5-r1.ebuild clean configure
>
>
> Yikes. I wonder if this is also a problem for ffmpeg:
>
> multilib_src_configure() {
>
> [...]
>
> # LTO support, bug #566282, bug #754654, bug #772854
> if [[ ${ABI} != x86 ]] && tc-is-lto; then
> # Respect -flto value, e.g -flto=thin
> local v="$(get-flag flto)"
> [[ -n ${v} ]] && myconf+=( "--enable-lto=${v}" ) || myconf+=(
> "--enable-lto" )
> fi
> filter-lto
It is indeed.. https://bugs.gentoo.org/923491.
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 2/3] distutils-r1.eclass: wire up meson-python to meson.eclass
Eli Schwartz writes:
> The meson-python build backend -- as the name suggests -- uses meson
> under the hood. We have a meson eclass which does lots of useful things
> pertinent to meson. Make sure it gets invoked.
>
Maybe check a sample (or ideally all) of the meson-python reverse
dependencies?
> Signed-off-by: Eli Schwartz
> ---
> eclass/distutils-r1.eclass | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index c0d1992ccce0..35825d4c3aa6 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -197,6 +197,10 @@ _DISTUTILS_R1_ECLASS=1
> inherit flag-o-matic
> inherit multibuild multilib multiprocessing ninja-utils toolchain-funcs
>
> +if [[ ${DISTUTILS_USE_PEP517} = meson-python ]]; then
> + inherit meson
> +fi
> +
> if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
> inherit python-r1
> else
> @@ -1386,6 +1390,7 @@ distutils_pep517_install() {
> )
> ;;
> meson-python)
> + meson_src_configure "${DISTUTILS_ARGS[@]}"
> local -x NINJAOPTS=$(get_NINJAOPTS)
> config_settings=$(
> "${EPYTHON}" - "${DISTUTILS_ARGS[@]}" <<-EOF ||
> die
> @@ -1397,7 +1402,6 @@ distutils_pep517_install() {
> ninjaopts =
> shlex.split(os.environ["NINJAOPTS"])
> print(json.dumps({
> "builddir": "${BUILD_DIR}",
> - "setup-args": sys.argv[1:],
> "compile-args": ["-v"] +
> ninjaopts,
> }))
> EOF
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 0/3] eclass updates for meson <> distutils <> LTO
Eli Schwartz writes: > Mainly motivated by some upstream work I did with dev-python/scipy, > which has some ancient code that will never be updated to work with LTO, > and some nice new code that works great. > > The first patch is a nice improvement on its own. The second one makes > limited sense without the third one. > The lot LGTM. > Eli Schwartz (3): > meson.eclass: wire up LTO support directly into the meson options > distutils-r1.eclass: wire up meson-python to meson.eclass > distutils-r1.eclass: fix src_configure to handle flag-o-matic > correctly > > eclass/distutils-r1.eclass | 11 +++ > eclass/meson.eclass| 36 > 2 files changed, 39 insertions(+), 8 deletions(-) signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] check-reqs.eclass: more disk checks
"Robin H. Johnson" writes:
> Allow checking more disk space, for users with many split volumes and
> ever-larger packages.
>
> gentoo-kernel-bin:
> / >=350MB/version (in /lib/modules)
> /boot >=40MB/version
>
> rust-bin:
> /opt >=450MB/version
>
LGTM, but give a bit of time for other comments.
> Signed-off-by: Robin H. Johnson
> ---
> eclass/check-reqs.eclass | 44 +++-
> 1 file changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
> index fac2f4553d74..7b65f44e8c41 100644
> --- a/eclass/check-reqs.eclass
> +++ b/eclass/check-reqs.eclass
> @@ -24,12 +24,21 @@
> # # need this much temporary build space
> # CHECKREQS_DISK_BUILD="2G"
> #
> +# # install will need this much space in /
> +# CHECKREQS_DISK_ROOT="1G"
> +#
> +# # install will need this much space in /boot
> +# CHECKREQS_DISK_BOOT="128M"
> +#
> # # install will need this much space in /usr
> # CHECKREQS_DISK_USR="1G"
> #
> # # install will need this much space in /var
> # CHECKREQS_DISK_VAR="1024M"
> #
> +# # install will need this much space in /opt
> +# CHECKREQS_DISK_OPT="1G"
> +#
> # @CODE
> #
> # If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is
> not
> @@ -56,6 +65,16 @@ _CHECK_REQS_ECLASS=1
> # @DESCRIPTION:
> # How much diskspace is needed to build the package? Eg.:
> CHECKREQS_DISK_BUILD=2T
>
> +# @ECLASS_VARIABLE: CHECKREQS_DISK_ROOT
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# How much space in / is needed to install the package? Eg.:
> CHECKREQS_DISK_ROOT=1G
> +
> +# @ECLASS_VARIABLE: CHECKREQS_DISK_BOOT
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# How much space in /boot is needed to install the package? Eg.:
> CHECKREQS_DISK_BOOT=128M
> +
> # @ECLASS_VARIABLE: CHECKREQS_DISK_USR
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> @@ -66,6 +85,11 @@ _CHECK_REQS_ECLASS=1
> # @DESCRIPTION:
> # How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M
>
> +# @ECLASS_VARIABLE: CHECKREQS_DISK_OPT
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# How much space is needed in /opt? Eg.: CHECKREQS_DISK_OPT=1G
> +
> # @ECLASS_VARIABLE: CHECKREQS_DONOTHING
> # @USER_VARIABLE
> # @DEFAULT_UNSET
> @@ -121,8 +145,11 @@ _check-reqs_prepare() {
>
> if [[ -z ${CHECKREQS_MEMORY} &&
> -z ${CHECKREQS_DISK_BUILD} &&
> + -z ${CHECKREQS_DISK_ROOT} &&
> + -z ${CHECKREQS_DISK_BOOT} &&
> -z ${CHECKREQS_DISK_USR} &&
> - -z ${CHECKREQS_DISK_VAR} ]]; then
> + -z ${CHECKREQS_DISK_VAR} &&
> + -z ${CHECKREQS_DISK_OPT} ]]; then
> eerror "Set some check-reqs eclass variables if you want to use
> it."
> eerror "If you are user and see this message file a bug against
> the package."
> die "${FUNCNAME}: check-reqs eclass called but not actually
> used!"
> @@ -161,6 +188,16 @@ _check-reqs_run() {
> fi
>
> if [[ ${MERGE_TYPE} != buildonly ]]; then
> + [[ -n ${CHECKREQS_DISK_ROOT} ]] && \
> + _check-reqs_disk \
> + "${EROOT%/}/" \
> + "${CHECKREQS_DISK_ROOT}"
> +
> + [[ -n ${CHECKREQS_DISK_BOOT} ]] && \
> + _check-reqs_disk \
> + "${EROOT%/}/boot" \
> + "${CHECKREQS_DISK_BOOT}"
> +
> [[ -n ${CHECKREQS_DISK_USR} ]] && \
> _check-reqs_disk \
> "${EROOT%/}/usr" \
> @@ -170,6 +207,11 @@ _check-reqs_run() {
> _check-reqs_disk \
> "${EROOT%/}/var" \
> "${CHECKREQS_DISK_VAR}"
> +
> + [[ -n ${CHECKREQS_DISK_OPT} ]] && \
> + _check-reqs_disk \
> + "${EROOT%/}/opt" \
> + "${CHECKREQS_DISK_OPT}"
> fi
> }
signature.asc
Description: PGP signature
[gentoo-dev] Please fill in .mailmap if desired
Hi, Following the previous discussion on .mailmap, I've committed it to gentoo.git in https://marc.info/?l=gentoo-dev=170781377903495=2. Please consider filling in .mailmap if you'd like your pre-developer contributions to be accurately mapped, if you've accidentally used the wrong email at some point, or if any of the other reasons from the original post apply. You can check https://www.mantisbt.org/wiki/doku.php/mantisbt:mailmap for some handy commands to identify if you are a candidate. See gitmailmap(5) for help on the format - or just ask. Use of .mailmap is not mandatory. thanks, sam signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] x86 arch testing: please use -mfpmath=sse
Michał Górny writes: > [[PGP Signed Part:Undecided]] > Hello, > > TL;DR: when arch testing for x86, please use `-mfpmath=sse` (this may > require raising `-march=` to `pentium4` or newer, or adding `-msse2`. > > > The x86 architecture historically supports two floating-precision > arithmetic modes: using the 387 coprocessor, and using the SSE > instruction set. The compilers default to using the former when > compiling for 32-bit x86, and the latter for amd64. > > The problem with 387 arithmetic is that it uses nonstandard 80-bit > registers (vs 64-bit doubles). While technically this means that it > achieves better precision, it often means that the same computations > yield different rounding results. As a result, test built against amd64 > fail with 387-based arithmetic. > > While technically these tests are broken in the first place for doing > exact matching on floating-point arithmetic results, getting everything > fixed is a major issue. These problems are quite unlikely to affect > real use cases. On top of that, many upstreams don't care about 32-bit > systems much, and bothering them with avoidable test failures reduces > our chances of having real problems solved. Yes. To be clear, this is NOT about us not caring about bugs without SSE or SSE2, but rather that right now, the spurious FP comparison failures are blocking stabilisation on x86 and are causing people to not want to look at x86 at all and keep calling for it to be destabled. I'm very happy to look into interesting problems, I just don't think it's a good use of anybody's time to be reporting these FP issues when it's taking time away from real problems on these platforms. We're better off with this by avoiding useless failures. We also did this for multilib x86 a while ago -- see ed189588a071f88186a3a9de25abfbd7582b9c69. > > Therefore, I would like to ask arch testers not to test with 387 > floating-point arithmetic anymore. We have already switched amd64 > multilib to use `-mfpmath=sse` for 32-bit multilib, and we are planning > to provide x86 profiles with SSE2 baseline as well. > > Note that in order for `-mfpmath=sse` to be fully effectively, the code > must be compiled with SSE2 support. This could be achieved by using `- > march=pentium4` or higher, or adding `-msse2`. > > TIA. +1 thanks for doing this, sam signature.asc Description: PGP signature
[gentoo-dev] Introducing .mailmap?
Hi, We should consider adding a .mailmap to gentoo.git. There's a few reasons: * We should accurately map pre-developer-status contributions. For example, it'd be nice if s...@cmpct.info was mapped correctly into s...@gentoo.org when doing git blame. We know s...@cmpct.info and s...@gentoo.org are the same person, it feels coherent to tell git that via the mechanism intended for it. * It's useful for when people retire as well. Not that I plan on going anywhere any time soon (sorry!), but this is both a useful way for people to better "retain credit" *and* for e.g. 'git blame' to work better if they then come back as a contributor but not a developer, which happens on occasion, or if they occasionally contribute with a different email address (we have this for some devs who contribute under a "work context" too). * It allows people to have git respecting changing their name for various reasons (e.g. we've had contributors start using their real name and vice-versa over the years). I was considering this anyway but xgqt pinged me about it after I mentioned it on a recent bug (https://bugs.gentoo.org/836936#c12) as well which made me think there's perhaps some merit in it. thanks, sam signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs
Daniel Simionato writes: > Hello, > I'd like to start a discussion regarding setting HOME_MODE by default in the > /etc/login.defs file (owned by > sys-apps/shadow package). > > Upstream keeps HOME_MODE commented: > https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb5c28468e33a4529d5/etc/login.defs#L207 > > HOME_MODE affects only useradd and newuser commands: if HOME_MODE is set, > they will use the specified permission when > creating a user home directory, otherwise the default UMASK will be used. > Since the default umask is 022, keeping HOME_MODE unset will result in home > readable home directories created by useradd, > which goes against security best practices. > > The proposal is to set HOME_MODE to 0700, or at least 0750: RedHat and RH > based distros, OpenSuse, ArchLinux all set it > to 0700, Ubuntu has it at 0750. Debian and Gentoo are two exceptions, keeping > the upstream value of HOME_MODE (although > login.defs is changed in other ways). > > I previously made a PR on github where you can find more details > (https://github.com/gentoo/gentoo/pull/35231), but as > pointed in the comments this probably warrants some discussion beforehand. > > I can understand the argument against the change, which is keeping in sync > with upstream and don't risk changing the > historic default behaviour of tools some users might rely upon. > > I do believe though there's merit in providing safer and secure defaults, so > I would like HOME_MODE to have a safe > default value for Gentoo and Gentoo based distros. I'm in favour, although I'd be curious as to why upstream shadow don't just set it. It would be interesting to see if the discussion already happened there at some point (surely it has?) and find out their reasoning. (But that's not a blocker for proceeding.) I want to hear more opinions first though. Thanks for raising this, it's been in the back of my head. > > Have a nice day, > Daniel best, sam signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs
Michael Orlitzky writes: > On Sat, 2024-02-10 at 17:57 +0100, Daniel Simionato wrote: >> Hello, >> I'd like to start a discussion regarding setting HOME_MODE by default in >> the /etc/login.defs file (owned by sys-apps/shadow package). >> >> Upstream keeps HOME_MODE commented: >> https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb5c28468e33a4529d5/etc/login.defs#L207 >> >> HOME_MODE affects only useradd and newuser commands: if HOME_MODE is set, >> they will use the specified permission when creating a user home directory, >> otherwise the default UMASK will be used. >> Since the default umask is 022, keeping HOME_MODE unset will result in home >> readable home direct > > umask 022 is also egregious, changing it to 027 would kill two birds. > But in lieu of that, yes. mgorny wrote in favour of this 13 years ago too: https://blogs.gentoo.org/mgorny/2011/10/18/027-umask-a-compromise-between-security-and-simplicity/. It would be a bigger change and require us to do a lot of daily-driver testing first though. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] kernel-install.eclass: explicitly set kernel image to 644
Andrew Ammerlaan writes:
> Author: Andrew Ammerlaan
> Date: Sun Feb 11 10:41:32 2024 +0100
>
Did you not use git-send-email here or what's going on?
Formatting looks off.
> kernel-install.eclass: explicitly set kernel image to 644
>
> The kernel build system sets the permissions on the kernel
> image to 644. However objcopy creates a file with permissions
> 755. This causes a discrepancy in the permissions on the
> installed kernel image between +generic-uki,-generic-uki and
> between gentoo-kernel, gentoo-kernel-bin.
>
> Restore the symmetry by explicitly setting the objcopy'ed
> files permissions to 644.
>
Anyway, OK.
> Signed-off-by: Andrew Ammerlaan
>
> diff --git a/eclass/kernel-install.eclass b/eclass/kernel-install.eclass
> index 47865a953389..f512d815fe09 100644
> --- a/eclass/kernel-install.eclass
> +++ b/eclass/kernel-install.eclass
> @@ -621,6 +621,7 @@ kernel-install_extract_from_uki() {
>
> $(tc-getOBJCOPY) -O binary "-j.${extract_type}" "${uki}" "${out}" ||
> die "Failed to extract ${extract_type}"
> + chmod 644 "${out}" || die
> }
>
> # @FUNCTION: kernel-install_install_all
signature.asc
Description: PGP signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
Eli Schwartz writes: > [[PGP Signed Part:Undecided]] > On 2/9/24 7:04 PM, Sam James wrote: >> >> Eli Schwartz writes: >>> Often, USE flags have an obvious point even without selecting or >>> deselecting dependencies -- usually because their maintainers took care >>> in describing it in metadata.xml. >>> >> >> To pick up on this point: yes, if one concludes the USE flag has merit >> and the global description is either poor or has some reason to be >> considered spurious in the case of the package, you should consider >> documenting it to avoid this question. >> >> Adding a suppression like https://github.com/pkgcore/pkgcheck/issues/478 >> proposes should really be accompanied by such an improvement anyway for >> the benefit of users. > > > I'd like to request in the event that this pkgcheck ticket is > implemented, that including a description in metadata.xml which provides > additional package specific information (or, programmatically, "is > non-empty and un-equal to the global description") is made mandatory for > the purposes of silencing this warning... :) parona ended up messaging me and pointing out that https://pkgcore.github.io/pkgcheck/man/pkgcheck.html#useflagwithoutdeps already says... > In cases where this USE flag is appropriate, you can silence this > warning by adding a description to this USE flag in metadata.xml file > and thus making it a local USE flag instead of global one. which I think pretty much solves the full thing already... signature.asc Description: PGP signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
Eli Schwartz writes: > [[PGP Signed Part:Undecided]] > On 2/9/24 2:57 PM, Michael Orlitzky wrote: >> One example I know off the top of my head is dev-lang/php where >> USE=ipv6 isn't entirely about ipv6 connectivity (although it does do >> that). It also augments some of the user-facing PHP language functions >> with ipv6 support. Having them enabled is not a big deal, and PHP is a >> programming language so you may say that it's atypical, but... for a >> package that gets a new CVE every week and sits on the public web, I'd >> just rather have it off? > > > Counterpoint: some PHP program out there is probably vulnerable because > it tried to validate an ipv6 address and could not distinguish between > "it's okay" and "idk if it's okay, the function you called does not > exist" (because php is really that terrible of a language). > I was going to make this point as well but I didn't want to go down that route as I figured it'd come across like I'm questioning Michael, as oppossed to trying to make a point about using an option simply because it exists. i.e. Disabling an option isn't always as simple as it sounds (see below). But I'm also not personally wanting to debate that PHP should remove it, just saying that this sort of consideration should be made and it's part of why a USE flag for everything is not always great. We *HAVE* had real problems like this before, see also USE=threads (check out commit bd4d42f83c774c36bf879a5b7ec89d373546743e). > [...] >> I really don't want to fall into a trap where I make up reasons why >> other people might want to do things and everyone says my reasons are >> stupid. Everyone is going to have different reasons, and we have a lot >> of users who are our users because they're edge cases. >> >> It's not unfathomably stupid to build a package without ipv6 or unicode >> support (whatever that means), and there are no small files to worry >> about, so I don't think they deserve the special negative treatment. > > > Maintainability matters too. So does user experience in the other > direction: too many USE flags will lead users to confusion if they don't > understand what all those flags do, and accidentally choose the wrong > answer. also whether the flag then gets tinderboxed, reverse dependencies having to depend on the right flags, debugging user issues which may not be obvious (especially if they surface in another application/interface) because of it... (It's also worth us having the discussion about whether a flag existing means a tinderbox should try it, e.g. USE=debug which IMO isn't suitable for this at all (see also its description) and the kernel stuff like for secureboot.) > > That's not necessarily a reason to remove choice, so much as it is a > reason to... carefully document what that choice actually gets you. > > $ equery -N uses sbcl | grep unicode > + + unicode : Add support for Unicode > > > This is... vague. Good to know that it is enabled by default, but... > what? What does it do? There is no description in metadata.xml, either. > > I think it is fair and reasonable for people to ask people's reasons are > for doing something when it is not actually obvious what the point is. > And when a USE flag selects or deselects dependencies, it is very easy > to know, what exactly "the point" is. > > Often, USE flags have an obvious point even without selecting or > deselecting dependencies -- usually because their maintainers took care > in describing it in metadata.xml. > To pick up on this point: yes, if one concludes the USE flag has merit and the global description is either poor or has some reason to be considered spurious in the case of the package, you should consider documenting it to avoid this question. Adding a suppression like https://github.com/pkgcore/pkgcheck/issues/478 proposes should really be accompanied by such an improvement anyway for the benefit of users. signature.asc Description: PGP signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
Michael Orlitzky writes: > On Fri, 2024-02-09 at 14:09 -0500, Eli Schwartz wrote: >> >> Asking out of genuine ignorance: what kind of direct behavioral changes >> occur as a result of setting or unsetting USE=ipv6. > > One example I know off the top of my head is dev-lang/php where > USE=ipv6 isn't entirely about ipv6 connectivity (although it does do > that). It also augments some of the user-facing PHP language functions > with ipv6 support. Having them enabled is not a big deal, and PHP is a > programming language so you may say that it's atypical, but... for a > package that gets a new CVE every week and sits on the public web, I'd > just rather have it off? A few years ago when this last came up, I ended up digging into a bunch of USE=ipv6 providers and found that USE=-ipv6 either didn't build, took a less supported (non-default-upstream) codepath which looked bitrotten, only toggled default configuration (sometimes via the build system). I also found several cases where it ended up taking a legacy code path while the USE=ipv6 one used modern networking functions which happened to then support IPv6. For a case like the latter one (and the rest I mention, really), disabilng kernel support is more appropriate. But read on wrt PHP. > > Unicode support is similar in my mind. Adding "unicode support" to a > package might be easy (at the cost of some extra memory), but dealing > with the consequences of unicode is harder. Maybe I don't want to worry > about homoglyphs and bidirectional text when I'm validating a hostname? > Life is just simpler without it, if you know you don't need it. Things > also tend to be more space and memory efficient with features compiled > out; not to mention that the compile times themselves are improved. > You're still pulling in "extra dependencies," in a sense, even if > they're in the same tarball. I think what you really want is https://github.com/pkgcore/pkgcheck/issues/478 because you've made the case as its maintainer for the flags to exist. The discussion really ends there in such a case given you're considered the matter and decided it has value in PHP. The issue is therefore just having a suppression for pkgcheck. The pkgcheck rule was intended as a hint that something might be suspicious, rather than indicating it must be removed. thanks, sam signature.asc Description: PGP signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
Andrey Grozin writes: > Hello *, > > pkgcheck complains about each new version of dev-lisp/sbcl: > > UseFlagWithoutDeps: version 2.4.1: special small-files USE flag > without effect on dependencies: [ unicode ] > > The USE flag "unicode" in the sbcl ebuild has nothing to do with > installing / not installing any files, small or otherwise. It > determins whether the produced lisp will support unicode internally: > > sbcl_feature "$(usep unicode)" ":sb-unicode" > > Usually this is desirable, so, in USE we have +unicode. > If you can't think of a someone to not want it, you should just enable it. Common reasons to not want it are substantial impact on build-time, additional dependencies, unsupported or poorly supported upstream, experimental status, and so on. Most of the time, one of these applies for these flags, and it's therefore useless. Hence https://github.com/pkgcore/pkgcheck/issues/414. Note further that USE=unicode is forced on for many packages in profiles and historically it ended up changing ABI for a bunch of them. If you conclude that there is a valid reason to toggle it, then the next part becomes relevant: > Is there a way to silence these warnings? There are real times when we may want to suppress the warning/notices. This is tracked as https://github.com/pkgcore/pkgcheck/issues/478 for pkgcheck. thanks, sam signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v3] llvm-r1.eclass: Initial version
Michał Górny writes:
> See-Also: https://bugs.gentoo.org/923228
> See-Also: https://bugs.gentoo.org/880671
s/See-Also/Bug/.
LGTM otherwise. Thanks for working on this, it's a great improvement.
> Closes: https://bugs.gentoo.org/821955
> Closes: https://bugs.gentoo.org/919150
> Signed-off-by: Michał Górny
> ---
> eclass/llvm-r1.eclass | 250
> eclass/tests/llvm-r1.sh | 151
> 2 files changed, 401 insertions(+)
> create mode 100644 eclass/llvm-r1.eclass
> create mode 100755 eclass/tests/llvm-r1.sh
>
> Changed in v3: added LLVM_OPTIONAL to avoid unconditionally setting
> REQUIRED_USE when the ebuild doesn't require LLVM unconditionally.
> It also controls pkg_setup export.
>
> diff --git a/eclass/llvm-r1.eclass b/eclass/llvm-r1.eclass
> new file mode 100644
> index ..658946a1ecbd
> --- /dev/null
> +++ b/eclass/llvm-r1.eclass
> @@ -0,0 +1,250 @@
> +# Copyright 2024 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: llvm-r1.eclass
> +# @MAINTAINER:
> +# Michał Górny
> +# @AUTHOR:
> +# Michał Górny
> +# @SUPPORTED_EAPIS: 8
> +# @PROVIDES: llvm-utils
> +# @BLURB: Provide LLVM_SLOT to build against slotted LLVM
> +# @DESCRIPTION:
> +# An eclass to reliably depend on a set of LLVM-related packages
> +# in a matching slot. To use the eclass:
> +#
> +# 1. Set LLVM_COMPAT to the list of supported LLVM slots.
> +# 2. Use llvm_gen_dep and/or LLVM_USEDEP to add appropriate
> +#dependencies.
> +# 3. Use llvm-r1_pkg_setup, get_llvm_prefix or LLVM_SLOT.
> +#
> +# The eclass sets IUSE and REQUIRED_USE. The flag corresponding
> +# to the newest supported stable LLVM slot (or the newest testing,
> +# if no stable slots are supported) is enabled by default.
> +#
> +# Example:
> +# @CODE
> +# LLVM_COMPAT=( {16..18} )
> +#
> +# inherit llvm-r1
> +#
> +# DEPEND="
> +# dev-libs/libfoo[${LLVM_USEDEP}]
> +# $(llvm_gen_dep '
> +# sys-devel/clang:${LLVM_SLOT}
> +# sys-devel/llvm:${LLVM_SLOT}
> +# ')
> +# "
> +# @CODE
> +
> +case ${EAPI} in
> + 8) ;;
> + *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> +esac
> +
> +if [[ ! ${_LLVM_R1_ECLASS} ]]; then
> +_LLVM_R1_ECLASS=1
> +
> +inherit llvm-utils
> +
> +# == internal control knobs ==
> +
> +# @ECLASS_VARIABLE: _LLVM_OLDEST_SLOT
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Oldest supported LLVM slot. This is used to automatically filter out
> +# unsupported LLVM_COMPAT values.
> +_LLVM_OLDEST_SLOT=15
> +
> +# @ECLASS_VARIABLE: _LLVM_NEWEST_STABLE
> +# @INTERNAL
> +# @DESCRIPTION:
> +# The newest stable LLVM version. Versions newer than that won't
> +# be automatically enabled via USE defaults.
> +_LLVM_NEWEST_STABLE=17
> +
> +# == control variables ==
> +
> +# @ECLASS_VARIABLE: LLVM_COMPAT
> +# @PRE_INHERIT
> +# @REQUIRED
> +# @DESCRIPTION:
> +# A list of LLVM slots supported by the package, oldest to newest.
> +#
> +# Example:
> +# @CODE
> +# LLVM_COMPAT=( {15..17} )
> +# @CODE
> +
> +# @ECLASS_VARIABLE: LLVM_OPTIONAL
> +# @PRE_INHERIT
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# If set to a non-empty value, disables setting REQUIRED_USE
> +# and exporting pkg_setup. You have to add LLVM_REQUIRED_USE and call
> +# pkg_setup manually, with appropriate USE conditions.
> +
> +# == global metadata ==
> +
> +# @ECLASS_VARIABLE: LLVM_REQUIRED_USE
> +# @OUTPUT_VARIABLE
> +# @DESCRIPTION:
> +# An eclass-generated REQUIRED_USE string that enforces selecting
> +# exactly one slot. It LLVM_OPTIONAL is set, it needs to be copied
> +# into REQUIRED_USE, under appropriate USE conditions. Otherwise,
> +# it is added automatically.
> +
> +# @ECLASS_VARIABLE: LLVM_USEDEP
> +# @OUTPUT_VARIABLE
> +# @DESCRIPTION:
> +# An eclass-generated USE dependency string that can be applied to other
> +# packages using the same eclass, to enforce a LLVM slot match.
> +
> +_llvm_set_globals() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + if [[ ${LLVM_COMPAT@a} != *a* ]]; then
> + die "LLVM_COMPAT must be set to an array before inheriting
> ${ECLASS}"
> + fi
> +
> + local stable=() unstable=()
> + local x
> + for x in "${LLVM_COMPAT[@]}"; do
> + if [[ ${x} -gt ${_LLVM_NEWEST_STABLE} ]]; then
> + unstable+=( "${x}" )
> + elif [[ ${x} -ge ${_LLVM_OLDEST_SLOT} ]]; then
> + stable+=( "${x}" )
> + fi
> + done
> +
> + _LLVM_SLOTS=( "${stable[@]}" "${unstable[@]}" )
> + if [[ ! ${_LLVM_SLOTS[@]} ]]; then
> + die "LLVM_COMPAT does not contain any valid versions (all older
> than ${_LLVM_OLDEST_SLOT}?)"
> + fi
> +
> + if [[ ${stable[@]} ]]; then
> + IUSE="+llvm_slot_${stable[-1]}"
> + unset 'stable[-1]'
> + else
> + IUSE="+llvm_slot_${unstable[-1]}"
> + unset 'unstable[-1]'
> + fi
> + local nondefault=( "${stable[@]}" "${unstable[@]}" )
> +
Re: [gentoo-dev] [PATCH 1/7] eclass/dotnet-pkg-base.eclass: quotes and style tweaks for edge cases
Maciej Barć writes:
> Signed-off-by: Maciej Barć
> ---
The series lgtm but please add some commit messages to them explaining
the motivation / why we're doing it now if applicable. No need to
re-send to ML once that's done.
Thanks!
> eclass/dotnet-pkg-base.eclass | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/eclass/dotnet-pkg-base.eclass b/eclass/dotnet-pkg-base.eclass
> index 1a9d31120..e7484a6c5 100644
> --- a/eclass/dotnet-pkg-base.eclass
> +++ b/eclass/dotnet-pkg-base.eclass
> @@ -63,18 +63,24 @@ DOTNET_PKG_BDEPS=""
>
> # Have this guard to be sure that *DEPS are not added to
> # the "dev-dotnet/dotnet-runtime-nugets" package dependencies.
> -if [[ ${CATEGORY}/${PN} != dev-dotnet/dotnet-runtime-nugets ]] ; then
> +if [[ "${CATEGORY}/${PN}" != dev-dotnet/dotnet-runtime-nugets ]] ; then
> if [[ -z ${DOTNET_PKG_COMPAT} ]] ; then
> die "${ECLASS}: DOTNET_PKG_COMPAT not set"
> fi
>
> - DOTNET_PKG_RDEPS+=" virtual/dotnet-sdk:${DOTNET_PKG_COMPAT} "
> - DOTNET_PKG_BDEPS+=" ${DOTNET_PKG_RDEPS} "
> + DOTNET_PKG_RDEPS+="
> + virtual/dotnet-sdk:${DOTNET_PKG_COMPAT}
> + "
> + DOTNET_PKG_BDEPS+="
> + ${DOTNET_PKG_RDEPS}
> + "
>
> # Special package "dev-dotnet/csharp-gentoodotnetinfo" used for
> information
> # gathering, example for usage see the "dotnet-pkg-base_info" function.
> - if [[ ${CATEGORY}/${PN} != dev-dotnet/csharp-gentoodotnetinfo ]] ; then
> - DOTNET_PKG_BDEPS+=" dev-dotnet/csharp-gentoodotnetinfo "
> + if [[ "${CATEGORY}/${PN}" != dev-dotnet/csharp-gentoodotnetinfo ]] ;
> then
> + DOTNET_PKG_BDEPS+="
> + dev-dotnet/csharp-gentoodotnetinfo
> + "
> fi
>
> IUSE+=" debug "
Re: [gentoo-dev] [PATCH 6/8] dev-util/intel_clc: Migrate to llvm-r1
Michał Górny writes:
> Closes: https://bugs.gentoo.org/923228
> Signed-off-by: Michał Górny
> ---
> dev-util/intel_clc/intel_clc-24.0.0.ebuild | 48 --
> dev-util/intel_clc/intel_clc-.ebuild | 48 --
> 2 files changed, 18 insertions(+), 78 deletions(-)
Arsen, could you verify this does solve the problem for you, just to be
sure?
>
> diff --git a/dev-util/intel_clc/intel_clc-24.0.0.ebuild
> b/dev-util/intel_clc/intel_clc-24.0.0.ebuild
> index 10dd7e930b24..adb22e32e30a 100644
> --- a/dev-util/intel_clc/intel_clc-24.0.0.ebuild
> +++ b/dev-util/intel_clc/intel_clc-24.0.0.ebuild
> @@ -3,9 +3,10 @@
>
> EAPI=8
>
> +LLVM_COMPAT=( 16 17 )
> PYTHON_COMPAT=( python3_{10..12} )
>
> -inherit llvm meson python-any-r1
> +inherit llvm-r1 meson python-any-r1
>
> MY_PV="${PV/_/-}"
>
> @@ -31,6 +32,11 @@ RDEPEND="
> dev-util/spirv-tools
> >=sys-libs/zlib-1.2.8:=
> x11-libs/libdrm
> + $(llvm_gen_dep '
> + dev-util/spirv-llvm-translator:${LLVM_SLOT}
> + sys-devel/clang:${LLVM_SLOT}
> + sys-devel/llvm:${LLVM_SLOT}
> + ')
> "
> DEPEND="${RDEPEND}
> dev-libs/expat
> @@ -41,53 +47,17 @@ BDEPEND="
> virtual/pkgconfig
> "
>
> -# Please keep the LLVM dependency block separate. Since LLVM is slotted,
> -# we need to *really* make sure we're not pulling one than more slot
> -# simultaneously.
> -#
> -# How to use it:
> -# 1. Specify LLVM_MAX_SLOT (inclusive), e.g. 17.
> -# 2. Specify LLVM_MIN_SLOT (inclusive), e.g. 16.
> -LLVM_MAX_SLOT="17"
> -LLVM_MIN_SLOT="16"
> -PER_SLOT_DEPSTR="
> - (
> - dev-util/spirv-llvm-translator:@SLOT@
> - sys-devel/clang:@SLOT@
> - sys-devel/llvm:@SLOT@
> - )
> -"
> -LLVM_DEPSTR="
> - || (
> - $(for ((slot=LLVM_MAX_SLOT; slot>=LLVM_MIN_SLOT; slot--)); do
> - echo "${PER_SLOT_DEPSTR//@SLOT@/${slot}}"
> - done)
> - )
> - - -"
> -RDEPEND="${RDEPEND}
> - ${LLVM_DEPSTR}
> -"
> -unset LLVM_MIN_SLOT {LLVM,PER_SLOT}_DEPSTR
> -
> -llvm_check_deps() {
> - has_version "dev-util/spirv-llvm-translator:${LLVM_SLOT}" &&
> - has_version "sys-devel/clang:${LLVM_SLOT}" &&
> - has_version "sys-devel/llvm:${LLVM_SLOT}"
> -}
> -
> python_check_deps() {
> python_has_version -b ">=dev-python/mako-0.8.0[${PYTHON_USEDEP}]"
> }
>
> pkg_setup() {
> - llvm_pkg_setup
> + llvm-r1_pkg_setup
> python-any-r1_pkg_setup
> }
>
> src_configure() {
> - PKG_CONFIG_PATH="$(get_llvm_prefix
> "${LLVM_MAX_SLOT}")/$(get_libdir)/pkgconfig"
> + PKG_CONFIG_PATH="$(get_llvm_prefix)/$(get_libdir)/pkgconfig"
>
> local emesonargs=(
> -Dllvm=enabled
> diff --git a/dev-util/intel_clc/intel_clc-.ebuild
> b/dev-util/intel_clc/intel_clc-.ebuild
> index 10dd7e930b24..adb22e32e30a 100644
> --- a/dev-util/intel_clc/intel_clc-.ebuild
> +++ b/dev-util/intel_clc/intel_clc-.ebuild
> @@ -3,9 +3,10 @@
>
> EAPI=8
>
> +LLVM_COMPAT=( 16 17 )
> PYTHON_COMPAT=( python3_{10..12} )
>
> -inherit llvm meson python-any-r1
> +inherit llvm-r1 meson python-any-r1
>
> MY_PV="${PV/_/-}"
>
> @@ -31,6 +32,11 @@ RDEPEND="
> dev-util/spirv-tools
> >=sys-libs/zlib-1.2.8:=
> x11-libs/libdrm
> + $(llvm_gen_dep '
> + dev-util/spirv-llvm-translator:${LLVM_SLOT}
> + sys-devel/clang:${LLVM_SLOT}
> + sys-devel/llvm:${LLVM_SLOT}
> + ')
> "
> DEPEND="${RDEPEND}
> dev-libs/expat
> @@ -41,53 +47,17 @@ BDEPEND="
> virtual/pkgconfig
> "
>
> -# Please keep the LLVM dependency block separate. Since LLVM is slotted,
> -# we need to *really* make sure we're not pulling one than more slot
> -# simultaneously.
> -#
> -# How to use it:
> -# 1. Specify LLVM_MAX_SLOT (inclusive), e.g. 17.
> -# 2. Specify LLVM_MIN_SLOT (inclusive), e.g. 16.
> -LLVM_MAX_SLOT="17"
> -LLVM_MIN_SLOT="16"
> -PER_SLOT_DEPSTR="
> - (
> - dev-util/spirv-llvm-translator:@SLOT@
> - sys-devel/clang:@SLOT@
> - sys-devel/llvm:@SLOT@
> - )
> -"
> -LLVM_DEPSTR="
> - || (
> - $(for ((slot=LLVM_MAX_SLOT; slot>=LLVM_MIN_SLOT; slot--)); do
> - echo "${PER_SLOT_DEPSTR//@SLOT@/${slot}}"
> - done)
> - )
> - - -"
> -RDEPEND="${RDEPEND}
> - ${LLVM_DEPSTR}
> -"
> -unset LLVM_MIN_SLOT {LLVM,PER_SLOT}_DEPSTR
> -
> -llvm_check_deps() {
> - has_version "dev-util/spirv-llvm-translator:${LLVM_SLOT}" &&
> - has_version "sys-devel/clang:${LLVM_SLOT}" &&
> - has_version "sys-devel/llvm:${LLVM_SLOT}"
> -}
> -
> python_check_deps() {
> python_has_version -b ">=dev-python/mako-0.8.0[${PYTHON_USEDEP}]"
> }
>
> pkg_setup() {
> - llvm_pkg_setup
> + llvm-r1_pkg_setup
> python-any-r1_pkg_setup
> }
>
> src_configure() {
> - PKG_CONFIG_PATH="$(get_llvm_prefix
>
Re: [gentoo-dev] [RFC] Gentoo Bugzilla: new resolution for bugs closed due to last rites
Ionen Wolkens writes: > [[PGP Signed Part:Undecided]] > On Wed, Feb 07, 2024 at 12:03:52PM +0100, Michał Górny wrote: >> Hi, >> >> I think we should add a new bug resolution that would more precisely >> cover closing bugs due to packages being removed. Right now, whichever >> resolution we use (be it WONTFIX, OBSOLETE, etc.), we aren't able to >> easily distinguish whether the resolution was used "normally" or due to >> last rites. >> >> Having a dedicated resolution (technical name RESO/PKGREMOVED) would >> make this clear. Furthermore, it would make it easier to reopen bugs >> if the packages are ever reintroduced. >> >> WDYT? > > Sounds like it could be useful (that or some other way to identify > these if preferred), but think something that's missing either way > would be a way to automate/streamline it preferably without scripts. > Like additional actions for commit summaries (aka like 'Closes:'). > > In general think not many want to use bugz or do it manually on > removal. So these are often not even closed WONTFIX/OBSOLETE but > rather as FIXED through 'Closes:' regardless of what the devmanual > says (currently it instructs to do WONTFIX). Agreed. I like the idea, but for me, it's a non-starter unless we commit to doing this (some bug tag like 'Removed:' or 'Last-rited:' or w/e for commits) as well. It ends up being asked to be ignored/forgotten otherwise. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Introducing LLVM_TARGET
Sam James writes:
> Michał Górny writes:
>
>> [[PGP Signed Part:Undecided]]
>> Hi,
>>
>> TL;DR: Given that (not really surprising) the current approach for LLVM
>> dependencies doesn't work, I think it's time to give up and introduce
>> LLVM_TARGETS. This would probably mean introduce llvm-r1.eclass.
>>
>> However, since random apps tend to require old versions of LLVM, I do
>> wonder if we should set the default value globally, or have the eclass
>> generate IUSE defaults, so that everything works out of the box.
>>
>
> I need to think about this bit.
>
>>
>> The problem roughly is that right now we rely on depstrings like:
>>
>> DEPEND="
>> > > || (
>> ( sys-devel/clang:18 sys-devel/llvm:18 )
>> ( sys-devel/clang:17 sys-devel/llvm:17 )
>> ( sys-devel/clang:16 sys-devel/llvm:16 )
>> )
>> "
>>
>> This kinda works, in the sense that it will enforce that you have
>> a single matching version of LLVM+Clang, and the eclass will use it.
>> However, the := deps on top may be entirely mismatched. For example, if
>> you have llvm:18 and clang:17 (+ llvm:17) installed, you'd get:
>>
>> sys-devel/clang:17=
>> sys-devel/llvm:18=
>>
>> When more packages land on the list, this could lead to quite a mess.
>>
>> So what'd we go for would effectively be:
>>
>> DEPEND="
>> llvm_target_16? ( sys-devel/clang:16 sys-devel/llvm:16 )
>> llvm_target_17? ( sys-devel/clang:17 sys-devel/llvm:17 )
>> llvm_target_18? ( sys-devel/clang:18 sys-devel/llvm:18 )
>> "
>>
>> WDYT?
>
> We should mention that https://bugs.gentoo.org/923228 was the motivation
> that tipped us over the edge here.
>
> We should also consider the https://bugs.gentoo.org/880671 /
> https://bugs.gentoo.org/821955 case, as I think this is going to end up
> solving that too, actually.
>
I suppose it will fix https://bugs.gentoo.org/919150 for us too.
> But yeah, I like it. It solves a request we've had from users for a
> while ("let me choose") and it solves these silly dep games.
>
> Thank you!
Re: [gentoo-dev] [RFC] Introducing LLVM_TARGET
Michał Górny writes:
> [[PGP Signed Part:Undecided]]
> Hi,
>
> TL;DR: Given that (not really surprising) the current approach for LLVM
> dependencies doesn't work, I think it's time to give up and introduce
> LLVM_TARGETS. This would probably mean introduce llvm-r1.eclass.
>
> However, since random apps tend to require old versions of LLVM, I do
> wonder if we should set the default value globally, or have the eclass
> generate IUSE defaults, so that everything works out of the box.
>
I need to think about this bit.
>
> The problem roughly is that right now we rely on depstrings like:
>
> DEPEND="
> || (
> ( sys-devel/clang:18 sys-devel/llvm:18 )
> ( sys-devel/clang:17 sys-devel/llvm:17 )
> ( sys-devel/clang:16 sys-devel/llvm:16 )
> )
> "
>
> This kinda works, in the sense that it will enforce that you have
> a single matching version of LLVM+Clang, and the eclass will use it.
> However, the := deps on top may be entirely mismatched. For example, if
> you have llvm:18 and clang:17 (+ llvm:17) installed, you'd get:
>
> sys-devel/clang:17=
> sys-devel/llvm:18=
>
> When more packages land on the list, this could lead to quite a mess.
>
> So what'd we go for would effectively be:
>
> DEPEND="
> llvm_target_16? ( sys-devel/clang:16 sys-devel/llvm:16 )
> llvm_target_17? ( sys-devel/clang:17 sys-devel/llvm:17 )
> llvm_target_18? ( sys-devel/clang:18 sys-devel/llvm:18 )
> "
>
> WDYT?
We should mention that https://bugs.gentoo.org/923228 was the motivation
that tipped us over the edge here.
We should also consider the https://bugs.gentoo.org/880671 /
https://bugs.gentoo.org/821955 case, as I think this is going to end up
solving that too, actually.
But yeah, I like it. It solves a request we've had from users for a
while ("let me choose") and it solves these silly dep games.
Thank you!
Re: [gentoo-dev] [PATCH] 2024-02-01-grub-upgrades: add news item
Mike Gilbert writes: > Signed-off-by: Mike Gilbert > --- > .../2024-02-01-grub-upgrades.en.txt | 40 +++ > 1 file changed, 40 insertions(+) > create mode 100644 2024-02-01-grub-upgrades/2024-02-01-grub-upgrades.en.txt > LGTM. > diff --git a/2024-02-01-grub-upgrades/2024-02-01-grub-upgrades.en.txt > b/2024-02-01-grub-upgrades/2024-02-01-grub-upgrades.en.txt > new file mode 100644 > index 000..f7aaa72 > --- /dev/null > +++ b/2024-02-01-grub-upgrades/2024-02-01-grub-upgrades.en.txt > @@ -0,0 +1,40 @@ > +Title: GRUB upgrades > +Author: Mike Gilbert > +Posted: 2024-02-01 > +Revision: 1 > +News-Item-Format: 2.0 > +Display-If-Installed: sys-boot/grub > + > +When booting with GRUB, it is important that the core image and modules > +have matching versions. Usually, running grub-install is sufficient to > +ensure this. > + > +On the UEFI platform, grub-install allows the core image to be placed in > +two different locations: > + > +EFI/gentoo/grubx64.efi > +This is the location used by grub-install without options. > + > +EFI/BOOT/BOOTX64.EFI > +This is the location used by grub-install --removable. > + > +On upgrades, it is common for users to mismatch the grub-install options > +they used for the current and previous versions of grub. This will cause > +a stale core image to exist. For example: > + > +/boot/efi/EFI/BOOT/BOOTX64.EFI (grub 2.06 core image) > +/boot/efi/EFI/gentoo/grubx64.efi (grub 2.12 core image) > +/boot/grub/x86_64-pc/*.mod (grub 2.12 modules) > + > +Booting this system using BOOTX64.EFI image would likely fail due to a > +symbol mismatch between the core image and modules. [1] > + > +Re-runing grub-install both with and without the --removable option > +should ensure a working GRUB installation. > + > +However, this will clobber any BOOTX64.EFI image provded by other > +loaders. If dual-booting using another boot loader, users must take care > +not to replace BOOTX64.EFI if it is not provided by GRUB. > + > +References: > +[1] https://bugs.gentoo.org/920708
Re: [gentoo-dev] Pseudo up-for-grabs: dev-lang/rust, dev-lang/rust-bin, virtual/rust
Randy Barlow writes: > On 1/24/24 23:56, Sam James wrote: >> Please consider stepping forward if you rely on Rust. There's more >> than enough advocates for it, there should be someone who is able >> to then handle the packaging side. > > Is this something I could do as a proxy maintainer? Yes, no problem with that -- but would say that having a co-maintainer (proxied or not) would still be good if you can.
[gentoo-dev] Pseudo up-for-grabs: dev-lang/rust, dev-lang/rust-bin, virtual/rust
Hi all, rust@ is essentially empty as gyakovlev is long-term away and dev-lang/rust, dev-lang/rust-bin, virtual/rust, sys-devel/rust-std, etc all need _at least one_ maintainer. xen0n has been doing some of the bumps but he's only really doing so drive-by (although with best-effort review) and isn't AFAIK interested in maintaining Rust full-time. gyakovlev had some notes at https://wiki.gentoo.org/wiki/User:GYakovlev/Rust_bump on bumping Rust, might be that xen0n can improve that a little bit to improve handover if necessary. Ultimately, Rust needs an active maintainer who is on-top of the ecosystem and able to handle the regular bumps every 6 weeks. We already have a package needing not-in-tree rust-1.75.0 (https://bugs.gentoo.org/922880) which was only released 3-4 weeks ago. Please consider stepping forward if you rely on Rust. There's more than enough advocates for it, there should be someone who is able to then handle the packaging side. thanks, sam
[gentoo-dev] [PATCH] profiles: workaround sandbox bug with getcwd() configure test (gl_cv_func_getcwd_path_max)
Workaround for sandbox bug which causes this gnulib configure test to take many real hours on slower machines, and certainly a huge amount of CPU hours on others. Spoof the same result as configure gets on a modern glibc & musl system for now. Bug: https://bugs.gentoo.org/447970 Closes: https://bugs.gentoo.org/922652 Signed-off-by: Sam James --- profiles/default/linux/make.defaults | 9 - profiles/features/musl/make.defaults | 7 +++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/profiles/default/linux/make.defaults b/profiles/default/linux/make.defaults index 74dd59d5d8179..4e21cd58fdf22 100644 --- a/profiles/default/linux/make.defaults +++ b/profiles/default/linux/make.defaults @@ -1,4 +1,4 @@ -# Copyright 1999-2023 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # # System-wide defaults for the Portage system @@ -54,3 +54,10 @@ LDFLAGS="-Wl,-O1 -Wl,--as-needed" # Prevent automagic use of 64-bit time_t. # https://bugs.gentoo.org/828001 enable_year2038="no" + +# Sam James (2024-01-22) +# Workaround for sandbox bug which causes this gnulib configure test to take +# many real hours on slower machines, and certainly a huge amount of CPU hours +# on others. Spoof the same result as configure gets on a modern glibc system +# for now. See bug #447970 and bug #922652. +gl_cv_func_getcwd_path_max="yes" diff --git a/profiles/features/musl/make.defaults b/profiles/features/musl/make.defaults index 3078bdd61b09c..ca792276e3945 100644 --- a/profiles/features/musl/make.defaults +++ b/profiles/features/musl/make.defaults @@ -17,3 +17,10 @@ FEATURES="-multilib-strict" # that use a charset, it causes package collisons. # Note: we use a full path for locale.alias for bug #799437 INSTALL_MASK="charset.alias /usr/share/locale/locale.alias" + +# Sam James (2024-01-22) +# Workaround for sandbox bug which causes this gnulib configure test to take +# many real hours on slower machines, and certainly a huge amount of CPU hours +# on others. Spoof the same result as configure gets on a modern musl system +# for now. See bug #447970 and bug #922652. +gl_cv_func_getcwd_path_max="no, but it is partly working" -- 2.43.0
Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass
Florian Schmaus writes: > I really like the functionality of readme.gentoo-r1.eclass, as it > allows to communicate Gentoo-specific information about a package to > the user. Especially as it improves the signal-to-noise ratio of > messages arriving to our users. > > However, readme.gentoo-r1.eclass will only show this information on > new installs, but not if the information changed. This is a major > drawback. Furthermore, readme.gentoo-r1.eclass does not provide an API > to assemble the information via heredoc. > > The following patch includes a new eclass named "greadme", that > addresses those shortcomings of readme.gentoo-r1.eclass and hopefully > can be seen as a general overhaul. I have a few concerns at the moment, but of varying severity: 1) The name seems odd (why not readme.gentoo-r2)? 2) Why can't the existing eclass be improved? 3) Is the reason for 2) strong enough to introduce a new eclass? 4) The compression deal seems not worth bothering with. I don't really want to see a bifurcation in our README eclasses if we can help it. Porting to something new takes ages and it's a lot of churn.
Re: [gentoo-dev] Last rites: app-admin/fluentd
Jaco Kroon writes: > Hi, > > On 2024/01/09 13:42, Michał Górny wrote: >> On Tue, 2024-01-09 at 12:54 +0200, Jaco Kroon wrote: >>> https://github.com/gentoo/gentoo/pull/34126 ?? >>> >>> Perhaps I'm missing something if you say it's non-trivial but we're >>> using that on 9 hosts currently. >>> >> Do tests pass for you? https://bugs.gentoo.org/879181#c2 indicated that >> they do not. > > How critical is it that they do? > > Even for the bump PR they do not, they fail with the below, and > frankly my knowledge of ruby is outright scary. The below to me > indicates that the tests are designed specifically to run from a git > checkout, there are two possible "fixes": > > 1. patch the code to not require this. > 2. disable tests. > Test phase: app-admin/fluentd-1.16.3 > * Running test phase for ruby31 > [...] > [...] > :85:in > `require': cannot load such file -- rr (LoadError) Try adding a test dep on dev-ruby/rr. Anyway, if it works for you in production, and you're willing to (reluctantly) adopt it, then we can work on the tests later.
Re: [gentoo-dev] [RFC] New category: dev-debug
Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > On 07/01/2024 13.48, Michał Górny wrote: >> Hi, >> I'd like to propose adding a new dev-debug category. The >> description >> could be: >>Code debuggers and debugging-related tools. > > Seems sensible. I'd probably drop the "Code" from the description, > since packages like d-spy do not primarily debug code. > > I assume profilers are explicitly not part of this category? leio had the same question and we came up with a list of about 5-6 packages at least which would fit in a dev-profile category... > > - Flow >
Re: [gentoo-dev] [RFC] New category: dev-debug
Michał Górny writes: > [[PGP Signed Part:Undecided]] > Hi, > > I'd like to propose adding a new dev-debug category. The description > could be: > > Code debuggers and debugging-related tools. Sounds good. > > Potential candidates include: > > [...] dev-util/seer as well would be a good fit. > > This was originally prompted by bug 920438 [1], pointing out that LLDB > and GDB belong to the same category. dev-util/ currently carries 428 > packages, so I suppose it makes sense to split it some more, especially > when we can clearly distinguish some more specific groups. > Does anything dominate dev-util post-move or is it a real mix? > [1] https://bugs.gentoo.org/920438
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
Ulrich Mueller writes: > [[PGP Signed Part:Undecided]] >> On Tue, 02 Jan 2024, Eli Schwartz wrote: > >> +++ >> b/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt > > The short-name is rather long. GLEP 42 strongly recommends to stay below > 20 characters: > https://www.gentoo.org/glep/glep-0042.html#news-item-identities > >> +Title: Separate /usr now requires an initramfs >> +Author: Eli Schwartz >> +Content-Type: text/plain >> +Posted: 2024-01-02 >> +Revision: 1 >> +News-Item-Format: 2.0 >> +Display-If-Installed: sys-apps/baselayout[split-usr] > > This is not a valid header. (Format 2.0 doesn't have Content-Type.) > >> +In 2013, Gentoo policy determined that separate /usr without an initramfs >> was >> +officially no longer supported: >> + >> +- https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202 >> +- >> https://gitweb.gentoo.org/data/gentoo-news.git/tree/2013/2013-09-27-initramfs-required/2013-09-27-initramfs-required.en.txt?id=a79dd69b0cca439bc0c483c9193c79e0554819d0 > > The 2013-09-27-initramfs-required news item already said: > > | Linux systems which have / and /usr on separate file systems but do not > | use an initramfs will not be supported starting on 01-Nov-2013. > | > | If you have / and /usr on separate file systems and you are not > | currently using an initramfs, you must set one up before this date. > | Otherwise, at some point on or after this date, upgrading packages > | will make your system unbootable. > > It is also in the Handbook since 2014: > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Optional:_Building_an_initramfs > > What has changed that we would need another news item? The fact that we continued to support it means we had various confused users (like in the cited bug 868306). The job was never finished, with usr-ldscript remaining pervasive in the tree, and then it appearing supported - or at least not unsupported. > > Ulrich > > [[End of PGP Signed Part]]
[gentoo-dev] [PATCH 2/2] distutils-r1.eclass: mark DISTUTILS_EXT as @PRE_INHERIT
We set DEPEND and IUSE based on it.
Signed-off-by: Sam James
---
eclass/distutils-r1.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 6d2640b295983..0a9815f2d4591 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -50,6 +50,7 @@ case ${EAPI} in
esac
# @ECLASS_VARIABLE: DISTUTILS_EXT
+# @PRE_INHERIT
# @DEFAULT_UNSET
# @DESCRIPTION:
# Set this variable to a non-null value if the package (possibly
--
2.43.0
[gentoo-dev] [PATCH 1/2] distutils-r1.eclass: workaround cython bug for Modern C
Pass -Wno-error=incompatible-pointer-types for now to avoid many dupes for
the same cython bug.
Bug: https://github.com/cython/cython/issues/2747
Bug: https://bugs.gentoo.org/918983
Bug: https://bugs.gentoo.org/919261
Bug: https://bugs.gentoo.org/919277
Signed-off-by: Sam James
---
eclass/distutils-r1.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 0a7b18e4a1a4f..6d2640b295983 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1806,6 +1806,11 @@ distutils-r1_run_phase() {
tc-export AR CC CPP CXX
if [[ ${DISTUTILS_EXT} ]]; then
+ if [[ ${BDEPEND} == *dev-python/cython* ]] ; then
+ # Workaround for
https://github.com/cython/cython/issues/2747 (bug #918983)
+ local -x CFLAGS="${CFLAGS} $(test-flags-CC
-Wno-error=incompatible-pointer-types)"
+ fi
+
local -x CPPFLAGS="${CPPFLAGS} $(usex debug '-UNDEBUG'
'-DNDEBUG')"
# always generate .c files from .pyx files to ensure we get
latest
# bug fixes from Cython (this works only when setup.py is using
--
2.43.0
Re: [gentoo-dev] Adding Ada support
"Luke A. Guest" writes: > Hi, > > Can we add the following patch to the toolchain.eclass? I want to stop > having to mess with this overlay. The diff can be generated by > grabbing the repo https://github.com/Lucretia/ada-overlay and running > ./scripts/diff_eclass.sh. It'd be useful to send the whole lot with `git send-email` as proper patches which could be `git am`'d. > > The only thing I'm not sure about is the BDEPEND stuff. It looks OK from a glance. > > The reason for doing this is because gnat-gpl is dead, more info can > be found here https://www.adacore.com/community. > > The > https://github.com/Lucretia/ada-overlay/tree/master/dev-lang/ada-bootstrap > ebuilds provide bootstrap compilers, the archives are hosted on > dropbox, from 9.5.0 -> 14. > What is going to be a problem is using these. We'll need to build our own. > The scripts/build-bootstrap.sh script will build a bootstrap for a > particular version based on an env var. > But if this works, I guess that's fine. It would be nice if there were some we could use from elsewhere somewhat-official that other distros are using, but if they don't exist, I guess we have to live with it. We need to do the same for D. > As for anything in dev-ada/* well, the ada guy would need to work on > that really, I'm not really experienced enough to handle it properly. > Kind of curious as to your interest in Ada if you're not experienced enough - not intended derogatorily, just know you've been interested in Ada for a while so I wonder if dev-ada/* is somehow that different or what.. I also wouldn't want to merge something if it's then going to conflict with anything in dev-ada/*, so at least some coordination is required. (To that end, cc'd toolchain@ and ada@.) > Given GCC is masked up to :10 now, the gnat gpr tools / libs might be > easier to get going with single versions covering numerous toolchain > versions. > > Alire would need to be added at some point, http://alire.ada.dev/ to > provide an easier way to get packages going. > > I originally envisioned gnatmake, gprbuild eclasses to cover building > simple projects with one entry point (gnatmake) and projects > (gprbuild). I think an alire based eclass would need to be added as > well. > > Thanks, > Luke. > > [2. text/x-patch; gentoo-diff.patch]...
Re: [gentoo-dev-announce] Re: [gentoo-dev] Last rites: app-text/gocr, media-video/subtitleripper
Jonas Stein writes: >> Sorry, the subject should've included gocr. > >> On Sat, Nov 25, 2023 at 07:12:40AM -0800, John Helmert III wrote: >>> # John Helmert III (2023-11-24) >>> # Multiple vulnerabilities, unmaintained upstream and in Gentoo. >>> # subtitleripper included as sole reverse dependency, similarly >>> # unmaintained, and with no other reverse dependencies. >>> # Removal on 2023-12-24, bug #824290. >>> app-text/gocr >>> media-video/subtitleripper > > > media-gfx/xsane ocr depends on app-text/gocr > > https://gitweb.gentoo.org/repo/gentoo.git/tree/media-gfx/xsane/xsane-0.999-r5.ebuild#n34 ... and media-gfx/xsane[ocr] is masked, so there's no problem.
[gentoo-dev] [PATCH] profiles/features/hardened/amd64: enable USE=pic
There's no real reason not to do this. The status quo is wrong for when we're doing multilib 32-bit builds on x86, and we already have to undo this on musl because its handling for TEXTRELs is limited (see bug #707660). (I noted my intention to do this in 80a72bac2350811712c018b68f61a031736c579f as well.) This seems to have been added originally in e718e1dc1781b3bb5cd80233c217aea3b0e46755 and bb28d08f1cf8cf16f6e57929a8de6b7c85bbe714 (git graft commit). Bug: https://bugs.gentoo.org/707660 Bug: https://bugs.gentoo.org/913412 Signed-off-by: Sam James --- profiles/features/hardened/amd64/make.defaults | 2 +- profiles/features/hardened/amd64/no-multilib/make.defaults | 6 -- 2 files changed, 1 insertion(+), 7 deletions(-) delete mode 100644 profiles/features/hardened/amd64/no-multilib/make.defaults diff --git a/profiles/features/hardened/amd64/make.defaults b/profiles/features/hardened/amd64/make.defaults index e8f0bdf8ba650..89a7242c35648 100644 --- a/profiles/features/hardened/amd64/make.defaults +++ b/profiles/features/hardened/amd64/make.defaults @@ -1,4 +1,4 @@ # Copyright 1999-2023 Gentoo Authors. # Distributed under the terms of the GNU General Public License v2 -USE="cet -pic" +USE="cet" diff --git a/profiles/features/hardened/amd64/no-multilib/make.defaults b/profiles/features/hardened/amd64/no-multilib/make.defaults deleted file mode 100644 index 1dd0a2a0f7e0d..0 --- a/profiles/features/hardened/amd64/no-multilib/make.defaults +++ /dev/null @@ -1,6 +0,0 @@ -# Copyright 1999-2011 Gentoo Foundation -# Distributed under the terms of the GNU General Public License v2 - -# We don't need to have pic on -USE="-pic" - -- 2.43.0
Re: [gentoo-dev] [PATCH v2] acct-user.eclass: Warn when the user is removed from a group
Ulrich Müller writes:
> Acked-by: Mike Gilbert
> Signed-off-by: Ulrich Müller
> ---
> v2: Add explanation and documentation reference to warning message
lgtm
>
> eclass/acct-user.eclass | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index f658aa0eabc3..c9d335c4e558 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -431,6 +431,20 @@ acct-user_pkg_postinst() {
> opts+=( --prefix "${ROOT}" )
> fi
>
> + local g old_groups del_groups=""
> + old_groups=$(egetgroups "${ACCT_USER_NAME}")
> + for g in ${old_groups//,/ }; do
> + has "${g}" "${groups[@]}" || del_groups+="${del_groups:+, }${g}"
> + done
> + if [[ -n ${del_groups} ]]; then
> + ewarn "Removing user ${ACCT_USER_NAME} from group(s):
> ${del_groups}"
> + ewarn "To retain the user's group membership in the local
> system"
> + ewarn "config, override with
> ACCT_USER_${ACCT_USER_NAME^^}_GROUPS"
> + ewarn "or ACCT_USER_${ACCT_USER_NAME^^}_GROUPS_ADD in
> make.conf."
> + ewarn "Documentation reference:"
> + ewarn
> "https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration#Override_user_groups;
> + fi
> +
> elog "Updating user ${ACCT_USER_NAME}"
> # usermod outputs a warning if unlocking the account would result in an
> # empty password. Hide stderr in a text file and display it if usermod
> fails.
Re: [gentoo-dev] [PATCH] eclass/go-env.eclass: add helper to set compile env
James Le Cuirot writes:
> From: Thilo Fromm
>
> This change adds a helper function to explicitly set CC, CXX, and
> GOARCH, and carrying over CFLAGS, LDFLAGS and friends to CGO
> equivalents, to provide a minimal sane compile environment for Go.
> It enables Go builds to play nice with crossdev's wrappers for
> emerge/ebuild etc. Previously, Go ebuilds emitted binaries for the host
> architecture.
>
> For example, when running on an x86_64 host:
>emerge-aarch64-cross-linux-gnu foo
> will now correctly emerge Go package "foo" for aarch64 instead of
> x86_64.
>
> The eclass provides a single helper function
> go-env_set_compile_environment()
> intended to be called by other Go eclasses in an early build stage.
> Ebuilds may also explicitly call this function.
>
> Calls to this function from _src_prepare in go-module.eclass,
> golang-vcs-snapshot.eclass, and golang-vcs.eclass have also been added
> to un-break cross-compilation of existing Go packages.
Overall looks good. Please split into several commits (one for the new
eclass, then one per eclass to wire it up).
Respecting flags properly for CGO stuff has been overdue anyway.
CCing William too.
>
> Signed-off-by: Thilo Fromm
> Closes: https://github.com/gentoo/gentoo/pull/33539
> Signed-off-by: James Le Cuirot
> ---
> eclass/go-env.eclass | 48 +++
> eclass/go-module.eclass | 5 +++-
> eclass/golang-vcs-snapshot.eclass | 5 +++-
> eclass/golang-vcs.eclass | 5 +++-
> 4 files changed, 60 insertions(+), 3 deletions(-)
> create mode 100644 eclass/go-env.eclass
>
> See the GitHub link for earlier discussion. This still doesn't work for
> cross-prefix
> builds, unless you set CGO_ENABLED=1, but fixing that involves different code
> and can
> be done later.
>
> diff --git a/eclass/go-env.eclass b/eclass/go-env.eclass
> new file mode 100644
> index ..0b4d44658a07
> --- /dev/null
> +++ b/eclass/go-env.eclass
> @@ -0,0 +1,48 @@
> +# Copyright 2023 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: go-env.eclass
> +# @MAINTAINER:
> +# Flatcar Maintainers
> +# @AUTHOR:
> +# Flatcar Maintainers
Does this have a Bugzilla account we can CC on bugs? If not, let's pick
a different @MAINTAINER entry. @AUTHOR doesn't need to change.
> +# @BLURB: Helper eclass for setting the Go compile environment. Required for
> cross-compiling.
> +# @DESCRIPTION:
> +# This eclass includes a helper function for setting the compile environment
> for Go ebuilds.
> +# Intended to be called by other Go eclasses in an early build stage, e.g.
> src_unpack.
> +
> +if [[ -z ${_GO_ENV_ECLASS} ]]; then
> +_GO_ENV_ECLASS=1
> +
> +inherit toolchain-funcs
> +
> +# @FUNCTION: go-env_set_compile_environment
> +# @DESCRIPTION:
> +# Set up basic compile environment: CC, CXX, and GOARCH.
> +# Also carry over CFLAGS, LDFLAGS and friends.
> +# Required for cross-compiling with crossdev.
> +# If not set, host defaults will be used and the resulting binaries are host
> arch.
> +# (e.g. "emerge-aarch64-cross-linux-gnu foo" run on x86_64 will emerge "foo"
> for x86_64
> +# instead of aarch64)
> +go-env_set_compile_environment() {
> + local arch=$(tc-arch "${CHOST}}")
> + case "${arch}" in
> + x86)GOARCH="386" ;;
> + x64-*) GOARCH="amd64" ;;
> + ppc64) if [[ "$(tc-endian "${${CHOST}}")" = "big" ]] ; then
== please, as we're in bash
> + GOARCH="ppc64"
> + else
> + GOARCH="ppc64le"
> + fi ;;
> + *) GOARCH="${arch}" ;;
> + esac
> +
> + tc-export CC CXX
> + export GOARCH
> + export CGO_CFLAGS="${CGO_CFLAGS:-$CFLAGS}"
> + export CGO_CPPFLAGS="${CGO_CPPFLAGS:-$CPPFLAGS}"
> + export CGO_CXXFLAGS="${CGO_CXXFLAGS:-$CXXFLAGS}"
> + export CGO_LDFLAGS="${CGO_LDFLAGS:-$LDFLAGS}"
> +}
> +
> +fi
> diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> index 6c58d7f26f07..701d36e012e2 100644
> --- a/eclass/go-module.eclass
> +++ b/eclass/go-module.eclass
> @@ -68,7 +68,7 @@ esac
> if [[ -z ${_GO_MODULE_ECLASS} ]]; then
> _GO_MODULE_ECLASS=1
>
> -inherit multiprocessing toolchain-funcs
> +inherit multiprocessing toolchain-funcs go-env
>
> if [[ ! ${GO_OPTIONAL} ]]; then
> BDEPEND=">=dev-lang/go-1.18"
> @@ -363,6 +363,7 @@ go-module_setup_proxy() {
> #local go proxy. This mode is deprecated.
> # 2. Otherwise, if EGO_VENDOR is set, bail out, as this functionality was
> removed.
> # 3. Otherwise, call 'ego mod verify' and then do a normal unpack.
> +# Set compile env via go-env.
> go-module_src_unpack() {
> if use amd64 || use arm || use arm64 ||
> ( use ppc64 && [[ $(tc-endian) == "little" ]] ) || use s390 ||
> use x86; then
> @@ -386,6 +387,8 @@ go-module_src_unpack() {
>
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Add functions to get pointer size in bytes
James Le Cuirot writes:
> tc-get-ptr-size for CHOST and tc-get-build-ptr-size for CBUILD.
>
> Closes: https://bugs.gentoo.org/328401
> Signed-off-by: James Le Cuirot
> ---
lgtm
> eclass/toolchain-funcs.eclass | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index 8fef764ad597..5da93063866b 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -1216,4 +1216,18 @@ tc-get-c-rtlib() {
> return 0
> }
>
> +# @FUNCTION: tc-get-ptr-size
> +# @RETURN: Size of a pointer in bytes for CHOST (e.g. 4 or 8).
> +tc-get-ptr-size() {
> + $(tc-getCPP) -P - <<< __SIZEOF_POINTER__ ||
> + die "Could not determine CHOST pointer size"
> +}
> +
> +# @FUNCTION: tc-get-build-ptr-size
> +# @RETURN: Size of a pointer in bytes for CBUILD (e.g. 4 or 8).
> +tc-get-build-ptr-size() {
> + $(tc-getBUILD_CPP) -P - <<< __SIZEOF_POINTER__ ||
> + die "Could not determine CBUILD pointer size"
> +}
> +
> fi
Re: [gentoo-dev] Package up for grabs: dev-util/cvise
Michał Górny writes: > [[PGP Signed Part:Undecided]] > Hello, > > dev-util/cvise is now looking for a new maintainer. > > It is fairly low maintenance package. It's in need of a version bump > right now, as well as testing with llvm:17 and python:3.12 (both seem to > work fine). > > The main problem with it is that it happens to hit some bugs in sys- > devel/clang[debug] that cause crashes, and I don't really have the > resources to rebuild sys-devel/clang just to test this one package. > Note that these are actually upstream bugs of clang and not cvise. They > haven't been fixed for years because big tech just doesn't care that > clang sometimes crashes on random code. Adopted for toolchain@ as it's pretty essential for us. Co-maintainers very welcome. thanks, sam
Re: [gentoo-dev] Re: Last rites: media-gfx/gmic
Zoltan Puskas writes: > [[PGP Signed Part:Undecided]] > On Fri, Oct 27, 2023 at 12:24:32PM +0100, Marek Szuba wrote: >> On 2023-10-26 02:29, Jonas Stein wrote: >> >> > this is a very powerful package with many users. >> >> ...but sadly, very few maintainers. It was m-n when I took it over 3 years >> ago, as apparently no-one found it worth looking after following the >> disbanding of the Graphics project - and that was back when upstream still >> used CMake! Telling the truth I wasn't exactly interested either, it's just >> that it happened to be an optional dependency of media-gfx/darktable. >> >> > Thank you for maintaining it till now. >> >> You're very welcome! >> >> > Could you address the exact problems to upstream, so they are aware and >> > can improve it? >> > I think not only Gentoo, but also other distributions suffer if it does >> > not build smooth. >> >> I used to do that. It seemed to have little to no effect so in the end I >> just gave up. >> >> > Looks to me as if the package is not broken now, but there is a lack of >> > manpower to update it. 30 days is the minimum for a removal. >> >> There are two outstanding QA issues (ignored LDFLAGS and pre-stripped >> binaries) in 3.3.1 pertaining to USE=gimp and USE=qt5. Prior to adding that >> version I tried to leverage qmake-utils.eclass in the Qt parts of the >> package, which hopefully would have got rid of these issues - but resulted >> in a wall of actual errors. This has been the last straw as far as me >> maintaining G'MIC is concerned. >> >> > I suggest to keep it for a few more months. >> >> Fine by me if someone actually maintains it. I've just dropped >> media-gfx/gmic back to m-n to make it clear that I do not intend to block it >> from being reactivated. >> >> -- >> Marecki >> > > This is quite a loss. Ever since the dropping the gimp-resynthesizer plugin > (due > to Python2 deprecation) gmic was the last package to provide "heal selection" > functionality in GIMP. Losing gmic will put GIMP behind other image editing > software by a significant margin. > > I'm wondering if we could collaborate with other distro developers on building > and improving the state of this package. E.g. Debian seems to be packaging > gmic > by itself and also for gimp and krita. I wonder if it's possible to build the > gimp plugin portion only and not deal with gmic QT frontend? https://github.com/GreycLab/gmic/issues/17 indicates upstream are open to PRs at least. > > Zoltan > > [[End of PGP Signed Part]]
[gentoo-dev] Last rites: dev-perl/PathTools
# Sam James (2023-10-16) # Part of Perl core and better maintained there - the version on CPAN is out of # date and incompatible with Perl 5.38. No reverse dependencies. # Removal on 2023-11-15. dev-perl/PathTools
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Make use of gpep517's new build-wheel --prefix arg
James Le Cuirot writes:
> This fixes cross-prefix installations.
Do we need to crank the minimum version we depend on for gpep517 then?
>
> Signed-off-by: James Le Cuirot
> ---
> eclass/distutils-r1.eclass | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 56afcdc5bcb8..838162c6b0f8 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -1444,6 +1444,7 @@ distutils_pep517_install() {
> einfo " Building the wheel for ${PWD#${WORKDIR}/} via ${build_backend}"
> local cmd=(
> gpep517 build-wheel
> + --prefix="${EPREFIX}/usr"
> --backend "${build_backend}"
> --output-fd 3
> --wheel-dir "${WHEEL_BUILD_DIR}"
Re: [gentoo-dev] Proposal for a Universal Remote-ID File
Michael Orlitzky writes: > On Sat, 2023-09-23 at 00:10 +0530, Siddhanth Rathod wrote: >> >> 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? > > Building the wiki page isn't too hard, but what's the plan to propagate > changes into those seven other repositories? If we're still > copy/pasting the output of some tool, then we haven't really saved a > step, we've only changed what we're copy/pasting. At the moment, we bundle the DTD in pkgcore. If we just shoved it in metadata/ instead in the main repo, we don't have that kind of problem.
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.
