Re: [gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install)
On 6/4/24 2:28 PM, Florian Schmaus wrote: > And yes, "docompress -x README.gentoo" would make the code mch > simpler. And, as additional benefit, would help us get rid of storing > the whole content of the readme in a environment variable (which is what > readme.gentoo-r1.elcass currently does). Hence this is what was > previously suggested, until people complained about it. > > It seems like we are going in circles… :( I think it would be fantastic if we could drop the crude workaround of adding the text of the readme.gentoo file into environment to sidestep the fact that the original design was buggy and stored it as an optional documentation file vulnerable to corruption as a side effect of default `docompress` handling, when its purpose was to be a pkg_postinst metadata file. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 3/3] dev-db/postgresql: pass in a ninja-compatible value to meson_src_compile
Signed-off-by: Eli Schwartz
---
dev-db/postgresql/postgresql-.ebuild | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dev-db/postgresql/postgresql-.ebuild
b/dev-db/postgresql/postgresql-.ebuild
index e5eaa285027b..3f53c730579f 100644
--- a/dev-db/postgresql/postgresql-.ebuild
+++ b/dev-db/postgresql/postgresql-.ebuild
@@ -199,7 +199,7 @@ src_compile() {
# Generates both manpages and HTML documentation.
meson_src_compile docs
else
- meson_src_compile man:alias
+ meson_src_compile man
fi
}
--
2.44.2
[gentoo-dev] [PATCH 2/3] sys-apps/systemd-utils: pass in a ninja-compatible value to meson_src_compile
It is an alias_target so "libudev" is anyways the correct way to do it.
Signed-off-by: Eli Schwartz
---
sys-apps/systemd-utils/systemd-utils-254.10-r1.ebuild | 2 +-
sys-apps/systemd-utils/systemd-utils-254.12.ebuild| 2 +-
sys-apps/systemd-utils/systemd-utils-254.13.ebuild| 2 +-
sys-apps/systemd-utils/systemd-utils-255.4.ebuild | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/sys-apps/systemd-utils/systemd-utils-254.10-r1.ebuild
b/sys-apps/systemd-utils/systemd-utils-254.10-r1.ebuild
index ca3697269cd2..b906b6110034 100644
--- a/sys-apps/systemd-utils/systemd-utils-254.10-r1.ebuild
+++ b/sys-apps/systemd-utils/systemd-utils-254.10-r1.ebuild
@@ -375,7 +375,7 @@ multilib_src_compile() {
fi
if use udev; then
targets+=(
- udev:shared_library
+ libudev
src/libudev/libudev.pc
)
if use test; then
diff --git a/sys-apps/systemd-utils/systemd-utils-254.12.ebuild
b/sys-apps/systemd-utils/systemd-utils-254.12.ebuild
index 9ba529076182..4e14021f3732 100644
--- a/sys-apps/systemd-utils/systemd-utils-254.12.ebuild
+++ b/sys-apps/systemd-utils/systemd-utils-254.12.ebuild
@@ -375,7 +375,7 @@ multilib_src_compile() {
fi
if use udev; then
targets+=(
- udev:shared_library
+ libudev
src/libudev/libudev.pc
)
if use test; then
diff --git a/sys-apps/systemd-utils/systemd-utils-254.13.ebuild
b/sys-apps/systemd-utils/systemd-utils-254.13.ebuild
index 9ba529076182..4e14021f3732 100644
--- a/sys-apps/systemd-utils/systemd-utils-254.13.ebuild
+++ b/sys-apps/systemd-utils/systemd-utils-254.13.ebuild
@@ -375,7 +375,7 @@ multilib_src_compile() {
fi
if use udev; then
targets+=(
- udev:shared_library
+ libudev
src/libudev/libudev.pc
)
if use test; then
diff --git a/sys-apps/systemd-utils/systemd-utils-255.4.ebuild
b/sys-apps/systemd-utils/systemd-utils-255.4.ebuild
index 4c64afbd80c1..ea1032f738dc 100644
--- a/sys-apps/systemd-utils/systemd-utils-255.4.ebuild
+++ b/sys-apps/systemd-utils/systemd-utils-255.4.ebuild
@@ -384,7 +384,7 @@ multilib_src_compile() {
fi
if use udev; then
targets+=(
- udev:shared_library
+ libudev
src/libudev/libudev.pc
)
if use test; then
--
2.44.2
[gentoo-dev] [PATCH 1/3] net-libs/libsrtp: pass in a ninja-compatible value to meson_src_compile
Signed-off-by: Eli Schwartz
---
net-libs/libsrtp/libsrtp-2.4.2.ebuild | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net-libs/libsrtp/libsrtp-2.4.2.ebuild
b/net-libs/libsrtp/libsrtp-2.4.2.ebuild
index 96e02837fcf2..1aaaf742a61f 100644
--- a/net-libs/libsrtp/libsrtp-2.4.2.ebuild
+++ b/net-libs/libsrtp/libsrtp-2.4.2.ebuild
@@ -55,7 +55,7 @@ multilib_src_configure() {
multilib_src_compile() {
meson_src_compile
if multilib_is_native_abi && use doc; then
- meson_src_compile doc
+ meson_src_compile doc/html
fi
}
--
2.44.2
[gentoo-dev] [PATCH 0/3] meson.eclass: corresponding updates to ebuilds
Eli Schwartz (3): net-libs/libsrtp: pass in a ninja-compatible value to meson_src_compile sys-apps/systemd-utils: pass in a ninja-compatible value to meson_src_compile dev-db/postgresql: pass in a ninja-compatible value to meson_src_compile dev-db/postgresql/postgresql-.ebuild | 2 +- net-libs/libsrtp/libsrtp-2.4.2.ebuild | 2 +- sys-apps/systemd-utils/systemd-utils-254.10-r1.ebuild | 2 +- sys-apps/systemd-utils/systemd-utils-254.12.ebuild| 2 +- sys-apps/systemd-utils/systemd-utils-254.13.ebuild| 2 +- sys-apps/systemd-utils/systemd-utils-255.4.ebuild | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) -- 2.44.2
[gentoo-dev] [PATCH] meson.eclass: stop using the incomparably broken "meson compile"
With my upstream meson hat on, I have griped about this for years any
time someone mentions "meson compile" to me. I think it was badly
motivated and shouldn't exist.
The purpose of this command is "for symmetry" with meson setup and meson
test and meson install, even though all of those are python programs
first and foremost, which have ninja targets that simply call back into
the meson tool but with less control.
Symmetry doesn't make a whole lot of sense. The compile phase actually
is implemented as a... ninja file, not a python program. Using ninja
directly is:
- faster, since you don't load hundreds of python modules into memory,
just to fork out to ninja
- easier to control, since you can directly control the ninja arguments
The "meson compile" program actually, in fact, only really exists for
two reasons:
- meson supports multiple backends -- only when manually requested -- on
operating systems other than linux. Namely, VS on Windows, and xcode
on macOS. The wrapper first checks which backend has been generated,
and then runs the appropriate command there. It also provides the
ninja argument syntax for options that multiple backends understand,
so, you can pass -v -j8 and it actually works regardless of backend
(even if in fact it has to pass `-verbosity:minimal -maxCpuCount:8` to
do it).
- via retconning, on Windows when using the MSVC `cl.exe` meson compile
started actually adding this to PATH and setting it up (because it
requires sourcing a batch script in order to both add to PATH and set
inscrutable mandatory environment variables) to prevent ninja utterly
failing if you missed this yourself.
For portage purposes, neither of these matter whatsoever. Even if
portage were to ever use cl.exe on Windows (???) it could set up the
environment just fine on its own, and actually using alternative
backends would require extending the eclass to configure xcode/vs for
tremendous slowdown in compile time, which would be silly.
In exchange for all these features portage doesn't need, what do we get?
meson compile unabashedly doesn't support all possible ninja arguments,
and says you should instead pass the combination of --ninja-args "..."
--vs-args "..." --xcode-args "..." and it will figure out which ones are
relevant for *your* backend and forward it to the backend. We don't
actually do that -- it would be super ugly for the common case of -v
-j8.
As a result, we ignore $NINJAOPTS, which ninja-utils.eclass claims we
are allowed to use. Instead we manually parse out some subset of
"supported" values. We *cannot* respect NINJAOPTS anyways, because...
... meson compile sucks and cannot handle it. To be more accurate: it
expects --ninja-args to be formatted using `meson-format-array`, the
same format that machine files use. No thank you!
And we still have to move to get_NINJAOPTS, then pass it as:
```
meson compile -C "${BUILD_DIR}" --ninja-args="['-j', '8', '-k', '0', '-v',
'-l', '0']"
```
instead of:
```
meson compile -C "${BUILD_DIR}" -j 8 -v -l 0 --ninja-args="['-k0']"
```
The overengineered complexity of this is immense. ninja-utils.eclass
exists for an extremely good reason, provides best practices, and means
we don't have to maintain an interface to a custom tool with unintuitive
behavior since we get precisely the common functionality we already
want, for free.
Just use eninja.
Fixes:
- the absolute inability to use standard $NINJAOPTS to fine-tune
meson-using packages, for example to keep going and collect all the
build errors before aborting with a failure.
- support for ${NINJA_VERBOSE} (expected to be the fallback if
MESON_VERBOSE isn't set)
Signed-off-by: Eli Schwartz
---
eclass/meson.eclass | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index a22a85887584..a2bc5537e458 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -440,23 +440,11 @@ meson_src_compile() {
pushd "${BUILD_DIR}" > /dev/null || die
- local mesoncompileargs=(
- --jobs "$(get_makeopts_jobs 0)"
- --load-average "$(get_makeopts_loadavg 0)"
- )
-
case ${MESON_VERBOSE} in
- OFF) ;;
- *) mesoncompileargs+=( --verbose ) ;;
+ OFF) NINJA_VERBOSE=OFF eninja "$@" ;;
+ *) eninja "$@" ;;
esac
-
- mesoncompileargs+=( "$@" )
-
- set -- meson compile "${mesoncompileargs[@]}"
- echo "$@" >&2
- "$@"
local rv=$?
- [[ ${rv} -eq 0 ]] || die -n "compile failed"
popd > /dev/null || die
return ${rv}
--
2.44.2
Re: [gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install)
On 6/2/24 12:28 PM, Ulrich Mueller wrote: >>>>>> On Sun, 02 Jun 2024, Eli Schwartz wrote: > >> Per the commit message, the old readme and the new readme can have the >> same contents, but be compressed by different compressors on the live >> system vs the image, and/or a compressor with unstable algorithms, >> and/or one that isn't installed at the time of merging. > >> Given you've explicitly rejected disabling compression, I don't quite >> see how you can have your cake and eat it too. > > How is installing another file (4 KiB on many file systems) an > improvement over disabling compression for README.gentoo itself? I didn't say it was. The improvement is to disable compression for README.gentoo itself. *You* are the one insisting on another approach. Remember the original argument against disabling compression: """ > Then why does "docompress -x" exist at all? Short answer, because some upstream programs access these directories and cannot cope with compressed files there. """ readme.gentoo-r1.eclass as proposed in this thread is exactly such an upstream program (gentoo is the upstream, and gentoo cannot cope with compressed files there). It strikes me as rules lawyering to use this as an argument against the eclass, but whatever. The alternative to `docompress -x` is to *not have to decompress* when comparing the compressed contents of two files, which means recording persistent state. There is one approach that I can think of for this: - recording state in a second file (additional to README.gentoo itself) If you dislike this solution, and are unwilling to back down on "docompress -x", then my personal feeling is that it is *your* responsibility to come up with an alternative mechanism for implementing the functionality. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/4] readme.gentoo-r1.eclass: display readme if content changed (or fresh install)
On 6/2/24 11:34 AM, Ulrich Mueller wrote:
>>>>>> On Sun, 02 Jun 2024, Florian Schmaus wrote:
>
>> +(
>> +insinto "${_GREADME_DOC_DIR}"
>> +
>> +doins "${_GREADME_TMP_FILE}"
>> +cksum --raw "${_GREADME_TMP_FILE}" | newins -
>> "${_GREADME_HASH_FILENAME}"
>> +assert
>> +)
>
> Why do you need that hash file? The old README file exists on the
> system, so couldn't you just compare the new one with it?
Per the commit message, the old readme and the new readme can have the
same contents, but be compressed by different compressors on the live
system vs the image, and/or a compressor with unstable algorithms,
and/or one that isn't installed at the time of merging.
Given you've explicitly rejected disabling compression, I don't quite
see how you can have your cake and eat it too.
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Proxy-maint PR queue resolution speed (Was: Imminent Python 3.12 switch reminder)
On 5/30/24 11:09 AM, orbea wrote: > This is a reoccurring theme and its driving away contributors. The PR > queue really should be taken care of. It is a recurring theme in the volunteer open source community that people work on stuff as and when they have time to do so, which also means that contributors sometimes have to wait until people are available to merge PRs. There are some things that can help make sure people have more time to volunteer for free to do OSS things: - carefully consider before adding new packages. Maybe they belong in GURU instead? This is something a lot of people have trouble with, I fear. - review PRs, even if you're not a developer, to help polish things up so there is less for developers to have to sort through. - help out in other areas of Gentoo, such as bug wrangling, release engineering, or fixing outstanding bugs in packages maintained by developers rather than their own proxy-maint packages - or even just being a sympathetic and friendly ear when developers are feeling down from the stress of doing open source work There are also some things that I personally do not think are especially helpful: - complaining that the community is being driven away - responding to community members adding a *friendly* and cheerful comment by pearl clutching about how the community is being driven away - engaging in a multi-year campaign to pressure open source developers into feeling guilty about not spending "enough" time, culminating in getting maintainer access to an xkcd 2347 "Nebraska" compliant project for purposes of inserting a backdoor - unwittingly being a member of a grassroots support base for the Jia Tans of the world by normalizing the relevant behavior -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Files for doc building
On 5/21/24 4:10 PM, Henri Gasc wrote: > Hello, > > I am in the process of updating dev-python/mkdocs-rss-plugin (in GURU), > and I find myself in a pinch. > To build the documentation, there are 74 files needed. It's too much to > add them to the SRC_URI and copy the files in src_prepare, but at the > same time, the best compression achieved on a tar archive is 3.3M and I > worry about putting it in a files directory. > > Does anyone has an idea on how to solve this ? I would prefer not to > create a git repo and add it from there. > Regards, > Henri Gasc It is even a violation of Gentoo policy to have files larger than IIRC 20kb in files/. This *must* be handled via SRC_URI, where to host the tarball is up to the maintainer. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] [QA] allow overriding settings
On 5/5/24 11:48 AM, Paul Zander wrote: > Signed-off-by: Paul Zander > --- > .editorconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/.editorconfig b/.editorconfig > index f2cd7328e57..dc1d5587a8b 100644 > --- a/.editorconfig > +++ b/.editorconfig > @@ -2,7 +2,6 @@ > # Distributed under the terms of the GNU General Public License v2 > > # https://editorconfig.org/ > -root = true Can you explain the goal of this better? Removing this setting tells editorconfig that the gentoo.git repo is a subdirectory of a wider project scope, and that it should check e.g. /var/db/repos/.editorconfig and /var/db/.editorconfig and /var/.editorconfig as well -- and in the event of two files trying to set the same editorconfig setting, the file you're editing in this patch wins. So this will not actually allow one to override settings, for two reasons: - it imposes an awkward UX requirement that the way to override settings is to move your gentoo.git clone into a subdirectory of a dedicated directory existing solely to provide its own .editorconfig file along with the gentoo/ (clone) directory - it does exactly the opposite of overriding settings, because it allows you to set non-overriding defaults and it also requires editorconfig tooling to walk every directory upward until it reaches the / directory to check for more files, which is a pointless waste. The editorconfig standard *specifically* expects you to set root=true at the top level scope of your project, and this patch is in opposition to the recommended workflow. What workflow are you envisioning people will use if this patch is merged? -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] [QA] drop indent_size
On 5/5/24 11:50 AM, Paul Zander wrote: > indent_size is the width in spaces, we use tabs. > tab_width would be the tab width in spaces, but there is no reason to force > this. > > Signed-off-by: Paul Zander > --- > .editorconfig | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/.editorconfig b/.editorconfig > index dc1d5587a8b..04a69b17304 100644 > --- a/.editorconfig > +++ b/.editorconfig > @@ -8,9 +8,8 @@ charset = utf-8 > end_of_line = lf > insert_final_newline = true > indent_style = tab > -indent_size = 4 > trim_trailing_whitespace = true > -#max_line_length = 80 > +# max_line_length = 80 Commit message is silent on this line, which isn't about dropping indent size but rather about reformatting the comments for the editorconfig file itself... -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo identification in Primary Volume Descriptor of ISOs
On 5/3/24 4:43 AM, Michal Prívozník wrote: > Awesome! Thank you. > > And speaking of things that slip our attention. When trying to get a > link to this e-mail thread I've noticed at least gentoo-dev archives on > archives.gentoo.org are stuck in 2023: > > https://archives.gentoo.org/gentoo-dev/ > > I'm not sure where to report this, so I'm hoping this will find the > right recipient. Thanks once again. Unfortunate but known issue: https://bugs.gentoo.org/903753 There's an experimental public-inbox instance at https://public-inbox.gentoo.org/gentoo-dev/ with just the one mailing list for now. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] .github: Add pull request template
On 5/1/24 11:02 AM, Maciej Barć wrote: > Well, not really, there were many cases where pkg was broken on sandbox! > The latest example would be nim (before I updated it myself) where > contributor submitted broken pkg without telling anybody. It was a WIP > PR but nowhere they specified that it did not merge under sandbox. I > want to encourage contributors to outright say when they know/think > something might be wrong with package. And adding another checkbox is going to stop people from submitting WIP draft PRs without marking them as drafts? Maybe the solution here is that developers who merge patches from contributors should test the PR before merging. At least if you don't have a preexisting relationship with the contributor such that you have trust in the contributor to publish high quality ebuilds that pass basic smoketests. I mean, you probably want to do that anyway because if someone shows up with their first ever PR and the change looks okay but has a broken checksum it is awfully hard to tell without actually running it. I certainly hope that if PRs are merged without being tested locally by the developer doing the merge, that it's for proxied packages contributed by the proxied maintainer, not packages where the Developer that maintains the package is merging untested patches just because someone suggested a change. And if proxied maintainers make a habit of breaking their packages by submitting WIP drafts maybe they aren't such great proxied maintainers and there's a larger infrastructural problem going on. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: make qa warning conditional
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. 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". -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] .github: Add pull request template
On 5/1/24 10:38 AM, Maciej Barć wrote: > Ionen, I think that regular contributors could skip this altogether. For > example the person I'm mentoring I am sure would follow all requirements > listed by mgorny and me (see my reply). Regular contributors might not even be submitting via PRs at all. :P >> On a side-note, I have nothing against having .github in the tree. Just >> saying given I know not everyone is happy with that. > > I think we should push more into "conforming" to standard of online > software forges. Reminder that we STILL do not have any form of a README > file. Not even one that would say "Hey look at https://gentoo.org/;. > Also no license link. Afaik all contribs are under GPL-2. Every file has a copyright header: # Distributed under the terms of the GNU General Public License v2 It's not clear to me what more you want than this, or who it would help. A README could be useful to github I guess, but on the other hand the main purpose of a README is to tell people who don't know what a repository is for, what that repository is for. Would it basically duplicate the contents of https://wiki.gentoo.org/wiki/Ebuild_repository or is there something else you want to see in a README? I don't think "Hey look at https://gentoo.org; is remotely useful as a README, compared to what is already there: [MIRROR] Official Gentoo ebuild repository https://gitweb.gentoo.org/repo/gentoo.git which is already quite explanatory in ways that a noncommittal link to the gentoo homepage is NOT. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] .github: Add pull request template
On 5/1/24 10:27 AM, Maciej Barć wrote: > Maybe we could consider also adding something along the lines (4 > additional positions): > > 1. I have emerged the package(s) on a Gentoo-based system (be it > "native" or virtualized by means of hardware-based virtualization or > system layer virtualization). > 2. I have tested that the package(s) merge inside both the user and net > sandbox without violations on a Gentoo-based system. > 3. I can assure that the packages would be able to be merged on the > currently default Gentoo profile (with or without modifications to USE > flags). > 4. If manual intervention (beyond "emerge PKG") is required ro complete > the install/update of the package(s) I have explained the steps needed > to be taken in the PR and/or package ebuild(s) and/or Gentoo Wiki. It's not obvious to me these are necessary since the entire concept behind submitting an ebuild update is to, well, install and use it. My base assumption is that users submitting such an update have done so because it solved a problem for them. This covers 1, 2, and 3, unless the user has done some fairly heavily nonstandard things or submits effectively untested spam which admittedly might happen -- but the checkboxes don't seem the easiest way to solve this. 4 seems semantically wrong since it's not the job of a PR to describe what users should do to manually intervene to install a package, but IMHO this is already covered by 3. The only interesting case I can actually think of is where updating a package requires some sort of e.g. database migration to run after updating and before the next use -- this is the minority of packages and should be handled by a postinst message, but could also be reviewed on a case by case basis... It is *not* the job of a packager to ensure that the gentoo wiki excellently describes how to use the software, as that's a different skillset. I wouldn't want to discourage users from contributing code because they aren't skilled documentarians. The existing pull request template suggestion proposes to add checkboxes for 3 types of requirements that aren't necessarily obvious to users who had a problem, fixed it, and want to share the fix -- they are all about complying with Gentoo policy. Your 4 suggestions are all about requirements for fixing a problem and successfully fixing it even as a local ebuild. We don't need to remind people that the PR has to actually fix the problem. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
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. :) Replacing implementations has several great uses. There's some prior art in make.conf, but it doesn't go far enough: PORTAGE_BZIP2_COMMAND BINPKG_COMPRESS BINPKG_COMPRESS_FLAGS Disregarding the security component entirely, one might wish to use pixz or pigz instead of the default programs. Why not 7zip as well? In terms of security, this suggests an easy and simple way both to allow users to depclean xz-utils without sacrificing the ability to install packages using *.tar.xz sources, and for Gentoo to roll out an update that would do this distribution-wide if necessary via a trivial configuration change. https://dev.gentoo.org/~ulm/pms/head/pms.html#section-12.3.15 may need updating to allow this. But it seems very valid to propose doing exactly that. I am not sure why it specifies e.g. "must ensure that GNU gzip" with heavy ties to implementations, when it doesn't specify such for compression. I'm guessing what you did was override/hook the unpack phase helper function and divert it to 7zip instead. ;) It would be interesting to have actual hooks for that instead. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
o to solve the problem. Your suggestion is only one such badly thought out idea. However, it stands out from the rest because your suggestion has something that the rest by and large lack: it has an accusation that distros, in this case Gentoo, are being cavalier about security. This attitude of "Gentoo is being cavalier about security" is disproportionately worse than the average user interaction and, as has been noted, is the reason why FOSS maintainers suffer burnout. It has nothing to do with bringing up concerns. It has everything to do with "if you don't agree with me you're being cavalier about MY security as a Gentoo user". Seriously. Please learn to bring up suggestions as suggestions, not as demands. It makes all the difference in the world. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 4/1/24 3:57 AM, Eddie Chapman wrote: > No, I don't need to do that. I don't appreciate suggestions to "just calm > down", especially when I'm not being hysterical. Your comment to me just > reinforces what I mean when I say there is far too much of a cavalier > attitude. I think you're making a big mistake by confusing "approach the issue with a calm and clearheaded approach, be methodical about how you analyze and react to trouble spots" with "everyone is being cavalier". But also, please keep in mind that 98% of all people on the internet can do whatever they want and it simply doesn't matter. They are public commentators at a three-ring circus and their cavalier or panicked attitudes change nothing. Well, they change one thing. It's hard for the security professionals at work to deal with things when they are constantly having to respond to the three-ring circus. > I stand by and reiterate my view that there is far too much of a cavalier > attitude towards the matter in general out there including here in Gentoo. > But not in particular here, it is everywhere where this is being discussed > at the moment. I don't care where this is being "discussed", scare quotes intentional. > But please think a little about what I mean when I say a "cavalier > attitude", and what it does NOT mean. It does not mean that a lot of > people are not working very hard to analyse and learn about this issue and > taking steps to try to mitigate it. It does not mean people are not well > intentioned, everyone wants to fix this. I have great appreciation and > admiration for a lot of fantastic work I see going on including by people > involved in Gentoo. But I believe it will only really be beneficial in the > far future, not right now. Please stop insulting the work of the people who are working very hard to analyze and learn about this issue and taking steps to try to mitigate it... > How are people in general being cavalier? By trying desperately to salvage > the situation with xz-utils above all else, by focussing too much on how > the original author of xz-utils and rallying round them (absolutely a > great thing to do but has absolutely nothing to do with what is good or > not good for users as a whole right now), there is too much clouded > judgment. There is more I could argue about why I use that word, but I > know by now that I am going against the grain of what the majority want > and it's not what people want to hear so I'm done, this discussion is now > a waste of everyone's time here including mine. ... by implying that people who are NOT part of that process "rallying around the original author" (an act of human compassion!!! which you admit is a good thing) is, somehow, detrimental to the process of working very hard to analyze and learn about this issue and taking steps to try to mitigate it. What does one have to do with the other? Why is it necessary to claim that based on some sort of vibe check "there is too much compassion going around in our communities, and this must mean that not enough effort is being expended on the technical and cleanup aspects"? ... Reading in between the lines, e.g. "trying desperately to salvage the situation with xz-utils", I suspect you are trying to subtly suggest that any second of time where gentoo hasn't yet removed xz-utils from gentoo as a dead end is "cavalier". Considering the fact that xz-utils is widely used and on the critpath for people to actually get work done, including to actually acquire extremely important software that already exists and must somehow be dealt with, I do indeed think that the situation needs salvaging and the community needs some form of xz decompressor. Fortunately, as you've agreed, we know the original xz-utils circa 2020 and before is trustworthy, so using that is viable and under discussion. I understand that you are passionate about your suggestion to make portage not validate distfile hashes. But I don't understand how you think it's a solution to the xz-utils problem. For a wide variety of reasons, but the simplest one is that your proposal has zero plan of action for solving this at the community level and is entirely designed to allow "lone wolf" users to use throwaway systems performing security-sensitive actions (decompressing and hosting distfiles) in a networked environment that has the xz-utils installed, to feed into other security-sensitive systems (daily drivers etc.) that don't, but do have to trust the artifacts produced by the former. It's not being cavalier when zero portage developers responded by saying "good idea I'll drop everything so I can get right on this and implement it". But if you are absolutely positive this is the right solution, I have an offer for you: implement this yourself, submit patche
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 3/30/24 11:17 AM, Eddie Chapman wrote: > Yes that's a very good point, that was something I was wondering in > weighing up both sides, what the costs would be practically, as I don't > know the realities of running Gentoo infrastructure. And maybe the costs > is just too high of a price to pay. > > I wonder if increased use of git repos rather than distributed tarballs > could be part of a solution to those issues, although that could put quite > a storage burden on every user. Unless they were all shallow git pulls and > the user could optionally choose to tar up the git directory after clone > with compression. But yes granted then there is even more ebuild > complexity. Live ebuilds cannot have keywords, so using git repos is not a valid option. There's not really much to discuss here. Recompressing all distfiles in gentoo-specific ways is... definitely a decision. It's a decision that Debian has made, mind you, so it's not like Gentoo would be breaking new ground here, but frankly I don't really regard that as fundamentally palatable. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 3/29/24 11:07 PM, Eddie Chapman wrote: > 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. It suffices to downgrade to the version of xz before a social engineering attack by a malicious actor to gain maintainership of the xz project. Have you been linked to this yet? https://www.mail-archive.com/xz-devel@tukaani.org/msg00571.html -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: make the FHS paths warning easier to read
On 3/29/24 12:54 AM, Haelwenn (lanodan) Monnier wrote:
>> - 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
>
> Could maybe be confusable with installers not supporting DESTDIR though
> (although the sandbox messages look *very* different).
I'm not worried about confusing it with lack of DESTDIR support, since
lack of DESTDIR support would equal a failed src_install rather than a
FHS warning.
It's really nothing to do with the sandbox specifically.
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [PATCH] metadata/install-qa-check.d: make the FHS paths warning easier to read
* 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
---
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
--
2.43.2
[gentoo-dev] [PATCH] flag-o-matic.eclass: simplify implementation and work in all cases
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
---
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
Re: [gentoo-dev] Please migrate your distutils-r1 ebuilds to use PEP517 builds
On 3/9/24 9:32 AM, Michał Górny wrote: > Hi, > > Please consider the "legacy" build mode to be strongly deprecated, both > in distutils-r1 and upstream (to the point that sole presence of > packages installed that way triggers deprecation warnings elsewhere, > sigh). Therefore, if you haven't done that already, please look into > converting your packages to use PEP517 builds (DISTUTILS_USE_PEP517, > installing .dist-info rather than .egg*). We'd like to eventually > remove the legacy code paths from the eclass, as they are not well- > tested at this point, and they certainly are lacking, compared to > the newer code paths. Reminder as well to be *extremely* careful when looking at non-library packages, since projects using setup.py as a "pythonic Makefile" run a very high risk of being broken under PEP 517 (and this is unavoidable, since the python wheel standard doesn't support application packaging, only *.py libraries and executables). As noted in the migration guide link, you MUST check the list of installed files before and after switching and make sure the switch doesn't break anything. > This also applies to overlay maintainers, since overlays will be > affected once we remove old code paths. > > The migration guide is here: > > https://projects.gentoo.org/python/guide/migration.html#migrating-to-pep-517-builds > > While at it, please also look at replacing `distutils_enable_tests > setup.py` with one of the other test runners, as running `setup.py test` > has been deprecated upstream as well. Or running `setup.py` at all, but > the latter is less likely to suddenly stop working. > -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 4/7] distutils-r1.eclass: Make vars local before calling filter-lto
On 3/9/24 2:59 PM, Mike Gilbert wrote:
> On Tue, Mar 5, 2024 at 12:16 PM Michał Górny wrote:
>>
>> Make LTO filtering local to the compilation code. This avoids disabling
>> LTO for non-Python parts of an ebuild.
>>
>> Signed-off-by: Michał Górny
>> ---
>> eclass/distutils-r1.eclass | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
>> index ee1dcef24ff6..134cb39f276a 100644
>> --- a/eclass/distutils-r1.eclass
>> +++ b/eclass/distutils-r1.eclass
>> @@ -1828,6 +1828,10 @@ distutils-r1_run_phase() {
>> # Rust extensions are incompatible with C/C++ LTO compiler
>> # see e.g. https://bugs.gentoo.org/910220
>> if has cargo ${INHERITED}; then
>> + local x
>> + for x in $(all-flag-vars); do
>> + local -x "${x}=${!x}"
>> + done
>> filter-lto
>> fi
>> fi
>
> I had never thought to loop over all-flag-vars like this. Added to my
> mental code repo, thanks!
To be fair, when I suggested this in review of the patch it wasn't my
idea either. I shamelessly stole it from... flag-o-matic.eclass, where
it is used by filter-flags, replace-flags, is-flagq, strip-flags, get-flag.
filter-flags in turn is used by filter-lto, hence all-flag-vars is the
direct API that governs what variables filter-lto will modify. It seemed
fitting to single-source that information.
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On 3/9/24 4:13 PM, Duncan wrote: > I'm not saying don't use gentoo -- I'm a gentooer after all -- I'm saying > gentoo simply isn't in a good position to condemn AI for its energy > inefficiency. In fact, I'd claim that in the Gentoo case there are > demonstrably more energy efficient practical alternatives (can anyone > sanely argue otherwise?, there are binary distros after all), while in the > AI case, for some usage AI is providing practical solutions where there > simply /weren't/ practical solutions /at/ /all/ before. In others, > availability and scale was practically and severely cost-limiting compared > to the situation with AI. At least in those cases despite high energy > usage, AI *is* the most efficient -- arguably including energy efficient > -- practical alternative, being the _only_ practical alternative, at least > at scale. Can Gentoo _ever_ be called the _only_ practical alternative, > at scale or not? > > Over all, I'd suggest that Gentoo is in as bad or worse a situation in > terms of most energy efficient practical alternative than AI, so it simply > can't credibly make the energy efficiency argument against AI. Debian/ > RedHat/etc, perhaps, a case could be reasonably made at least, Gentoo, no, > not credibly. FWIW I am not really convinced of this claim... gentoo is not a monoculture, I could have installed Gentoo in 2012 and was strongly tempted but did not because it didn't have binpkgs, but being an early adopter of https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html is the single reason I have a Gentoo system today. There you go, Gentoo is a binary distro. (If you want it to be one.) You are not required to waste energy in order to use Gentoo. Leaving that aside, I think it's a bit of a red herring to claim that one must be *as energy efficient as possible* in order to have the right to criticize technologies that use orders of magnitude more energy and don't come with an option to avoid spending said energy. You also note that AI is providing practical solutions "where none existed before, for some cases". But I really, really, REALLY don't think this is the case for AI-backed contributions to Gentoo, which plainly do have an exceedingly practical solution that has been in use for a couple decades so far. So we could perhaps agree that LLMs may not be intrinsically an impractical energy waste, but using them to contribute to Gentoo *is*? :) -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
ossibility (if I can ever > find the time). If you can state for a fact that you have done so, then clearly it's not a copyright violation. "exclusively open-source contributions" is NOT however a good bar. There are lots of open-source licenses, but not all of them are compatible with the GPL2 at all, and the ones that are compatible -- in fact, licenses in general -- tend to require you to include copyright notices. The LLM would have to know how to do that. Or if it is trained exclusively on gentoo repositories it may be able to say "okay all inputs are copyright GPL2 The Gentoo Authors". > 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. Huh? "The cat is out of the bag". What does this even mean? I'm not sure how to read this other than: Everyone else is breaking the law anyways so who cares. You can't stop them, so might as well join them. If it's something good or acceptable to do, then it is good or acceptable without needing to be defended by "but lots of people are doing it so you can't stop us". That being said, here's some food for thought: if something bad happens, and we *agree* it's bad, but every time the topic comes up people say "well, it's bad but everyone else is doing it so what can we do, might as well give in"... ... how do you think it became so popular to begin with? Maybe someone before you said "the cat is out of the bag"? -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On 2/27/24 9:45 AM, Michał Górny wrote: > 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. No constructive or valuable contributions will fall afoul of the new ban. Seems reasonable to me. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: 2024-02-26-debianutils-drops-installkernel-dep: add news item
On 2/26/24 10:55 PM, Duncan wrote: > Andrew Nowa Ammerlaan posted on Mon, 26 Feb 2024 18:13:32 +0100 as > excerpted: > >> Removing sys-kernel/installkernel from your system WILL change the way >> kernels are installed by 'make install'! Instead of the versioned >> /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply >> copy bzImage (or equivalent for you arch) into /boot. This image may not >> be picked up by your bootloader or its configuration tools. > > I'm uncomfortable with that unconditional, "SHOUTED" even, "WILL". > > That isn't the case here -- I've been getting versioned images without the > debianutils-based installkernel script for years. > > I long ago (when installkernel was still part of debianutils according to > comments in my version, presumably the debianutils default-enabled USE was > set when it was split out to avoid just this sort of surprise at that > time) created my own version based on the debianutils version, but > bashified/comment-and-var-name-clarified and with a config file that > determines various behavior (along with behavior for my other kernel- > related build/patch/config/etc scripts). Gentoo comes with several different installkernel options, and the critical thing here is that you need to *have* a program called `installkernel`. Via the package manager provided functionality, that means the "installkernel" package. There has been a lot of flux over the last few months. It used to be "installkernel" or "installkernel-systemd", or even "installkernel-gentoo". Surely, anyone can package an alternative installkernel in their overlay. Do we need a virtual/installkernel for this? Is that the only way to set the desired tone in the news item? I'm okay with news items having an implicit "the contents of this news item apply unless you have reimplemented the stated packages in ways that gentoo doesn't officially package and without using an overlay". Or even more simply, all news items have an implicit "unless you know better, including that you know *why* you know better". Someone could be writing that `installkernel` script for use with a kernel package that has an actual RDEPEND on sys-kernel/installkernel, too. Nothing changes. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 4/5] distutils-r1.eclass: wire up meson-python to meson.eclass
On 2/20/24 1:55 AM, Michał Górny wrote:
>> +if [[ ${DISTUTILS_USE_PEP517} = meson-python ]]; then
>
> We use '==' throughout.
I'm sorry to hear that. Would you like a patch to remove it everywhere
else? :)
Shell is a complex language to get consistently right already. The
double equals is almost-offensively redundant and pointless -- its
implementation is to be an exact alias for a single equals.
It causes muscle memory to be more likely to accidentally use this
bashism in #!/bin/sh scripts, it provides zero benefit, and the cherry
on top is that it takes up possibly-valuable real estate from your
screen width and causes (uncompressed) scripts to be (trivially) larger.
I wish Chet would repent of having added it and make bash issue a
bash-level warning on stderr if it encounters one in your scripts.
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH v2 3/5] meson.eclass: refactor src_configure into a setter function
On 2/20/24 1:14 AM, Eli Schwartz wrote:
> +# Calculate the command line which meson should use, and other relevant
> +# variables. Invoke via "${mesonargs[@]}" in the calling environment.
> +# This function is called from meson_src_configure.
I'm sure someone probably has a better name than "${mesonargs[@]}". If
you do I will be eternally grateful. :)
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/3] meson.eclass: wire up LTO support directly into the meson options
On 2/20/24 1:33 AM, Eli Schwartz wrote: > 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: (That being said, I actually tested this with the more thorough v2 patch that fixes numpy by not running twice.) Putting it out there because it's more interesting to look at than v1, not because I think it's necessarily ready. :) -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH v2 5/5] distutils-r1.eclass: fix src_configure to handle flag-o-matic correctly
Use of python_configure_all is a bit broken, because distutils-r1 is a
bit broken. It has the intriguing value-claim that *FLAGS shall be
modified with local -x as part of run-phase, which means that all
modifications are reset as soon as any given phase exits. Including
sub-phases. If you make changes in python_configure or
python_configure_all, as you are expected to do instead of defining
src_configure and then running the eclass phases manually, your changes
inherently get erased before you actually *get* to running builds (i.e.
reading the variables).
For an example of how this works, consider dev-python/scipy. It builds
with filter-lto, for the standard reasons. However, filter-lto gets run
inside python_configure_all, so it gets erased and ignored.
Note: it "worked" anyways prior to reworking meson.eclass to pass
-Db_lto based on `is-flagq flto`. This is because filter-lto removed it
from LDFLAGS, and since distutils-r1 doesn't localize that variable, the
changes stuck around. As a result:
- the previous fix to scipy caused scipy to be compiled with LTO, but
not linked with LTO
- meson.eclass changes caused scipy to be built with -Db_lto=true, which
affects both compiling and linking
It's absolutely unsafe to have flag-o-matic be ignored like this, and it
is fascinating to end up with LTO restored into compile flags while
still being filtered from LDFLAGS... simply as a side effect of
distutils-r1 not modifying the latter.
- this patch causes scipy to be built with -Db_lto=false
Consequences of the change make no difference to standard dev-python/
packages, but affect packages that use both distutils-r1 and other
packaging infrastructure:
- global variables for tools are exported. This is supposed to be a
safe, albeit unnecessary for better-than-setuptools build systems,
option.
- the "debug" option applies the DEBUG preprocessor macro to more than
just python code. This was already the case for python projects that
built non-CPython API C/C++ code and then linked them with thin python
wrappers, so projects with python bindings shouldn't be any different.
Also, it is a "debug" use flag so it's pretty silly if it only toggles
debug on python bindings but not the rest of the package, so just...
deal with it I guess?
- any project that uses cython, now ignores the Modern C Porting flag
"incompatible-pointer-types". This is terrible, because code which
should trigger that error is terrible. But it's also terrible for
python projects with mixed Cython and handwritten C, to squelch that
error just because one file happens to use Cython. Yet, we do it
because we don't have a way to make extremely specific files built
with different CFLAGS compared to the rest of the project. There's no
actual reason to treat handwritten C python modules different from
non-distutils phases.
Signed-off-by: Eli Schwartz
---
no change
eclass/distutils-r1.eclass | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index a42adc182ed9..841fe2df5405 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1815,16 +1815,15 @@ distutils-r1_run_phase() {
fi
# Set up build environment, bug #513664.
- local -x AR=${AR} CC=${CC} CPP=${CPP} CXX=${CXX}
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)"
+ append-cflags $(test-flags-CC
-Wno-error=incompatible-pointer-types)
fi
- local -x CPPFLAGS="${CPPFLAGS} $(usex debug '-UNDEBUG'
'-DNDEBUG')"
+ append-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
# cythonize() but it's better than nothing)
--
2.43.0
[gentoo-dev] [PATCH v2 4/5] distutils-r1.eclass: wire up meson-python to meson.eclass
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, by prying out the options
that meson_src_configure would use and setting passing them as our seed
values for gpep517.
Signed-off-by: Eli Schwartz
---
v2: call setup_meson_src_configure instead of meson_src_configure. This
avoids running `meson setup` twice, and guarantees we use whatever
settings the PEP517 backend requires. In particular, it respects numpy's
vendored meson fork with experimental new features.
eclass/distutils-r1.eclass | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index c0d1992ccce0..a42adc182ed9 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,9 +1390,11 @@ distutils_pep517_install() {
)
;;
meson-python)
+ local mesonargs=()
+ setup_meson_src_configure "${DISTUTILS_ARGS[@]}"
local -x NINJAOPTS=$(get_NINJAOPTS)
config_settings=$(
- "${EPYTHON}" - "${DISTUTILS_ARGS[@]}" <<-EOF ||
die
+ "${EPYTHON}" - "${mesonargs[@]}" <<-EOF || die
import json
import os
import shlex
--
2.43.0
[gentoo-dev] [PATCH v2 3/5] meson.eclass: refactor src_configure into a setter function
This is necessary in order to get at the implementation of `meson setup`
from other eclasses, which do not simply call meson_src_configure. The
intended use case is distutils-r1, where a python build backend wraps
meson and needs its arguments while calling meson on its own.
This allows distutils-r1 to invoke `setup_meson_src_configure` followed
by gpep517, and get access to:
- the preparation which needs to be done, including setting up the
environment
- the array of setup arguments
Signed-off-by: Eli Schwartz
---
v2: new patch
eclass/meson.eclass | 49 +++--
1 file changed, 29 insertions(+), 20 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index e1963e552710..620381ed7079 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -277,15 +277,12 @@ meson_feature() {
usex "$1" "-D${2-$1}=enabled" "-D${2-$1}=disabled"
}
-# @FUNCTION: meson_src_configure
-# @USAGE: [extra meson arguments]
+# @FUNCTION: setup_meson_src_configure
# @DESCRIPTION:
-# This is the meson_src_configure function.
-meson_src_configure() {
- debug-print-function ${FUNCNAME} "$@"
-
- [[ -n "${NINJA_DEPEND}" ]] || ewarn "Unknown value '${NINJA}' for
\${NINJA}"
-
+# Calculate the command line which meson should use, and other relevant
+# variables. Invoke via "${mesonargs[@]}" in the calling environment.
+# This function is called from meson_src_configure.
+setup_meson_src_configure() {
local ltoflags=()
if tc-is-lto; then
# We want to connect -flto in *FLAGS to the dedicated meson
option,
@@ -344,8 +341,7 @@ meson_src_configure() {
: "${BUILD_PKG_CONFIG_PATH:=${PKG_CONFIG_PATH}}"
fi
- local mesonargs=(
- meson setup
+ mesonargs=(
--libdir "$(get_libdir)"
--localstatedir "${EPREFIX}/var/lib"
--prefix "${EPREFIX}/usr"
@@ -390,12 +386,6 @@ meson_src_configure() {
# Arguments from user
"${MYMESONARGS[@]}"
-
- # Source directory
- "${EMESON_SOURCE:-${S}}"
-
- # Build directory
- "${BUILD_DIR}"
)
# Used by symbolextractor.py
@@ -407,13 +397,32 @@ meson_src_configure() {
python_export_utf8_locale
# https://bugs.gentoo.org/721786
- local -x BOOST_INCLUDEDIR="${BOOST_INCLUDEDIR-${EPREFIX}/usr/include}"
- local -x
BOOST_LIBRARYDIR="${BOOST_LIBRARYDIR-${EPREFIX}/usr/$(get_libdir)}"
+ export BOOST_INCLUDEDIR="${BOOST_INCLUDEDIR-${EPREFIX}/usr/include}"
+ export
BOOST_LIBRARYDIR="${BOOST_LIBRARYDIR-${EPREFIX}/usr/$(get_libdir)}"
+}
+
+# @FUNCTION: meson_src_configure
+# @USAGE: [extra meson arguments]
+# @DESCRIPTION:
+# This is the meson_src_configure function.
+meson_src_configure() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ [[ -n "${NINJA_DEPEND}" ]] || ewarn "Unknown value '${NINJA}' for
\${NINJA}"
(
+ setup_meson_src_configure "$@"
+ mesonargs+=(
+ # Source directory
+ "${EMESON_SOURCE:-${S}}"
+
+ # Build directory
+ "${BUILD_DIR}"
+ )
+
export -n {C,CPP,CXX,F,OBJC,OBJCXX,LD}FLAGS
PKG_CONFIG_{LIBDIR,PATH}
- echo "${mesonargs[@]}" >&2
- "${mesonargs[@]}"
+ echo meson setup "${mesonargs[@]}" >&2
+ meson setup "${mesonargs[@]}"
) || die
}
--
2.43.0
[gentoo-dev] [PATCH v2 2/5] meson.eclass: prefer -D buildtype instead of --buildtype
Because that is the logic which meson-python hardcodes, and meson needs
to match calling convention.
Signed-off-by: Eli Schwartz
---
v2: new patch
eclass/meson.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index c2ae289019e9..e1963e552710 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -369,7 +369,7 @@ meson_src_configure() {
)
if [[ -n ${EMESON_BUILDTYPE} ]]; then
- mesonargs+=( --buildtype "${EMESON_BUILDTYPE}" )
+ mesonargs+=( -Dbuildtype="${EMESON_BUILDTYPE}" )
fi
if tc-is-cross-compiler; then
--
2.43.0
[gentoo-dev] [PATCH v2 1/5] meson.eclass: wire up LTO support directly into the meson options
meson's builtin LTO support allows meson to introspect whether LTO is
enabled and do some fancy things, such as forcing LTO off for a single
target that is known to be special(ly bad) and not support LTO.
Signed-off-by: Eli Schwartz
---
no change
eclass/meson.eclass | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index d8bd93082ea5..c2ae289019e9 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -41,7 +41,7 @@ esac
if [[ -z ${_MESON_ECLASS} ]]; then
_MESON_ECLASS=1
-inherit multiprocessing ninja-utils python-utils-r1 toolchain-funcs
+inherit flag-o-matic multiprocessing ninja-utils python-utils-r1
toolchain-funcs
BDEPEND=">=dev-build/meson-1.2.1
${NINJA_DEPEND}
@@ -286,6 +286,36 @@ meson_src_configure() {
[[ -n "${NINJA_DEPEND}" ]] || ewarn "Unknown value '${NINJA}' for
\${NINJA}"
+ local ltoflags=()
+ if tc-is-lto; then
+ # We want to connect -flto in *FLAGS to the dedicated meson
option,
+ # to ensure that meson has visibility into what the user set.
Although
+ # it is unlikely projects will check `get_option('b_lto')` and
change
+ # their behavior, individual targets which are broken with LTO
can
+ # disable it per target. Injecting via *FLAGS means that meson
cannot
+ # strip -flto from that target.
+ ltoflags+=( -Db_lto=true )
+
+ # respect -flto value, e.g. -flto=8, -flto=thin
+ local v=$(get-flag flto)
+ case ${v} in
+ thin)
+ ltoflags+=( -Db_lto_mode=thin )
+ ;;
+ ''|*[!0-9]*)
+ ;;
+ *) ltoflags+=( -Db_lto_threads=${v} )
+ esac
+ # finally, remove it from *FLAGS to avoid passing it:
+ # - twice, with potentially different values
+ # - on excluded targets
+ filter-lto
+ else
+ # Prevent projects from enabling LTO by default. In Gentoo,
LTO is
+ # enabled via setting *FLAGS appropriately.
+ ltoflags+=( -Db_lto=false )
+ fi
+
local BUILD_CFLAGS=${BUILD_CFLAGS}
local BUILD_CPPFLAGS=${BUILD_CPPFLAGS}
local BUILD_CXXFLAGS=${BUILD_CXXFLAGS}
@@ -335,9 +365,7 @@ meson_src_configure() {
# an upstream development matter. bug #754279.
-Dwerror=false
- # Prevent projects from enabling LTO by default. In Gentoo,
LTO is
- # enabled via setting *FLAGS appropriately.
- -Db_lto=false
+ "${ltoflags[@]}"
)
if [[ -n ${EMESON_BUILDTYPE} ]]; then
--
2.43.0
[gentoo-dev] [PATCH v2 0/5] eclass updates for meson <> distutils <> LTO
v2 answers the question: how to deal with accumulated mesonargs without
actually *running* meson_src_configure before gpep517
Eli Schwartz (5):
meson.eclass: wire up LTO support directly into the meson options
meson.eclass: prefer -D buildtype instead of --buildtype
meson.eclass: refactor src_configure into a setter function
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 | 13 --
eclass/meson.eclass| 85 +++---
2 files changed, 70 insertions(+), 28 deletions(-)
Range-diff against v1:
1: aac9d1516675 = 1: aac9d1516675 meson.eclass: wire up LTO support directly
into the meson options
-: > 2: cf98596d9bd1 meson.eclass: prefer -D buildtype instead
of --buildtype
-: > 3: 7ac90f1b2d88 meson.eclass: refactor src_configure into a
setter function
2: bcbec23f5c76 ! 4: e8387e8dec72 distutils-r1.eclass: wire up meson-python
to meson.eclass
@@ Commit message
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.
+pertinent to meson. Make sure it gets invoked, by prying out the
options
+that meson_src_configure would use and setting passing them as our seed
+values for gpep517.
Signed-off-by: Eli Schwartz
@@ eclass/distutils-r1.eclass: distutils_pep517_install() {
)
;;
meson-python)
-+ meson_src_configure "${DISTUTILS_ARGS[@]}"
++ local mesonargs=()
++ setup_meson_src_configure "${DISTUTILS_ARGS[@]}"
local -x NINJAOPTS=$(get_NINJAOPTS)
config_settings=$(
- "${EPYTHON}" - "${DISTUTILS_ARGS[@]}" <<-EOF ||
die
-@@ eclass/distutils-r1.eclass: 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
+- "${EPYTHON}" - "${DISTUTILS_ARGS[@]}" <<-EOF ||
die
++ "${EPYTHON}" - "${mesonargs[@]}" <<-EOF || die
+ import json
+ import os
+ import shlex
-: > 5: a30c280f4573 distutils-r1.eclass: fix src_configure to
handle flag-o-matic correctly
--
2.43.0
Re: [gentoo-dev] [PATCH 1/3] meson.eclass: wire up LTO support directly into the meson options
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
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/3] meson.eclass: wire up LTO support directly into the meson options
On 2/20/24 12:58 AM, Mike Gilbert wrote:
> On Mon, Feb 19, 2024 at 11:26 PM Eli Schwartz wrote:
>>
>> meson's builtin LTO support allows meson to introspect whether LTO is
>> enabled and do some fancy things, such as forcing LTO off for a single
>> target that is known to be special(ly bad) and not support LTO.
>
> Please make sure to test this change with a multilib-enabled ebuild
> with multiple ABIs enabled. I suspect the filter-lto call will cause
> differing results for the ABIs after the first.
>
> If that is the case, we may need to declare the relevant FLAGS
> variables with "local -x".
>>> Configuring source in
/var/tmp/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson ...
* abi_x86_32.x86: running multilib-minimal_abi_src_configure
meson setup --libdir lib --localstatedir /var/lib --prefix /usr
--sysconfdir /etc --wrap-mode nodownload --build.pkg-config-path
/usr/share/pkgconfig:/usr/share/pkgconfig --pkg-config-path
/usr/share/pkgconfig:/usr/share/pkgconfig --native-file
/var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.i686-pc-linux-gnu.x86.ini
-Db_pch=false -Dwerror=false -Db_lto=true -Db_lto_threads=4
-Dbuildtype=plain -Ddefault_library=shared -Dbin_programs=false
-Dbin_contrib=false -Dbin_tests=false -Dzlib=disabled -Dlzma=disabled
-Dlz4=disabled --native-file
/var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.i686-pc-linux-gnu.x86.ini.local
/var/tmp/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson
/var/tmp/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson-abi_x86_32.x86
[...]
Native files :
/var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.i686-pc-linux-gnu.x86.ini
/var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.i686-pc-linux-gnu.x86.ini.local
b_lto: true
b_lto_threads: 4
* abi_x86_64.amd64: running multilib-minimal_abi_src_configure
meson setup --libdir lib64 --localstatedir /var/lib --prefix /usr
--sysconfdir /etc --wrap-mode nodownload --build.pkg-config-path
/usr/share/pkgconfig --pkg-config-path /usr/share/pkgconfig
--native-file
/var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.x86_64-pc-linux-gnu.amd64.ini
-Db_pch=false -Dwerror=false -Db_lto=true -Db_lto_threads=4
-Dbuildtype=plain -Ddefault_library=shared -Dbin_programs=true
-Dbin_contrib=true -Dbin_tests=false -Dzlib=enabled -Dlzma=enabled
-Dlz4=disabled --native-file
/var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.x86_64-pc-linux-gnu.amd64.ini.local
/var/tmp/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson
/var/tmp/portage/app-arch/zstd-1.5.5-r1/work/zstd-1.5.5/build/meson-abi_x86_64.amd64
[...]
Native files :
/var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.x86_64-pc-linux-gnu.amd64.ini
/var/tmp/portage/app-arch/zstd-1.5.5-r1/temp/meson.x86_64-pc-linux-gnu.amd64.ini.local
b_lto : true
b_lto_threads: 4
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] distutils-r1.eclass: wire up meson-python to meson.eclass
On 2/19/24 11:42 PM, Sam James wrote:
>
> 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?
Actually it works great for scipy but fails for numpy since numpy is
using a localized testing branch of meson... so meson_src_configure
cannot parse the new meson module they are adding.
This is caused by the fact that I ran meson_src_configure followed by
gpep517 build-wheel. It is doubling up the configure runs, which isn't
great, but it wasn't obvious to me how to solve this:
- how to get at the accumulated mesonargs?
- BOOST_INCLUDEDIR / BOOST_LIBRARYDIR should be made global?
>> 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
>
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [PATCH 3/3] distutils-r1.eclass: fix src_configure to handle flag-o-matic correctly
Use of python_configure_all is a bit broken, because distutils-r1 is a
bit broken. It has the intriguing value-claim that *FLAGS shall be
modified with local -x as part of run-phase, which means that all
modifications are reset as soon as any given phase exits. Including
sub-phases. If you make changes in python_configure or
python_configure_all, as you are expected to do instead of defining
src_configure and then running the eclass phases manually, your changes
inherently get erased before you actually *get* to running builds (i.e.
reading the variables).
For an example of how this works, consider dev-python/scipy. It builds
with filter-lto, for the standard reasons. However, filter-lto gets run
inside python_configure_all, so it gets erased and ignored.
Note: it "worked" anyways prior to reworking meson.eclass to pass
-Db_lto based on `is-flagq flto`. This is because filter-lto removed it
from LDFLAGS, and since distutils-r1 doesn't localize that variable, the
changes stuck around. As a result:
- the previous fix to scipy caused scipy to be compiled with LTO, but
not linked with LTO
- meson.eclass changes caused scipy to be built with -Db_lto=true, which
affects both compiling and linking
It's absolutely unsafe to have flag-o-matic be ignored like this, and it
is fascinating to end up with LTO restored into compile flags while
still being filtered from LDFLAGS... simply as a side effect of
distutils-r1 not modifying the latter.
- this patch causes scipy to be built with -Db_lto=false
Consequences of the change make no difference to standard dev-python/
packages, but affect packages that use both distutils-r1 and other
packaging infrastructure:
- global variables for tools are exported. This is supposed to be a
safe, albeit unnecessary for better-than-setuptools build systems,
option.
- the "debug" option applies the DEBUG preprocessor macro to more than
just python code. This was already the case for python projects that
built non-CPython API C/C++ code and then linked them with thin python
wrappers, so projects with python bindings shouldn't be any different.
Also, it is a "debug" use flag so it's pretty silly if it only toggles
debug on python bindings but not the rest of the package, so just...
deal with it I guess?
- any project that uses cython, now ignores the Modern C Porting flag
"incompatible-pointer-types". This is terrible, because code which
should trigger that error is terrible. But it's also terrible for
python projects with mixed Cython and handwritten C, to squelch that
error just because one file happens to use Cython. Yet, we do it
because we don't have a way to make extremely specific files built
with different CFLAGS compared to the rest of the project. There's no
actual reason to treat handwritten C python modules different from
non-distutils phases.
Signed-off-by: Eli Schwartz
---
eclass/distutils-r1.eclass | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 35825d4c3aa6..873421bbcee8 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1813,16 +1813,15 @@ distutils-r1_run_phase() {
fi
# Set up build environment, bug #513664.
- local -x AR=${AR} CC=${CC} CPP=${CPP} CXX=${CXX}
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)"
+ append-cflags $(test-flags-CC
-Wno-error=incompatible-pointer-types)
fi
- local -x CPPFLAGS="${CPPFLAGS} $(usex debug '-UNDEBUG'
'-DNDEBUG')"
+ append-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
# cythonize() but it's better than nothing)
--
2.43.0
[gentoo-dev] [PATCH 1/3] meson.eclass: wire up LTO support directly into the meson options
meson's builtin LTO support allows meson to introspect whether LTO is
enabled and do some fancy things, such as forcing LTO off for a single
target that is known to be special(ly bad) and not support LTO.
Signed-off-by: Eli Schwartz
---
eclass/meson.eclass | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index d8bd93082ea5..c2ae289019e9 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -41,7 +41,7 @@ esac
if [[ -z ${_MESON_ECLASS} ]]; then
_MESON_ECLASS=1
-inherit multiprocessing ninja-utils python-utils-r1 toolchain-funcs
+inherit flag-o-matic multiprocessing ninja-utils python-utils-r1
toolchain-funcs
BDEPEND=">=dev-build/meson-1.2.1
${NINJA_DEPEND}
@@ -286,6 +286,36 @@ meson_src_configure() {
[[ -n "${NINJA_DEPEND}" ]] || ewarn "Unknown value '${NINJA}' for
\${NINJA}"
+ local ltoflags=()
+ if tc-is-lto; then
+ # We want to connect -flto in *FLAGS to the dedicated meson
option,
+ # to ensure that meson has visibility into what the user set.
Although
+ # it is unlikely projects will check `get_option('b_lto')` and
change
+ # their behavior, individual targets which are broken with LTO
can
+ # disable it per target. Injecting via *FLAGS means that meson
cannot
+ # strip -flto from that target.
+ ltoflags+=( -Db_lto=true )
+
+ # respect -flto value, e.g. -flto=8, -flto=thin
+ local v=$(get-flag flto)
+ case ${v} in
+ thin)
+ ltoflags+=( -Db_lto_mode=thin )
+ ;;
+ ''|*[!0-9]*)
+ ;;
+ *) ltoflags+=( -Db_lto_threads=${v} )
+ esac
+ # finally, remove it from *FLAGS to avoid passing it:
+ # - twice, with potentially different values
+ # - on excluded targets
+ filter-lto
+ else
+ # Prevent projects from enabling LTO by default. In Gentoo,
LTO is
+ # enabled via setting *FLAGS appropriately.
+ ltoflags+=( -Db_lto=false )
+ fi
+
local BUILD_CFLAGS=${BUILD_CFLAGS}
local BUILD_CPPFLAGS=${BUILD_CPPFLAGS}
local BUILD_CXXFLAGS=${BUILD_CXXFLAGS}
@@ -335,9 +365,7 @@ meson_src_configure() {
# an upstream development matter. bug #754279.
-Dwerror=false
- # Prevent projects from enabling LTO by default. In Gentoo,
LTO is
- # enabled via setting *FLAGS appropriately.
- -Db_lto=false
+ "${ltoflags[@]}"
)
if [[ -n ${EMESON_BUILDTYPE} ]]; then
--
2.43.0
[gentoo-dev] [PATCH 2/3] distutils-r1.eclass: wire up meson-python to meson.eclass
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.
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
--
2.43.0
[gentoo-dev] [PATCH 0/3] eclass updates for meson <> distutils <> LTO
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. 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(-) -- 2.43.0
Re: [gentoo-dev] [PATCH] games-strategy/wargus: Fix running it with games-engines/stratagus[debug]
On 2/15/24 7:53 AM, Matthias Schwarzott wrote:
> When stratagus is compiled with USE=debug, its executable is called
> /usr/bin/stratatgus-dbg.
>
> Signed-off-by: Matthias Schwarzott
> ---
> games-strategy/wargus/wargus-3.3.2.ebuild | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/games-strategy/wargus/wargus-3.3.2.ebuild
> b/games-strategy/wargus/wargus-3.3.2.ebuild
> index fff6023fa177..3295b2911d48 100644
> --- a/games-strategy/wargus/wargus-3.3.2.ebuild
> +++ b/games-strategy/wargus/wargus-3.3.2.ebuild
> @@ -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
>
> EAPI=8
> @@ -46,10 +46,12 @@ pkg_pretend() {
> }
>
> src_configure() {
> + local suffix=
> + has_version games-engines/stratagus[debug] && suffix=-dbg
> local mycmakeargs=(
> -DGAMEDIR="${EPREFIX}/usr/bin"
> -DBINDIR="${EPREFIX}/usr/bin"
> - -DSTRATAGUS="${EPREFIX}/usr/bin/stratagus"
> + -DSTRATAGUS="${EPREFIX}/usr/bin/stratagus${suffix}"
> -DSHAREDIR="${EPREFIX}/usr/share/stratagus/wargus"
> -DICONDIR=/usr/share/icons/hicolor/64x64/apps
> -DWITH_STORMLIB=$(usex bne)
Ok so this just means the package will be broken if you change the USE
flags for stratagus and wargus doesn't get rebuilt.
Why is the executable name different, anyway?
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due to developer inactivity
On 2/14/24 4:49 AM, Michał Górny wrote: > app-doc/mathjax-docs > dev-libs/mathjax I can take mathjax as I need it for calibre. I suppose I can take the docs while I'm at it although I have no use for it personally... -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
On 2/10/24 10:46 PM, Sam James wrote: > 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... I was kind of hoping (in lieu of reading man pages) that someone would try it simply because it's the right thing to do and then get a happy surprise upon seeing that pkgcheck had excellent forethought. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs
On 2/10/24 11:57 AM, 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 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. As a config file, I think we can feel fine changing the defaults without worrying about diverging from upstream, and sticking to worrying "is this a good config value for us". As far as the actual change goes... Arguments in favor of keeping the existing default: - "someone might be relying on it" - security-sensitive software often sets a heavily restricted value for this purpose already, e.g. ssh / gnupg - sometimes it is necessary for other users to see your files, classic example being ~/public_html Arguments in favor of changing the default: - managing files that should be private by changing their permissions is tiresome, and not all private files are managed by "security-sensitive software". If you're writing the next Great American Novel in libreoffice on a shared user system, did you *know* you'd need to protect it from your arch-enemy who hopes to read your homedir and sell your novel instead of you? - You can manage ~/public_html by using setfacl to give apache read access to your entire home directory without granting it to everyone. You're still vulnerable to complete information leakage of your home directory to the apache user, but not also to the aforementioned arch-enemy Regarding which default to change to: - someone who added another account to their user group probably did so with the expectation that they'd be sharing files with that other account, and 700 mode in particular feels like going against that > 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. > > Have a nice day, > Daniel > -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
On 2/10/24 12:26 PM, stefan1 wrote: > On 2024-02-10 11:48, David Seifert wrote: >> >> Are users like you going to maintain and fix these obscure bugs too? I >> don't recall seeing you sending in many fixes or patches, yet you seem >> to be demanding that we go out of our way to accommodate you. > > I've sent and made plenty of patches to support my use cases. > I usually don't send patches to the ml and instead link them in bug > reports, forum posts, etc. > > Feel free to pull patches from my overlay or any other repo I have: > https://github.com/stefan1/stefan_overlay/ From every patch you've demonstrated in the past, my overall impression is that you put zero effort into attempting to convince others, zero effort into making the patches capable of supporting the toggleable use case (no, commenting out lines wholesale is not a suitable patch, adding a build option and an ifelse would be) and basically, in short... ... you've behaved in a way that guarantees that no patches of yours will ever be merged upstream. This is personally sad to me because I actually do think a number of them would make good toggleable feature options for upstream. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
On 2/10/24 6:22 AM, orbea wrote: > On Fri, 9 Feb 2024 16:56:55 -0500 > Eli Schwartz wrote: >> As evidenced by the removal of libressl and eudev, this logic is >> fallacious and wrong and not the way Gentoo is developed. > > Fwiw I still use both and Gentoo removing specifically Libressl has > only been detrimental. There is a huge amount of extra and redundant > maintainer work when all of the fixes have to be applied over and over > again without changes as the main Gentoo repo gets updated. Its > relatively rare that the fixes have to be rebased or changed against > their respective upstream, but rebasing it against Gentoo is an > extremely common and tedious task. > > Your argument is invalid and not appreciated. Sorry, could you clarify what you mean by this? I made a comment about the facts of reality regarding how Gentoo *is* developed. I understand that this has posed challenges to you and makes your work harder. Nonetheless, my statement about facts and realities is true: Gentoo really did remove upstream tree support for both from the ::gentoo tree. What, therefore, is "invalid" about my argument? Are you writing to the mailing list to inform me that my understanding of reality is invalid, and that contrary to my belief, the ::gentoo tree *does* officially support (and package!) libressl and eudev? -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
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... :) -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
On 2/9/24 4:25 PM, Michael Orlitzky wrote: > This is the part where you try to convince me that the things I want > are stupid. OK. I don't care. I want it off. Leave me alone :) As evidenced by the removal of libressl and eudev, this logic is fallacious and wrong and not the way Gentoo is developed. Gentoo does indeed discuss the things that people want, and try to determine whether they are useful to users, whether they are a placebo, and whether they are maintainable or have an adverse effect either on users or on the effort to maintain a consistent tree. So circling back around to the start of the thread: > pkgcheck complains about each new version of dev-lisp/sbcl: It is the allegation of the QA team that the option is a lie, it contains no purpose or value and doesn't contribute to use choice, and pkgcheck is reporting the QA team's allegation. If you wish to convince the QA team otherwise, be my guest... but I would personally encourage you to come up with a better argument than "the option makes me feel better about myself, I don't care what you have to say, just leave my options alone goshdarnit; I have the right to be stupid". Because I don't think you're likely to convince anyone like that. Sorry. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
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'm confused why you think compiling or not compiling in support for part of a programming language is supposed to make CVEs *less* likely to happen, rather than more likely? In the most optimistic scenario, it's a denial of service CVE because part of the programming language got deleted, instead of a remote code execution vulnerability because the application didn't correctly handle the consequences of silently returning NULL. > 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. ... and this is a property of the way you build the programming language rather than your choice of APIs when you compile your own software *using* sbcl? > 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. That sounds trivial to demonstrate. Can you describe the timings on how long a src_compile takes with and without this USE flag? What is the resulting size of the package? I will note that using -march=native also has an effect on compile time, and space and memory efficiency. But it is a feature of your CFLAGS, not USE. This invites another thought, for me. Gentoo doesn't necessarily need to support every possible option, since package.env can set EXTRA_ECONF, MYMESONARGS, MYCMAKEARGS. eclass-based overrides, too, are part of "Gentoo is about choice". I use this myself for things that aren't controllable as USE flags. > 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. 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. If people disagree about the specific choice itself, that's one thing (and Gentoo values respecting all sides, though not unconditionally so -- see libressl and eudev for examples where choice was booted out of ::gentoo, and people were told they'd have to homebrew their own overlays if they wanted that choice). It's another thing entirely when people cannot see what the choice actually is, and start suspecting that there is no choice, "the choice is a lie". -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
On 2/9/24 12:17 PM, Michael Orlitzky wrote: > USE=unicode and USE=ipv6 are different beasts. In many cases they > directly and immediately change the behavior of the package. I think > that there are good reasons to want those two disabled, but the user's > reasoning shouldn't really matter. The only "problem" in this case is > the pkgcheck warning. Upstream supports it, the maintainer supports it, > it works, users might want it, and it's one of our selling points. > Given all of that, I'm leery of treating it like some kind of mistake. Asking out of genuine ignorance: what kind of direct behavioral changes occur as a result of setting or unsetting USE=ipv6. I'm assuming that: - users who don't want ipv6 are also masking it in the kernel at runtime - users who do want ipv6 consider it a bug if the direct and immediate change is that the software is "broken because it fails due to lack of ipv6 support" Along a similar line: I've never touched sbcl so again, I have *no* clue what its deal is and am just curious: what are the advantages and disadvantages of setting USE=unicode on it? In particular since it defaults to on, under what circumstances would someone wish to unset it? "There are good reasons" is pretty vague. I assume the reason is more interesting than "when it is disabled, the package is buggy and broken for certain use cases which the user has explicitly chosen to not care about". Does it make the package smaller? Does it avoid depending on additional packages? (no...) Are unicode strings sometimes bad to have, but users cannot choose the string type except by recompiling the programming language itself? (Okay if that is the case, but that seems a strange decision for a programming language to make...) -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Block ebuilds installing tests to ${D} by default
On 2/1/24 4:52 PM, Mike Gilbert wrote: > Ah, that's a relatively new configure option added in Python 3.10. It > didn't exist back in 2015 when I was looking into this. > > https://docs.python.org/3/whatsnew/3.10.html#build-changes > > Thanks for pointing it out. Yes -- but personally, to me, it's less about the option existing in order to avoid having to manually implement it, and more about the fact that it's a clear message that you have the moral right to implement it yourself for 3.9 as well. And the public documentation for the "test" module has told people that it is purely internal, unstable, liable to change at the drop of a hat, and documented purely for the benefit of people hacking on the cpython.git repository... since python 2.6 and earlier Which reinforces the point that any packages that do `import test.support` are doing something naughty and we don't need to worry about people complaining that Gentoo isn't a good upstream-compatible development environment. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Block ebuilds installing tests to ${D} by default
On 2/1/24 4:03 PM, Michał Górny wrote: > I suppose you are referring to dev-lang/python here. Unfortunately, > removing tests from it is a non-trivial problem. As I've mentioned to > you before, there are packages that actually import modules form the > test directory. > > Remember that Gentoo has a policy of following upstream, and this policy > is specifically targeted towards developers who expect Gentoo to > be a good baseline environment for developing packages. By explicitly > diverging from upstream default install by default, we are effectively > creating an incompatible Python environment and requiring users to go > through extra steps to restore upstream compatibility. The "following upstream" argument is extremely weak. eschwartz ~/git/cpython $ ./configure --help| grep test --disable-test-modules don't build nor install test modules Clearly, upstream is giving you loud and clear permission to refrain from installing this. They even have a split in their Makefile variables: - LIBSUBDIRS: things that are always installed - TESTSUBDIRS: test files that you can disable > What's worse, Python development is often done via virtual environments. > For regular Python packages, all kinds of Gentoo divergence can be > easily "reverted" by installing the upstream packages inside the virtual > environment. However, this isn't the case for dev-lang/python itself -- > by stripping it down we're effectively creating virtual environments > that are not fully functional and whose functionality cannot be restored > without actually rebuilding dev-lang/python. This... I sort of hear the argument, and at the same time I kind of do not. https://docs.python.org/3/library/test.html """ Note The test package is meant for internal use by Python only. It is documented for the benefit of the core developers of Python. Any use of this package outside of Python’s standard library is discouraged as code mentioned here can change or be removed without notice between releases of Python. """ Any users who are developing packages on Gentoo and finding that a USE=pythontests choice is producing a "not fully functional" virtual environment which requires rebuilding dev-lang/python to fix, would be better served obeying the pleading and impassioned requests from upstream CPython and NOT using the `test` module. Not even `test.support`. However there are definitely packages in the wild that ignore this, and require the "test" module. > This is going to be a lot of effort, considering that > effectively developers would have to run without test suites installed > to detect missing dependencies, and then rebuild dev-lang/python every > time they are about to run tests in a package that actually requires > these files. This I think is the biggest issue. It's a relatively simple problem to solve for any distro that supports a single package recipe producing multiple packages -- but portage does not (yet!) support one ebuild that produces two gpkg.tar files, one per "component" of the full set of installed files. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] cargo.eclass: add CARGO_TOML_DIR
On 1/22/24 10:32 PM, orbea wrote:
> This is required when cargo_live_src_unpack needs to be find a
> Cargo.toml file in a directory other than ${S}
>
> Signed-off-by: orbea
> ---
Fairly confused why this email was posted to an existing thread instead
of a new one?
Anyway, I'm sure the change is very reasonable but it is difficult to
tell from an outside perspective just by reading the commit message --
which doesn't detail why your Cargo.toml would be in a directory other
than the one src_compile() starts off in.
--
Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] New category: dev-build
On 1/8/24 6:32 PM, Gordon Pettey wrote: > There are at least a few generally language-specific build > tools/systems that can, if you're into masochism, be used to build > other languages (Gradle, Maven, etc.), and tools like Ant, which while > primarily used in Java projects is really just a Makefile with > different syntax and core functions in XML. Does making a new category > for explicitly general-purpose tools like Make and friends ambiguate > where the language-specific tools belong? Should other > non-Make-related packages be moved from their current dev-[language] > locations? > > Does dev-util/gyp really belong there, or since it is node-specific, > should there be a dev-js category? gyp is not node specific. It was originally invented by Google, to be Google's build system for the C++ project known as the chromium web browser. It is also famously used to build the C++ project known as Node.js (the interpreter) which node projects use. It is not a very popular build system because it is written by Google and as was only to be expected, Google has deprecated it in favor of GN and thus gyp is largely not used anymore. Its only revdep in Gentoo is mozc, another large C++ project that contains no javascript. IIRC, Node.js forked and maintained gyp internally so they could continue to use it to build C++ software without being concerned about its being abandoned. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
On 1/2/24 4:15 AM, k...@aspodata.se wrote: > Eli Schwartz: > [...] >> +Systems which have /usr and / on separate filesystems have always required a >> +dedicated initramfs to bring up both partitions. Systems where both /usr >> and / >> +are on the same filesystem may use an initramfs if they wish, or choose not >> +to. > [...] > > Well, that is not technically correct, just have the required kernel > drivers (eg. AHCI and ext2/4) compiled in and use the same busybox > commands as in the initrd, but placed in /, to bring up the system > to the point that /usr is mounted. > > I have a static dev, compiled in drivers, busybox init and mount, and > separate / and /usr on a box here, works perfectly well. > Soo, add a clause about what gentoo supports out of the box and that > you can make it work if you wish. > If there is a general wish I can write an article about how to make > it work. You need the required kernel drivers regardless of having /usr on a separate partition. The problem here is solely about after the kernel has booted, mounted the / filesystem, and run init -- init needs to fully bring the system up. While it's no doubt possible to do this with finely-crafted busybox usage, there's a lot of ways it could break if you aren't *very* careful, and that should not require ongoing support. It's firmly in the "you break it, you bought it" category. But I have no objection if it's mentioned on the wiki in the initramfs article or somewhere similar. I don't think this is a blocker for dropping hacks like usr-ldscript.eclass usage, though. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
On 1/2/24 3:22 AM, Ulrich Mueller wrote: >>>>>> 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.) Thanks, I was too hasty in my double-checking -- I fixed all 3 formatting bugs locally. >> +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? > > Ulrich As Sam said, the idea is to give people a heads up that they have to do something to adapt -- given it's been 10+ years, it feels a bit not-good to suddenly carry out the original promise without warning. This is a good reason why when something is promised, it should actually be done on schedule... Given everything was already decided and signed off on, there's no need to rehash whether or not to do it. We can just do it. But users should get a heads up that there is something they need to do to ensure their system will be working -- and 10+ years is simply too much of a gap between the time of the news and the time of fulfillment. -- Eli Schwartz
[gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
Revival of commit a79dd69b0cca439bc0c483c9193c79e0554819d0. Bug: https://bugs.gentoo.org/868306#c10 Bug: https://bugs.gentoo.org/902829 Bug: https://bugs.gentoo.org/915379 Bug: https://bugs.gentoo.org/825078 Signed-off-by: Eli Schwartz --- ...separate-usr-now-requires-an-initramfs.txt | 47 +++ 1 file changed, 47 insertions(+) create mode 100644 2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt diff --git a/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt b/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt new file mode 100644 index 000..bfcbd87 --- /dev/null +++ b/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt @@ -0,0 +1,47 @@ +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] + +Systems which have /usr and / on separate filesystems have always required a +dedicated initramfs to bring up both partitions. Systems where both /usr and / +are on the same filesystem may use an initramfs if they wish, or choose not +to. + +Historically, Gentoo has tried to make the separate filesystems use case work +anyway. Despite all our efforts, it is broken and continues to get more broken +under various configurations. The only workable solution is to support +separate /usr but only when an initramfs is present. For more details on why +this is broken, see: + +- https://bugs.gentoo.org/868306#c10 +- https://bugs.gentoo.org/902829 +- http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken +- https://bugs.gentoo.org/915379 +- https://github.com/trofi/nix-guix-gentoo/commit/43d84cc00af530ef912d9c98448b64d6b5282907 +- https://github.com/trofi/nix-guix-gentoo/commit/8f194519982fbfabb6b3ca84c0806b1a379b5d06 +- https://bugs.gentoo.org/825078 + +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 + +11 years later, the support is being withdrawn. On 2024-02-01, we plan to +begin work on decommissioning existing workarounds and will not accept any +more. + +User Action Required + + +If you have separate /usr and are not currently using an initramfs, you have +until 2024-02-01 to set up an initramfs. If you do not, then at some point on +or after this date, routine system upgrades will leave your system unbootable. + +For details on setting up an initramfs, see: + +https://wiki.gentoo.org/wiki/Initramfs/Guide -- 2.41.0
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR
On 12/11/23 2:27 PM, Michał Górny wrote: > That looks wrong. Per [1]: > >> […] NO_COLOR environment variable that, when present and not an empty > string (regardless of its value), prevents the addition of ANSI color. > > So hey, I'm actually fixing pytest ;-). > > [1] https://no-color.org/ When you say you are fixing pytest, do you mean you are submitting a PR to pytest to make its behavior align with the (tbh reasonable) behavior you expected and want? -- Eli Schwartz
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR
On 12/11/23 2:30 PM, Ulrich Mueller wrote:
>>>>>> On Mon, 11 Dec 2023, Eli Schwartz wrote:
>
>>> + local color=yes
>>> + [[ ${NO_COLOR} ]] && color=no
>
>> [[ -v NO_COLOR ]]
>
> No, this would give the wrong result if NO_COLOR is set to an empty
> value. [[ ${NO_COLOR} ]] or [[ -n ${NO_COLOR} ]] is the correct test:
>
>"Command-line software which adds ANSI color to its output by default
>should check for a NO_COLOR environment variable that, when present
>and not an empty string (regardless of its value), prevents the
>addition of ANSI color." -- https://no-color.org/
Again, not according to pytest itself. ;)
Given the commit message says:
"""
Adjust it to correctly check whether it is set at all rather than to a
specific value, to match the behavior of pytest itself.
"""
--
Eli Schwartz
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR
On 12/2/23 7:44 AM, Michał Górny wrote:
> Update epytest to respect the modern NO_COLOR variable rather than
> Portage's old NOCOLOR. Adjust it to correctly check whether it is set
> at all rather than to a specific value, to match the behavior of pytest
> itself.
>
> Signed-off-by: Michał Górny
> ---
> eclass/python-utils-r1.eclass | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index 394f64a5d139..da9cb820840f 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -1336,15 +1336,8 @@ epytest() {
> _python_check_EPYTHON
> _python_check_occluded_packages
>
> - local color
> - case ${NOCOLOR} in
> - true|yes)
> - color=no
> - ;;
> - *)
> - color=yes
> - ;;
> - esac
> + local color=yes
> + [[ ${NO_COLOR} ]] && color=no
[[ -v NO_COLOR ]]
This is processed by the pytest code:
```
if "NO_COLOR" in os.environ:
return False
```
>
> local args=(
> # verbose progress reporting and tracebacks
--
Eli Schwartz
Re: [gentoo-dev] heads up: codeberg changed gzip impls (?) for ${REPO}/archive/${TAG}.tar.gz files
On 12/11/23 5:47 AM, Arsen Arsenović wrote:
> hi,
>
> it seems that codeberg has changed how they produce their archives on
> URLs like <https://codeberg.org/dnkl/foot/archive/${tag}.tar.gz> leading
> to digest failures like <https://bugs.gentoo.org/919135>, as implied by
> the following checks:
>
> ~$ diff <( <( ~$ diff <( <( Binary files /dev/fd/63 and /dev/fd/62 differ
>
> the above shows that compressed content differs while decompressed
> content remains identical.
>
> (dls/foot-1.16.2.tar.gz is downloaded from the master distfiles mirror,
> /var/cache/distfiles/foot-1.16.2.tar.gz is fetched from codeberg at
> around two in the morning last night)
>
> you might want to regenerate manifests for projects fetching from
> /archive/ urls on codeberg.
>
> Daniel, thank you for working on foot. may I ask that you attach 'meson
> dist'-generated files to releases? you could also use that opportunity
> to hash or sign them, if you so desire.
>
> in either case, thank you again.
>
> have a lovely day, all!
It sounds like they completely failed to get the memo about:
https://github.com/orgs/community/discussions/46034
However, I really do wish tremendously that they *would* change all
tarball checksums... for a good reason!
Namely, they need to fix https://github.com/go-gitea/gitea/issues/18078
because currently gitea-based software forges kind of suck and I'd
rather no one used them for anything, lol.
It does appear that since last year when they fixed an unrelated issue,
closed *this* issue as "not fixed but sometime in the future we'll fix
it, we pinky promise"...
... that they've fixed the issue for manually uploaded release assets
where the download url was based on an unpredictable uuid.
So that's sort of kind of a little bit good at least.
--
Eli Schwartz
Re: [gentoo-dev] Adding Ada support
On 12/9/23 10:51 AM, Luke A. Guest wrote: >>> 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. >> > > Ok, just looked at this. I don't have sendmail installed here. Due to > the way I've worked on this, the only way I know how to btw and which > was pointed to initially on the #gentoo-* channels. Which is to have a > remote (covered in the README from today) in which I can diff the eclass > with my version to make sure I only ever have ada changes and cherry > pick what I need into my eclass. > > If there is a way, I'll send it, but you'll need to guide me on what I > need to do to do it. The git send-email tools don't require mail-mta/sendmail installed, but they do need git to be built with USE=perl. That being said, not everyone is familiar with how to actually use `git send-email`, it can be a bit tricky to set it up to connect with your email account via SMTP. In particular, if your provider doesn't like you to authenticate without OAuth. If you like, there's a way to prepare your patches via a guided web UI workflow: https://man.sr.ht/git.sr.ht/#sending-patches-upstream tl;dr push your repository to https://git.sr.ht and have it send out the commits you select to the email address you select. Hope that helps, -- Eli Schwartz
[gentoo-dev] [RFC PATCH 10/10] net-print/cups-filters: restrict tests
Checking the test phase output, it is not implemented and does nothing.
Or to be more accurate, it compiles one executable but never runs
anything.
The former testsuite in the 1.x series has been divided up, just like
the constituent installable components, and it turns out that all
testable parts are in the split-out packages and none are left here.
Signed-off-by: Eli Schwartz
---
net-print/cups-filters/cups-filters-2.0.0.ebuild | 9 +
1 file changed, 9 insertions(+)
diff --git a/net-print/cups-filters/cups-filters-2.0.0.ebuild
b/net-print/cups-filters/cups-filters-2.0.0.ebuild
index fde6177f0322..e07acf911895 100644
--- a/net-print/cups-filters/cups-filters-2.0.0.ebuild
+++ b/net-print/cups-filters/cups-filters-2.0.0.ebuild
@@ -24,6 +24,15 @@ BDEPEND="
virtual/pkgconfig
"
+# The tests are composed of:
+# - built program
+# - test case itself: filter/test.sh
+#
+# The latter is not wired up, and it becomes immediately evident why.
+# Bow to this reality and don't claim we can run anything. As a side
+# effect, don't compile in src_test, that which we never use.
+RESTRICT="test"
+
src_configure() {
local myeconfargs=(
--enable-imagefilters
--
2.41.0
[gentoo-dev] [RFC PATCH 09/10] net-print/cups-browsed: restrict tests
The tests are newly created during the 2.x upgrade. They will hang
forever if they cannot run properly. And running them properly has hit a
wall. I'm not sure where to go on from here.
Even getting this far means stepping outside of what portage can
reasonably require. Avahi only runs as root, and doesn't seem to have a
mocking mode, and even if it is running, the sandbox prevents src_test
from seeing it.
Signed-off-by: Eli Schwartz
---
.../cups-browsed/cups-browsed-2.0.0.ebuild| 19 +++
1 file changed, 19 insertions(+)
diff --git a/net-print/cups-browsed/cups-browsed-2.0.0.ebuild
b/net-print/cups-browsed/cups-browsed-2.0.0.ebuild
index 6baeb697f2cd..0232d57c8b51 100644
--- a/net-print/cups-browsed/cups-browsed-2.0.0.ebuild
+++ b/net-print/cups-browsed/cups-browsed-2.0.0.ebuild
@@ -29,6 +29,18 @@ BDEPEND="
virtual/pkgconfig
"
+# The tests are new since the split out of cups-filters. Actually running them
+# seems to be challenging. You need:
+# - cups tools that are USE-optional
+# - running avahi-daemon (as root!)
+# - disable portage's pid-sandbox, which interferes with avahi
+# - ipptool still fails to connect to port 8xxx
+#
+# If anything fails, a `while true` loop fails to successfully launch and break
+# out of the loop, leading to a hang. Until there's an obvious recipe for
+# successfully running the tests, restrict it.
+RESTRICT="test"
+
PATCHES=(
"${FILESDIR}"/0001-cups-browsed.c-Fix-build-with-avahi-disabled-20.patch
)
@@ -47,6 +59,13 @@ src_configure() {
econf "${myeconfargs[@]}"
}
+src_test() {
+ # Requires avahi running. Hangs forever if not available.
+ avahi-daemon --check 2>/dev/null || die "no running avahi daemon found,
cannot run tests"
+
+ default
+}
+
src_install() {
default
--
2.41.0
[gentoo-dev] [RFC PATCH 08/10] net-print/cups: avoid running unittests in src_compile
If USE=test, an option was passed to configure that makes unittest
binaries be built, and as a side effect also runs them. But we really do
not want to run tests in src_compile, as FEATURES=test might not be set.
Crudely hack around this by overriding the autoconf variable that would
normally be set by `$(use_enable test unit-tests)`, when running the
test invocation itself. As a side effect, this also moves the
test-program compilation to src_test.
Signed-off-by: Eli Schwartz
---
net-print/cups/cups-2.4.7-r2.ebuild | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net-print/cups/cups-2.4.7-r2.ebuild
b/net-print/cups/cups-2.4.7-r2.ebuild
index 3f63cd43a70c..d8a193a64337 100644
--- a/net-print/cups/cups-2.4.7-r2.ebuild
+++ b/net-print/cups/cups-2.4.7-r2.ebuild
@@ -30,8 +30,6 @@ LICENSE="Apache-2.0"
SLOT="0"
IUSE="acl dbus debug kerberos openssl pam selinux static-libs systemd test usb
X xinetd zeroconf"
-# As of 2.4.2, they don't actually seem to be interactive (they pass some flags
-# by default to input for us), but they fail on some greyscale issue w/
poppler?
RESTRICT="!test? ( test )"
BDEPEND="
@@ -167,7 +165,6 @@ multilib_src_configure() {
$(use_enable kerberos gssapi)
$(multilib_native_use_enable pam)
$(use_enable static-libs static)
- $(use_enable test unit-tests)
--with-tls=$(usex openssl openssl gnutls)
$(use_with systemd ondemand systemd)
$(multilib_native_use_enable usb libusb)
@@ -222,7 +219,12 @@ multilib_src_test() {
mkdir "${T}"/cups-tests || die
# We only build some of CUPS for multilib, so can't run the tests.
- multilib_is_native_abi && default
+ if multilib_is_native_abi; then
+ # avoid building *and running* test binaries in src_compile
+ #
https://github.com/OpenPrinting/cups/commit/b1d42061e9286f50eefc851ed906d17c6e80c4b0
+ emake UNITTESTS=unittests
+ default
+ fi
}
multilib_src_install() {
--
2.41.0
[gentoo-dev] [RFC PATCH 07/10] net-print/cups: re-enable tests
They appear to work at the moment. There's a fun oddity, in that if
libcupsfilters is installed you need image support of some variety.
Signed-off-by: Eli Schwartz
---
net-print/cups/cups-2.4.7-r2.ebuild | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/net-print/cups/cups-2.4.7-r2.ebuild
b/net-print/cups/cups-2.4.7-r2.ebuild
index d63cb0132e9a..3f63cd43a70c 100644
--- a/net-print/cups/cups-2.4.7-r2.ebuild
+++ b/net-print/cups/cups-2.4.7-r2.ebuild
@@ -17,7 +17,7 @@ if [[ ${PV} == * ]] ; then
else
SRC_URI="https://github.com/OpenPrinting/cups/releases/download/v${MY_PV}/cups-${MY_PV}-source.tar.gz;
if [[ ${PV} != *_beta* && ${PV} != *_rc* ]] ; then
- KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~mips
~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86"
+ KEYWORDS="~amd64"
fi
fi
@@ -32,14 +32,14 @@ IUSE="acl dbus debug kerberos openssl pam selinux
static-libs systemd test usb X
# As of 2.4.2, they don't actually seem to be interactive (they pass some flags
# by default to input for us), but they fail on some greyscale issue w/
poppler?
-RESTRICT="!test? ( test ) test"
+RESTRICT="!test? ( test )"
BDEPEND="
acct-group/lp
acct-group/lpadmin
virtual/pkgconfig
"
-DEPEND="
+COMMON_DEPEND="
app-text/libpaper:=
sys-libs/zlib
acl? (
@@ -60,8 +60,13 @@ DEPEND="
xinetd? ( sys-apps/xinetd )
zeroconf? ( >=net-dns/avahi-0.6.31-r2[dbus,${MULTILIB_USEDEP}] )
"
+# if libcupsfilters is installed, more tests are run. They fail without at
least one of the two formats enabled.
+DEPEND="
+ ${COMMON_DEPEND}
+ test? ( || ( net-print/libcupsfilters[jpeg]
net-print/libcupsfilters[png] ) )
+"
RDEPEND="
- ${DEPEND}
+ ${COMMON_DEPEND}
acct-group/lp
acct-group/lpadmin
selinux? ( sec-policy/selinux-cups )
--
2.41.0
[gentoo-dev] [RFC PATCH 06/10] net-print/cups: drop cyclic dependency on cups-filters
It is a PDEPEND which forces installing both, and makes building a
modular cups-filters more challenging.
Additionally, many "users" of cups may not actually want cups-filters at
all. A primary reason is because cups provides libcups, which other
packages need as an RDEPEND in order to support USE=cups while not
having any expectation of using a printing stack (at least, yet). Rely
instead on a metapackage for the full cups experience.
Signed-off-by: Eli Schwartz
---
net-print/cups/cups-2.4.7-r2.ebuild | 313
1 file changed, 313 insertions(+)
create mode 100644 net-print/cups/cups-2.4.7-r2.ebuild
diff --git a/net-print/cups/cups-2.4.7-r2.ebuild
b/net-print/cups/cups-2.4.7-r2.ebuild
new file mode 100644
index ..d63cb0132e9a
--- /dev/null
+++ b/net-print/cups/cups-2.4.7-r2.ebuild
@@ -0,0 +1,313 @@
+# Copyright 1999-2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+inherit autotools linux-info xdg multilib-minimal optfeature pam
toolchain-funcs
+
+MY_PV="${PV/_beta/b}"
+MY_PV="${MY_PV/_rc/rc}"
+MY_PV="${MY_PV/_p/op}"
+MY_P="${PN}-${MY_PV}"
+
+if [[ ${PV} == * ]] ; then
+ inherit git-r3
+ EGIT_REPO_URI="https://github.com/OpenPrinting/cups.git;
+ [[ ${PV} != ]] && EGIT_BRANCH=branch-${PV/.}
+else
+
SRC_URI="https://github.com/OpenPrinting/cups/releases/download/v${MY_PV}/cups-${MY_PV}-source.tar.gz;
+ if [[ ${PV} != *_beta* && ${PV} != *_rc* ]] ; then
+ KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~mips
~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86"
+ fi
+fi
+
+S="${WORKDIR}/${MY_P}"
+
+DESCRIPTION="The Common Unix Printing System"
+HOMEPAGE="https://www.cups.org/ https://github.com/OpenPrinting/cups;
+
+LICENSE="Apache-2.0"
+SLOT="0"
+IUSE="acl dbus debug kerberos openssl pam selinux static-libs systemd test usb
X xinetd zeroconf"
+
+# As of 2.4.2, they don't actually seem to be interactive (they pass some flags
+# by default to input for us), but they fail on some greyscale issue w/
poppler?
+RESTRICT="!test? ( test ) test"
+
+BDEPEND="
+ acct-group/lp
+ acct-group/lpadmin
+ virtual/pkgconfig
+"
+DEPEND="
+ app-text/libpaper:=
+ sys-libs/zlib
+ acl? (
+ kernel_linux? (
+ sys-apps/acl
+ sys-apps/attr
+ )
+ )
+ dbus? ( >=sys-apps/dbus-1.6.18-r1[${MULTILIB_USEDEP}] )
+ kerberos? ( >=virtual/krb5-0-r1[${MULTILIB_USEDEP}] )
+ pam? ( sys-libs/pam )
+ !pam? ( virtual/libcrypt:= )
+ !openssl? ( >=net-libs/gnutls-2.12.23-r6:=[${MULTILIB_USEDEP}] )
+ openssl? ( dev-libs/openssl:=[${MULTILIB_USEDEP}] )
+ systemd? ( sys-apps/systemd )
+ usb? ( virtual/libusb:1 )
+ X? ( x11-misc/xdg-utils )
+ xinetd? ( sys-apps/xinetd )
+ zeroconf? ( >=net-dns/avahi-0.6.31-r2[dbus,${MULTILIB_USEDEP}] )
+"
+RDEPEND="
+ ${DEPEND}
+ acct-group/lp
+ acct-group/lpadmin
+ selinux? ( sec-policy/selinux-cups )
+"
+
+PATCHES=(
+ "${FILESDIR}/${PN}-2.4.1-nostrip.patch"
+ "${FILESDIR}/${PN}-2.4.1-user-AR.patch"
+)
+
+MULTILIB_CHOST_TOOLS=(
+ /usr/bin/cups-config
+)
+
+pkg_setup() {
+ if use kernel_linux; then
+ linux-info_pkg_setup
+ if ! linux_config_exists; then
+ ewarn "Can't check the linux kernel configuration."
+ ewarn "You might have some incompatible options
enabled."
+ else
+ # Recheck that we don't have usblp to collide with
libusb; this should now work in most cases (bug #501122)
+ if use usb; then
+ if linux_chkconfig_present USB_PRINTER; then
+ elog "Your USB printers will be managed
via libusb. In case you run into problems, "
+ elog "please try disabling USB_PRINTER
support in your kernel or blacklisting the"
+ elog "usblp kernel module."
+ elog "Alternatively, just disable the
usb useflag for cups (your printer will still work)."
+ fi
+ else
+ if ! linux_chkconfig_present USB_PRINTER; then
+ ewarn "If you plan to use USB printers
you should enable the USB_PRINTER"
+ ewarn "support in your kernel."
+ ewarn "Please en
[gentoo-dev] [RFC PATCH 05/10] net-print/cups-meta: new package, add 1
New metapackage to pull in all the parts for a functional cups printing stack. This will allow to avoid relying on net-print/cups for that purpose -- because, with the advent of cups-filters 2.0.0 and the ongoing work to refactor CUPS 3, things are broken out into various interconnected components and configuring each one is not perfectly straightforward. Eventually, there will not be a "cups" package at all anyway. Additionally, this helps solve a longstanding cycle with cups <--> cups-filters that has only gotten worse since the latter was broken up into various packages which require libcups from cups, which in turn depends on -filters. There are a number of use cases for having cups installed in "minimal" mode so that other packages can build against it. Signed-off-by: Eli Schwartz --- net-print/cups-meta/cups-meta-1.ebuild | 21 + net-print/cups-meta/metadata.xml | 9 + 2 files changed, 30 insertions(+) create mode 100644 net-print/cups-meta/cups-meta-1.ebuild create mode 100644 net-print/cups-meta/metadata.xml diff --git a/net-print/cups-meta/cups-meta-1.ebuild b/net-print/cups-meta/cups-meta-1.ebuild new file mode 100644 index ..f4d404d2be8e --- /dev/null +++ b/net-print/cups-meta/cups-meta-1.ebuild @@ -0,0 +1,21 @@ +# Copyright 2023 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=8 + +DESCRIPTION="Metapackage for a fully configured cups printer setup" + +SLOT="0" +IUSE="+browsed +foomatic pdf +postscript +poppler zeroconf" +KEYWORDS="~amd64" + +RDEPEND=" + net-print/cups[zeroconf?] + net-print/libppd[postscript?,poppler?] + net-print/libcupsfilters[pdf?,poppler?] + net-print/cups-filters[foomatic?] + + browsed? ( net-print/cups-browsed ) + pdf? ( app-text/mupdf ) + postscript? ( >=app-text/ghostscript-gpl-9.09[cups] ) +" diff --git a/net-print/cups-meta/metadata.xml b/net-print/cups-meta/metadata.xml new file mode 100644 index ..07456818fddc --- /dev/null +++ b/net-print/cups-meta/metadata.xml @@ -0,0 +1,9 @@ + +https://www.gentoo.org/dtd/metadata.dtd;> + + + print...@gentoo.org + Gentoo Printing Project + + + -- 2.41.0
[gentoo-dev] [RFC PATCH 04/10] net-print/cups-browsed: new package, add 2.0.0
Part of the CUPS v3 evolution. Now, cups-filters has been split out into
multiple sub-packages. This contains the standalone browsed component.
Signed-off-by: Eli Schwartz
---
net-print/cups-browsed/Manifest | 1 +
.../cups-browsed/cups-browsed-2.0.0.ebuild| 63 +++
...d.c-Fix-build-with-avahi-disabled-20.patch | 34 ++
net-print/cups-browsed/metadata.xml | 11
4 files changed, 109 insertions(+)
create mode 100644 net-print/cups-browsed/Manifest
create mode 100644 net-print/cups-browsed/cups-browsed-2.0.0.ebuild
create mode 100644
net-print/cups-browsed/files/0001-cups-browsed.c-Fix-build-with-avahi-disabled-20.patch
create mode 100644 net-print/cups-browsed/metadata.xml
diff --git a/net-print/cups-browsed/Manifest b/net-print/cups-browsed/Manifest
new file mode 100644
index ..e9a2ce2398ba
--- /dev/null
+++ b/net-print/cups-browsed/Manifest
@@ -0,0 +1 @@
+DIST cups-browsed-2.0.0.tar.xz 426132 BLAKE2B
e1724c03302d61cf131c8886a95f6ad8f0236b134f1deaadb783fa185141b83cd8ac5c5d993ded37d04c7fd806c5cde157a792a90a2f372075f24a5bd2423dc5
SHA512
592493ef82c65b2418b86b555c4d24bdf352f78516993a021d106240b8c399fd9f4fcc27e396e895d94da889a97f2bbc5e96bfa92c58c8be80802ee8df43db80
diff --git a/net-print/cups-browsed/cups-browsed-2.0.0.ebuild
b/net-print/cups-browsed/cups-browsed-2.0.0.ebuild
new file mode 100644
index ..6baeb697f2cd
--- /dev/null
+++ b/net-print/cups-browsed/cups-browsed-2.0.0.ebuild
@@ -0,0 +1,63 @@
+# Copyright 2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+inherit systemd
+
+DESCRIPTION="helper daemon to browse for remote CUPS queues and IPP network
printers"
+HOMEPAGE="https://github.com/OpenPrinting/cups-browsed;
+SRC_URI="https://github.com/OpenPrinting/cups-browsed/releases/download/${PV}/${P}.tar.xz;
+
+LICENSE="Apache-2.0"
+SLOT="0"
+IUSE="ldap test zeroconf"
+KEYWORDS="~amd64"
+
+RDEPEND="
+ dev-libs/glib:2
+ >=net-print/cups-2
+ >=net-print/cups-filters-2.0.0
+ ldap? ( net-nds/openldap:= )
+ test? ( net-print/cups[zeroconf] )
+ zeroconf? ( net-dns/avahi[dbus] )
+"
+DEPEND="${RDEPEND}"
+BDEPEND="
+ dev-util/gdbus-codegen
+ >=sys-devel/gettext-0.18.3
+ virtual/pkgconfig
+"
+
+PATCHES=(
+ "${FILESDIR}"/0001-cups-browsed.c-Fix-build-with-avahi-disabled-20.patch
+)
+
+src_configure() {
+ local myeconfargs=(
+ --localstatedir="${EPREFIX}"/var
+ --with-browseremoteprotocols=DNSSD,CUPS
+ --with-cups-rundir="${EPREFIX}"/run/cups
+ --with-rcdir=no
+
+ $(use_enable ldap)
+ $(use_enable zeroconf avahi)
+ )
+
+ econf "${myeconfargs[@]}"
+}
+
+src_install() {
+ default
+
+ cp "${FILESDIR}"/cups-browsed.init.d "${T}"/cups-browsed || die
+
+ if ! use zeroconf ; then
+ sed -i -e 's:need cupsd avahi-daemon:need cupsd:g'
"${T}"/cups-browsed || die
+ sed -i -e 's:cups\.service
avahi-daemon\.service:cups.service:g' "${S}"/daemon/cups-browsed.service || die
+ fi
+
+ doinitd "${T}"/cups-browsed
+ systemd_dounit "${S}"/daemon/cups-browsed.service
+
+}
diff --git
a/net-print/cups-browsed/files/0001-cups-browsed.c-Fix-build-with-avahi-disabled-20.patch
b/net-print/cups-browsed/files/0001-cups-browsed.c-Fix-build-with-avahi-disabled-20.patch
new file mode 100644
index ..f72d3919c037
--- /dev/null
+++
b/net-print/cups-browsed/files/0001-cups-browsed.c-Fix-build-with-avahi-disabled-20.patch
@@ -0,0 +1,34 @@
+Upstream:
https://github.com/OpenPrinting/cups-browsed/commit/08af74bfbf9aa8ccab45a2ee74e95951839756ba.patch
+From 08af74bfbf9aa8ccab45a2ee74e95951839756ba Mon Sep 17 00:00:00 2001
+From: Timo Gurr
+Date: Wed, 27 Sep 2023 13:01:46 +0200
+Subject: [PATCH] cups-browsed.c: Fix build with avahi disabled (#20)
+
+Fixes #19
+---
+ daemon/cups-browsed.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/daemon/cups-browsed.c b/daemon/cups-browsed.c
+index b06461b4..c1e64fab 100644
+--- a/daemon/cups-browsed.c
b/daemon/cups-browsed.c
+@@ -400,6 +400,7 @@ typedef struct pagesize_count_s
+ int count;
+ } pagesize_count_t;
+
++#ifdef HAVE_AVAHI
+ typedef struct resolver_args_s
+ {
+ AvahiIfIndex interface;
+@@ -414,6 +415,7 @@ typedef struct resolver_args_s
+ AvahiLookupResultFlags flags;
+ void* userdata;
+ } resolver_args_t;
++#endif // HAVE_AVAHI
+
+ typedef struct create_args_s
+ {
+--
+2.41.0
+
diff --git a/net-print/cups-browsed/metadata.xml
b/net-print/cups-browsed/metadata.xml
new file mode 100644
index ..1b9a77a07ab0
--- /dev/null
+++ b/net-print/cups-browsed/metadata.xml
@@ -0,0 +1,11 @@
+
+https://www.gentoo.org/dtd/metadata.dtd;>
+
+
+ print...@gentoo.org
+ Gentoo Printing Project
+
+
+ OpenPrinting/cups-browsed
+
+
--
2.41.0
[gentoo-dev] [RFC PATCH 03/10] net-print/cups-filters: add 2.0.0
Part of the CUPS v3 evolution. Now, cups-filters has been split out into
multiple sub-packages. The new version of cups-filters depends on a
couple of extracted libraries, and builds on these to distribute the
actual filters. It no longer handles browsed at all -- this is a
completely separate, optional component.
Most options are no longer relevant, as they are encapsulated in the
subpackages.
Signed-off-by: Eli Schwartz
---
net-print/cups-filters/Manifest | 1 +
.../cups-filters/cups-filters-2.0.0.ebuild| 45 +++
2 files changed, 46 insertions(+)
create mode 100644 net-print/cups-filters/cups-filters-2.0.0.ebuild
diff --git a/net-print/cups-filters/Manifest b/net-print/cups-filters/Manifest
index 96b28980e619..3e7f08806c56 100644
--- a/net-print/cups-filters/Manifest
+++ b/net-print/cups-filters/Manifest
@@ -1 +1,2 @@
DIST cups-filters-1.28.17.tar.xz 1516052 BLAKE2B
87258391901d55d9e59b06d54603d014e54d224a373529bd70fcd38cded9dc96c88ca73bcea63d7633c065caea3f9e3274cd450aec5f1bd90130d9a88c0d3421
SHA512
320544a48206165581adafb28dbef58f39c66bebd3641be3d180a692605349d9e6af6d464044db9f7bda17a67f4a079370d8cc880cd7873d684b2209882deb35
+DIST cups-filters-2.0.0.tar.xz 447648 BLAKE2B
be5e2aab4eb921aa67bfcc93aa5f95a9f1fe1a269ed73d18273a0e9a3e816187e9e32750ba6521c3ab083c3c7b7a60bb1fa679e16d4a5917f911a4ba8d4b7207
SHA512
fc8ba3bbf92d5ede295884023d1c42422c4c250dbbf21c948f160a04ded3259784df4bd17eea64492f9417f866e566be1a9fcde47d29655cd4204ef4cc7af134
diff --git a/net-print/cups-filters/cups-filters-2.0.0.ebuild
b/net-print/cups-filters/cups-filters-2.0.0.ebuild
new file mode 100644
index ..fde6177f0322
--- /dev/null
+++ b/net-print/cups-filters/cups-filters-2.0.0.ebuild
@@ -0,0 +1,45 @@
+# Copyright 2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+DESCRIPTION="Cups filters"
+HOMEPAGE="https://wiki.linuxfoundation.org/openprinting/cups-filters;
+SRC_URI="https://github.com/OpenPrinting/cups-filters/releases/download/${PV}/${P}.tar.xz;
+
+LICENSE="Apache-2.0"
+SLOT="0"
+IUSE="+foomatic"
+#IUSE=""
+KEYWORDS="~amd64"
+
+RDEPEND="
+ net-print/libcupsfilters
+ net-print/libppd
+ >=net-print/cups-1.7.3
+"
+DEPEND="${RDEPEND}"
+BDEPEND="
+ >=sys-devel/gettext-0.18.3
+ virtual/pkgconfig
+"
+
+src_configure() {
+ local myeconfargs=(
+ --enable-imagefilters
+ --enable-driverless
+ --enable-poppler
+ --localstatedir="${EPREFIX}"/var
+ --with-fontdir="fonts/conf.avail"
+ # cups-browsed is split out and avahi is not needed for filters
+ # https://github.com/OpenPrinting/cups-filters/pull/558
+ --disable-avahi
+ # These are just probed for the path. Always enable them.
+ --with-gs-path="${EPREFIX}"/usr/bin/gs
+ --with-mutool-path="${EPREFIX}"/usr/bin/mutool
+
+ $(use_enable foomatic)
+ )
+
+ econf "${myeconfargs[@]}"
+}
--
2.41.0
[gentoo-dev] [RFC PATCH 02/10] net-print/libppd: new package, add 2.0.0
Part of the CUPS v3 evolution. Now, cups-filters has been split out into
multiple sub-packages. This is the legacy PPD filters core library.
Signed-off-by: Eli Schwartz
---
net-print/libppd/Manifest| 1 +
net-print/libppd/libppd-2.0.0.ebuild | 52
net-print/libppd/metadata.xml| 14
3 files changed, 67 insertions(+)
create mode 100644 net-print/libppd/Manifest
create mode 100644 net-print/libppd/libppd-2.0.0.ebuild
create mode 100644 net-print/libppd/metadata.xml
diff --git a/net-print/libppd/Manifest b/net-print/libppd/Manifest
new file mode 100644
index ..bc6ba554c08c
--- /dev/null
+++ b/net-print/libppd/Manifest
@@ -0,0 +1 @@
+DIST libppd-2.0.0.tar.xz 580716 BLAKE2B
8505c5ab5b515104308624a8f78505343b894df08ab8ac2727d7bd82d0d65d256d22ecaf384b212d9a5c45d2a619a6311722a8c5ed954b7a8a9780477aedb458
SHA512
8be9e67552528606fd804ba13b05710938ed7d02316c1c902ee657bc0e5fade663ffacb5b032609a1c1fdc80d976e7e54d2ca2f71db83cb8fdcee6a371e6bad4
diff --git a/net-print/libppd/libppd-2.0.0.ebuild
b/net-print/libppd/libppd-2.0.0.ebuild
new file mode 100644
index ..174c775a213f
--- /dev/null
+++ b/net-print/libppd/libppd-2.0.0.ebuild
@@ -0,0 +1,52 @@
+# Copyright 2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+DESCRIPTION="Legacy library for PPD files, split out of cups-filters"
+HOMEPAGE="https://github.com/OpenPrinting/libppd;
+SRC_URI="https://github.com/OpenPrinting/libppd/releases/download/${PV}/${P}.tar.xz;
+
+LICENSE="Apache-2.0"
+SLOT="0"
+IUSE="+postscript +poppler"
+KEYWORDS="~amd64"
+
+# pdftops has various possible implementations, but the default
+# really needs to be decent
+REQUIRED_USE="|| ( postscript poppler )"
+
+RDEPEND="
+ >=net-print/cups-2
+ net-print/libcupsfilters
+ !=app-text/ghostscript-gpl-9.09[cups] )
+ poppler? ( >=app-text/poppler-0.32[utils] )
+"
+DEPEND="${RDEPEND}"
+BDEPEND="
+ >=sys-devel/gettext-0.18.3
+ virtual/pkgconfig
+"
+
+src_configure() {
+ local myeconfargs=(
+ --localstatedir="${EPREFIX}"/var
+ --with-cups-rundir="${EPREFIX}"/run/cups
+ # This does build time checks for (preferred) tool interfaces.
+ $(use_enable postscript ghostscript)
+ $(use_enable poppler pdftops)
+ # These fallbacks are just probed for the path. Always enable
them.
+ --with-mutool-path="${EPREFIX}"/usr/bin/mutool
+ --with-pdftocairo-path="${EPREFIX}"/usr/bin/pdftocairo # from
poppler
+ # unpackaged
+ --disable-acroread
+ )
+
+ econf "${myeconfargs[@]}"
+}
+
+src_install() {
+ default
+ find "${ED}" -name '*.la' -delete || die
+}
diff --git a/net-print/libppd/metadata.xml b/net-print/libppd/metadata.xml
new file mode 100644
index ..67a6452ca268
--- /dev/null
+++ b/net-print/libppd/metadata.xml
@@ -0,0 +1,14 @@
+
+https://www.gentoo.org/dtd/metadata.dtd;>
+
+
+ print...@gentoo.org
+ Gentoo Printing Project
+
+
+ Use the app-text/poppler
pdftops filter
+
+
+ OpenPrinting/libppd
+
+
--
2.41.0
[gentoo-dev] [RFC PATCH 01/10] net-print/libcupsfilters: new package, add 2.0.0
Part of the CUPS v3 evolution. Now, cups-filters has been split out into
multiple sub-packages. This is the core library.
Signed-off-by: Eli Schwartz
---
net-print/libcupsfilters/Manifest | 1 +
.../libcupsfilters-2.0.0.ebuild | 60 +++
net-print/libcupsfilters/metadata.xml | 14 +
3 files changed, 75 insertions(+)
create mode 100644 net-print/libcupsfilters/Manifest
create mode 100644 net-print/libcupsfilters/libcupsfilters-2.0.0.ebuild
create mode 100644 net-print/libcupsfilters/metadata.xml
diff --git a/net-print/libcupsfilters/Manifest
b/net-print/libcupsfilters/Manifest
new file mode 100644
index ..9145aecf6f6d
--- /dev/null
+++ b/net-print/libcupsfilters/Manifest
@@ -0,0 +1 @@
+DIST libcupsfilters-2.0.0.tar.xz 1279856 BLAKE2B
ce9d839bb700017c303c1301c7a97fd02e3657a908e685377be49557d995574a7fc5a31d4fcbda5eeb9ba2d3cd07858224540dbf0bc9fa078cfd25a58ee15a41
SHA512
279bff6dcfa76312b10dae97480914345defd90eab79c4716d4553870f73e0f9db404786fd7e2948a86ae5aedb10dca0c2984ccb4222acbd4e835cd572030d6a
diff --git a/net-print/libcupsfilters/libcupsfilters-2.0.0.ebuild
b/net-print/libcupsfilters/libcupsfilters-2.0.0.ebuild
new file mode 100644
index ..511d423289b8
--- /dev/null
+++ b/net-print/libcupsfilters/libcupsfilters-2.0.0.ebuild
@@ -0,0 +1,60 @@
+# Copyright 2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+DESCRIPTION="library for developing printing features, split out of
cups-filters"
+HOMEPAGE="https://github.com/OpenPrinting/libcupsfilters;
+SRC_URI="https://github.com/OpenPrinting/libcupsfilters/releases/download/${PV}/${P}.tar.xz;
+
+LICENSE="Apache-2.0"
+SLOT="0"
+IUSE="dbus exif jpeg pdf +poppler +postscript png test tiff"
+KEYWORDS="~amd64"
+
+RESTRICT="!test? ( test )"
+
+RDEPEND="
+ >=app-text/qpdf-8.3.0:=
+ media-libs/fontconfig
+ media-libs/lcms:2
+ >=net-print/cups-2
+ !=app-text/poppler-0.32[cxx] )
+ png? ( media-libs/libpng:= )
+ tiff? ( media-libs/tiff:= )
+"
+DEPEND="${RDEPEND}"
+BDEPEND="
+ >=sys-devel/gettext-0.18.3
+ virtual/pkgconfig
+ test? ( media-fonts/dejavu )
+"
+
+src_configure() {
+ local myeconfargs=(
+ --enable-imagefilters
+ --localstatedir="${EPREFIX}"/var
+ --with-cups-rundir="${EPREFIX}"/run/cups
+
+ $(use_enable exif)
+ $(use_enable dbus)
+ $(use_enable poppler)
+ $(use_enable postscript)
+ $(use_enable pdf mutool)
+ $(use_with jpeg)
+ $(use_with png)
+ $(use_with tiff)
+ )
+
+ econf "${myeconfargs[@]}"
+}
+
+src_install() {
+ default
+ find "${ED}" -name '*.la' -delete || die
+}
diff --git a/net-print/libcupsfilters/metadata.xml
b/net-print/libcupsfilters/metadata.xml
new file mode 100644
index ..d31059e1c097
--- /dev/null
+++ b/net-print/libcupsfilters/metadata.xml
@@ -0,0 +1,14 @@
+
+https://www.gentoo.org/dtd/metadata.dtd;>
+
+
+ print...@gentoo.org
+ Gentoo Printing Project
+
+
+ Build the pdftoraster filter
+
+
+ OpenPrinting/libcupsfilters
+
+
--
2.41.0
[gentoo-dev] [RFC PATCH 00/10] Upgrading cups-filters to 2.0.0
I've been working with Sam for a bit on this update. It's a bit of a fiddly one, as a lot of stuff has changed upstream. It's probably best described via my proposed news post. Please review. It would also be quite nice to get a bit of testing -- I'm especially concerned about cups-browsed's testsuite, so if anyone has any ideas how to actually run it, that would be fantastic. I do not use cups-browsed myself... News post: - Title: CUPS no longer directly depends on its filters Author: Eli Schwartz Posted: 2023-11-20 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: <=net-print/cups-2.4.7-r1 Reasons === Historically, net-print/cups has both depended on and been a dependency of net-print/cups-filters. The latter is required for usability of a CUPS printing setup, but also must build against the former's libraries. This results in an ugly dependency cycle, and forcing the entire CUPS printing setup wherever USE=cups is enabled on a framework. Current upstream work on CUPS has focused on modularizing the codebase. There are now several packages, and there will be more in the future. Installing net-print/cups-filters is no longer sufficient to ensure all components are installed. In the future, when CUPS v3 is released, filters will be exclusive to legacy printers, and largely replaced with IPP Everywhere.[1] A more future-proof way to install a CUPS production printing setup is needed. User Action Required === cups-filters is required for current versions of CUPS. To prevent depcleaning if you are a CUPS user (and it was not installed just as a dependency for something else): emerge net-print/cups-meta If cups-browsed support is desired, add the following package.use: net-print/cups-meta browsed [1] https://openprinting.github.io/current/#the-new-architecture-for-printing-and-scanning Eli Schwartz (10): net-print/libcupsfilters: new package, add 2.0.0 net-print/libppd: new package, add 2.0.0 net-print/cups-filters: add 2.0.0 net-print/cups-browsed: new package, add 2.0.0 net-print/cups-meta: new package, add 1 net-print/cups: drop cyclic dependency on cups-filters net-print/cups: re-enable tests net-print/cups: avoid running unittests in src_compile net-print/cups-browsed: restrict tests net-print/cups-filters: restrict tests net-print/cups-browsed/Manifest | 1 + .../cups-browsed/cups-browsed-2.0.0.ebuild| 82 + ...d.c-Fix-build-with-avahi-disabled-20.patch | 34 ++ net-print/cups-browsed/metadata.xml | 11 + net-print/cups-filters/Manifest | 1 + .../cups-filters/cups-filters-2.0.0.ebuild| 54 +++ net-print/cups-meta/cups-meta-1.ebuild| 21 ++ net-print/cups-meta/metadata.xml | 9 + net-print/cups/cups-2.4.7-r2.ebuild | 320 ++ net-print/libcupsfilters/Manifest | 1 + .../libcupsfilters-2.0.0.ebuild | 60 net-print/libcupsfilters/metadata.xml | 14 + net-print/libppd/Manifest | 1 + net-print/libppd/libppd-2.0.0.ebuild | 52 +++ net-print/libppd/metadata.xml | 14 + 15 files changed, 675 insertions(+) create mode 100644 net-print/cups-browsed/Manifest create mode 100644 net-print/cups-browsed/cups-browsed-2.0.0.ebuild create mode 100644 net-print/cups-browsed/files/0001-cups-browsed.c-Fix-build-with-avahi-disabled-20.patch create mode 100644 net-print/cups-browsed/metadata.xml create mode 100644 net-print/cups-filters/cups-filters-2.0.0.ebuild create mode 100644 net-print/cups-meta/cups-meta-1.ebuild create mode 100644 net-print/cups-meta/metadata.xml create mode 100644 net-print/cups/cups-2.4.7-r2.ebuild create mode 100644 net-print/libcupsfilters/Manifest create mode 100644 net-print/libcupsfilters/libcupsfilters-2.0.0.ebuild create mode 100644 net-print/libcupsfilters/metadata.xml create mode 100644 net-print/libppd/Manifest create mode 100644 net-print/libppd/libppd-2.0.0.ebuild create mode 100644 net-print/libppd/metadata.xml -- 2.41.0
Re: [gentoo-dev] [PATCH] use.desc: Make `native-extensions` flag global
On 11/5/23 1:42 AM, Michał Górny wrote: > Make the `native-extensions` flag global. It is used in 15 Python > packages to enable building optional C extensions, though the global > description also allows for other "native" and "pure" languages. > > In 9 cases, the flag description explicitly mentions "speedups", so this > is the primary case used in global description. There is one case > of the extension providing extra features, and the remaining cases > do not explain its role. The USE flag's name inherently feels like something aligned with building speedups, so why not dedicate it to that purpose? It feels confusing to have a global USE that does different things for different packages. It sounds like just renaming a single USE flag -- peewee from "native-extensions" to "sqlite-ext" -- would be enough to allow nicer semantics here. -- Eli Schwartz
Re: [gentoo-dev] Re: Last rites: media-gfx/gmic
On 10/25/23 9:29 PM, Jonas Stein wrote: > Hi Marecki, > > this is a very powerful package with many users. > Thank you for maintaining it till now. > > 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. > > 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. > > I suggest to keep it for a few more months. It's difficult to tell whether the problems were reported upstream since upstream has deleted the repository and purged all issues, PRs, commits, tags, and anything else whatsoever back in April. The commit message is elucidative: "Clean repository". Per https://github.com/GreycLab/gmic/issues/1#issuecomment-1521421747 """ Yes, my fault. I've completely messed up (mainly because I'm still a git novice after all these years!). I had to delete/recreate the repository from scratch. """ This is of course either untrue or every kind of over-reaction, and users have commented there to the effect of being willing to help sort things out but there has been radio silence. It is long past the 90 days where outright github-level recovery is possible. I think this also offers some compelling arguments against maintainers being willing to deal with the challenges of this software -- this is a pretty steep social cost to investing time and effort into caring about, using, or maintaining such software. I suppose it's always possible to orphan the package and let it rot until it gets last-rited for not working. Marecki -- is there any specific concern that it's likely to rot quickly if it lacks a maintainer? -- Eli Schwartz
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
On 9/13/23 9:10 AM, Michael Orlitzky wrote: > On Tue, 2023-09-12 at 22:52 -0400, Eli Schwartz wrote: >> >> Is portage generally expected to successfully complete (including >> internal metadata write stages) when its workdir drive runs out of space >> partway through? >> > > No, but I think what everyone else is forgetting to mention is that if > it's going to fail, we want it to fail as soon as possible, i.e. as > close to the thing that actually went wrong. If we proceed past ENOSPC > or whatever, we could get five or six lines further in the ebuild, and > then some other command will fail but possibly with a crazy unrelated > error message. The consequences of this particular command failing are that: - setuptools will still build, but without spawning a ThreadPoolExecutor to distribute jobs; it builds single threaded - setuptools will still build, but using its default build directory instead of an alternative one; setuptools itself *cannot* fail as a result, but other external commands hardcoding the location of setuptools internal files could fail to find those files (It will still fail when setuptools reports its own ENOSPC, but this is not a crazy unrelated error message.) (Unless portage expects to successfully complete where possible if the workdir drive runs out of space partway through, then quickly has more space freed up for it as soon as monitoring warnings are triggered and no actually-fatal ebuild errors occurred during the window of ENOSPC.) -- Eli Schwartz
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
On 9/13/23 5:27 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 13 Sep 2023, Eli Schwartz wrote:
>
>>> "|| 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.
>
> That's a rather bold statement. I can imagine a number of possible
> failures, e.g. no space left on device, quota exceeded, or a low-level
> I/O error of the filesystem. Also fork or exec of the cat command could
> fail (e.g. out of memory).
>
> While either of these may be unlikely here, best practice is to check
> for errors of _all_ external commands.
The implementation of `die` performs a fork+exec of the sed command,
invokes eerror (many times!) which forks to pipe, invokes $() which
forks, and could behave abnormally due to out of memory. It is not safe
to treat `|| die` as error recovery for an out of memory condition.
The implementation of `die` performs multiple writes to files inside of
${PORTAGE_BUILDDIR}, and could behave abnormally due to write failures.
It is not safe to treat `|| die` as error recovery for a write failure
of the ${PORTAGE_BUILDDIR} drive (whatever the reason for that write
failure).
Regarding:
- no space left on device
- quota exceeded
- low-level I/O error of the filesystem
this isn't "a number of possible failures" :) it is the same failure but
elicited by different prompts. Regarding this, I have already commented...
(And the `|| die` is added to the next revision of this patch either way.)
--
Eli Schwartz
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23 1:03 AM, Alexe Stefan wrote: > On 9/13/23, Eli Schwartz wrote: >> On 9/13/23 12:35 AM, Alexe Stefan wrote: >>> On 9/13/23, Matt Turner wrote: >>>> On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan >>>> wrote: >>>>> Is it such a burden to make a couple of commits once in a while? >>>> >>>> I see no commits from your email address in gentoo.git, so that might >>>> be a question for you. >>>> >>> >>> I and plenty of others have their overlays. Should I try to get my >>> ebuilds into ::gentoo? >> >> >> That seems to be rather missing the point. Why are you going out of your >> way to make a distinction between: >> >> - contributing ebuilds that would otherwise not be present in ::gentoo >> at all >> >> - helping fix issues in existing ebuilds that are part of ::gentoo and >> need to be kept in good working order >> >> Both are valid ways to demonstrate a commitment to collaboratively >> improving the Gentoo project. The one you *didn't* mention is easier to >> do, though, so I'd probably suggest trying that first. >> > > I do open bugs and threads about various issues regarding packages, > and propose solutions. Sometimes their gentoo maintainers agree, > sometimes they don't. What else should I do? I don't have commit > access. I am not sure what you're saying here. If you don't have commit access, how do you intend to get your ebuilds into ::gentoo? If you don't need commit access to get your ebuilds into ::gentoo, then what's stopping you from getting your patches against existing ebuilds into ::gentoo? Given that you were originally responding to Matt's remark that you have no commits in ::gentoo associated with your email address, I am merely pointing out that you are performing a bit of self-gatekeeping by interpreting this as "my ebuilds" rather than "my code contributions". If you propose solutions, do you include a demonstration patch to apply against ::gentoo that implements your proposed solution? Because that would make it very easy to have those solutions become associated with you. :) >>>>> How many commits were made in the last year to accommodate eudev? >>>> >>>> I'm not your monkey. >>>> >>>>> Regarding the bugs, what else did you expect when no news item was >>>>> given? >>>> >>>> Right, we should have done something *else* to keep eudev going. >>>> >>>> Welcome to my killfile. >>>> >>>> >>> >>> Something I said in this thread struck a chord? >> >> >> I think it's a very fair assessment to make that this thread is quite >> hostile to the Gentoo Developers as a whole, and hostile behavior >> towards the Gentoo Developers does indeed strike a chord. >> >> I am not completely sure why you find it important or desirable to >> highlight the fact that you elicit strong negative emotions in others, >> mind you. But I'm sure you have very good reasons for it. >> >> >> -- >> Eli Schwartz >> >> >> > > I don't think I said anything about you? > I do not like to see choice being taken away for no good reason, > especially in regards to such a contested topic. And I don't like signing up to this mailing list in order to email in a patch against ::gentoo to improve the speed of compilation for python libraries and make them more easily tested and debuggable, and getting my inbox filled with a bunch of yelling, hateful people who go around insulting the hard work of the Gentoo Developers, complaining that they didn't put in even MORE hard work, and figuratively screaming to the heavens about how it's a conspiracy to deny choice. You, in particular, even admitted you don't use eudev! But you're still more than happy to pontificate about how it's, I dunno, the most useful thing since sliced bread, or so I assume from the absolute moaning and wailing and gnashing of teeth about its removal. And you call it a contested topic! Contested by people who don't use it and are only contesting it in order to stir up trouble! And not content to stick with pontificating about how useful the philosophical concept of choice between two copies of the same code with different marketing names that you don't even use is, you have to describe it as > intentional crippling of systemd alternatives > regardless of how much money changes hands (???) > Do devs receive prizes based on how many useful packages they remove? > Don't answer that, we all already know the answer. (lmao) > most of those bugs were listed in the mask comment just to > increase the number of open bugs. I start to wonder: given you appear to despise the Gentoo Project with an almighty hatred, why do you use the darned thing anyway. It's a conspiracy to torment you and deny you choice, the Developers are getting secretly paid to remove packages that disagree with the New World Order of systemd, blah blah blah. Clearly Gentoo just has it in for you, so you'd better escape before it's too late. Can you please just not do this? -- Eli Schwartz
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/13/23 12:35 AM, Alexe Stefan wrote: > On 9/13/23, Matt Turner wrote: >> On Tue, Sep 12, 2023 at 5:45 PM Alexe Stefan >> wrote: >>> Is it such a burden to make a couple of commits once in a while? >> >> I see no commits from your email address in gentoo.git, so that might >> be a question for you. >> > > I and plenty of others have their overlays. Should I try to get my > ebuilds into ::gentoo? That seems to be rather missing the point. Why are you going out of your way to make a distinction between: - contributing ebuilds that would otherwise not be present in ::gentoo at all - helping fix issues in existing ebuilds that are part of ::gentoo and need to be kept in good working order Both are valid ways to demonstrate a commitment to collaboratively improving the Gentoo project. The one you *didn't* mention is easier to do, though, so I'd probably suggest trying that first. >>> How many commits were made in the last year to accommodate eudev? >> >> I'm not your monkey. >> >>> Regarding the bugs, what else did you expect when no news item was given? >> >> Right, we should have done something *else* to keep eudev going. >> >> Welcome to my killfile. >> >> > > Something I said in this thread struck a chord? I think it's a very fair assessment to make that this thread is quite hostile to the Gentoo Developers as a whole, and hostile behavior towards the Gentoo Developers does indeed strike a chord. I am not completely sure why you find it important or desirable to highlight the fact that you elicit strong negative emotions in others, mind you. But I'm sure you have very good reasons for it. -- Eli Schwartz
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/12/23 3:47 PM, Eddie Chapman wrote: > Andreas K. Huettel wrote: >> The eudev experiment has failed. >> * It was false labeling from the start.[*] >> * It's barely alive and not keeping up with udev upstream. > > Why does it have to? It is advertised as a fork after all. It provides libudev.pc; this means that it is either engaged in deceptive and malicious false advertising, or... ... it is intended to provide compatibility with udev. Hint: it is intended to provide compatibility with udev. But, it does so with an OLD version of udev. Other projects throughout the Linux ecosystem may depend on libudev.pc to provide API services; they have the right to use the advertised API of libudev.pc (and depend on a suitable version of it), but eudev cannot fulfill this contract as used by projects which e.g. use the sticky-tags API. Thus, eudev is failing its goal to be a compatible replacement, because it is not keeping up with udev upstream. >> * It's effectively unmaintained in Gentoo. > > That could change. Isn't that why a last rite comes with 30 days notice? Your question is a fallacy. Why are you pretending that the person you are replying to has claimed it isn't going to change? The person you are replying to is describing the current state of affairs that led to the last rite. Who are you arguing against? >> * You don't gain anything from using it instead of udev. >> (Nobody does.) > > Is there only 1 tool for the job? Why do we have both the OpenIPMI and > ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it be > better if we just choose one of each of those pairs and concentrate on it? This isn't a fallacy -- it has progressed onwards and is now a mendacious, twisting attempt at deception. For the benefit of other people reading this discussion -- Firefox and Chrome are vastly different programs, providing vastly different tools, that both share a fairly vague, general domain (open web pages). wget and curl, or openIPMI and ipmitool, are less extreme examples of this general concept: they are different tools taking different approaches to perform a somewhat more specific task, with pros and cons of each approach. eudev does not provide distinct functionality, which leads us on to... >> >> So why should anyone put up the effort to package it? > > Same question for the above choices and plenty of other examples. > > What's wrong with having an alternative purely for competition? > >> [*] Take something out of the systemd tarball, reapply every commit, >> make tiny changes so it looks different, > > That's basically how most forks start isn't it? There are two problems with this statement. The first is that it's wrong, that's not how most forks start. The second is that you used the word "start", without perhaps realizing that starts usually come with an afterwards that is distinguished from the start by not being the start. But let's discuss what it means to fork software. There's a few different reasons why a software project might fork: - the maintainers of the project lost (or never possessed) legal control over the trademark to some corporate interest, and "fork" their own project to a new name due to abuse against users by said corporate interest, in order to reform the community and carry on their operations as normal. Examples: Sun OpenOffice.org -> LibreOffice. In non-software, Freenode becoming Libera.Chat - a project dies because its sole maintainer(s) disappear and cannot be contacted or are unresponsive w.r.t. the project. The community forks, changes its name, and arranges a new development team to "carry on the torch" in memory of the old project. Example: TrueCrypt -> VeraCrypt - a project has some end-user functionality proposed, and rejected. The people who want that feature decide to make their own project, based on the first project but with all their favorite features instead of the first project's favorite features. They take the codebase and start making lots of changes to implement end-user functionality which they enjoy, and and the first project makes lots of changes that *they* enjoy. Rapidly, it becomes increasingly difficult to find changes from one that are relevant to the other. Example: gnome vs. cinnamon desktop - a project changes in ways that some users are unhappy about, and those users create a fork that's exactly the same as the first project, but "with X removed", and which regularly syncs with the first project to retrieve desired features while excluding undesired features. The third case is what most people think of when they talk about forks. eudev is the fourth case, as its stated goal is to be "a fork of systemd", with the motivation of "isolating udev from [...] systemd". eudev lacks mission independence, its driving goal is to accomplish the same aims as systemd-udev except modularizing it well enough that it is neutral regarding the init system you are running as
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
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?
--
Eli Schwartz
Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
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. (mkdir -p will return nonzero and die, if it exits
without having guaranteed its target is a directory on disk. There is
one loophole, and that is if its target already existed beforehand, but
the mkdir -p process did not have write permissions for it; mkdir will
not check permissions if it detects it doesn't have to do work. This
should not be the case inside the workdir, or something has gone
significantly wrong beforehand.)
That being said, as a style guide concern I can see why being cautious
is generally desirable, as it's much easier to review code that uses it
when it isn't strictly necessary than code that doesn't use it when it
turns out to be necessary.
I'm not very used to this yet :) so I blindly assumed while writing it
that it wasn't necessary to do some additional typing and add this for
call sites that shouldn't be able to fail. I will add this in the next
revision.
--
Eli Schwartz
Re: [gentoo-dev] last rites: sys-fs/eudev
On 9/12/23 3:05 PM, orbea wrote: On Tue, 12 Sep 2023 14:51:34 -0400 Matt Turner wrote: Conspiracy alert! It's been more than 2 years since https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html People have had plenty of time. More chances than were fair have been given. Nothing has changed, except eudev has further diverged from upstream udev. Unfortunately this flew under the radar for a lot of people, when I asked Sam about this on irc a while ago I was informed (As I understood) that eudev was still going to be an option into the future and as the ebuild was still getting updates I never considered this is how the core Gentoo devs felt. It sounds to me like the last-rite system has worked and achieved the desired goal then. It is no longer flying under the radar, and for people who use eudev and wish to see it be a supported option, a fire has been lit under them to get involved. Do keep in mind that based on commit history the only person that cares about eudev at all for years now is Sam, and that's apparently out of mere obligation. He is not listed as an eudev project member or package maintainer, the actual eudev project should likely acknowledge reality and disband in order to more effectively communicate their intent. None of this is or ever was sustainable -- do not expect people who don't use a thing, aren't willing to maintain a thing, but intercede out of obligation to be an effective maintainer or be willing to do so in perpetuity. If I had to take a wild guess, "it is still going to be an option into the future" actually meant "we aren't ready to treeclean it yet, people still use it, so we're gonna see how low-effort it is to keep it limping along without any maintainers but also maybe someone would like to maintain it". Sure enough, the total lack of gentoo maintainers for this package meant that once people who were engaging with ebuild updates *purely* out of a sense of obligation could no longer justify continuing to do so when the package wasn't compatible with its reverse dependencies, those people decided that it was time to step down. It's great to see people who do care and actually use the software, step up in their place. -- Eli Schwartz
[gentoo-dev] [PATCH 2/2] python-utils-r1.eclass: unconditionally warn on occluded packages in cwd
If the current directory masks packages that would be installed and
contains different contents, it can cause testing issues that otherwise
go unnoticed. This warning can stop being experimental and opt-in
Suggested-by: Michał Górny
Signed-off-by: Eli Schwartz
---
eclass/python-utils-r1.eclass | 4
1 file changed, 4 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index bd30c1203180..50aeabae1c17 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1242,10 +1242,6 @@ _python_check_EPYTHON() {
_python_check_occluded_packages() {
debug-print-function ${FUNCNAME} "${@}"
- # DO NOT ENABLE THIS unless you're going to check for false
- # positives before filing bugs.
- [[ ! ${PYTHON_EXPERIMENTAL_QA} ]] && return
-
[[ -z ${BUILD_DIR} || ! -d ${BUILD_DIR}/install ]] && return
local sitedir="${BUILD_DIR}/install$(python_get_sitedir)"
--
2.41.0
[gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options
Previously, setup.py was handled by:
- manually passing makejobs, with a heuristic to guess whether it was a
time saver to do so.
- rm -rf'ing the build directory in between python versions to prevent
cross-version contamination
This is because in PEP 517 mode, it doesn't accept build options
specific to a setuptools phase. So a crude hack is to just build_ext
twice, once explicitly and once internally as part of bdist_wheel, and
pray that in the latter case it detects that there's nothing to do.
Unfortunately, sometimes build_ext does NOT detect that there is nothing
to do -- e.g. for codegen tools such as mypyc, that produce *.c files
which are different every time you try building. As for build
directories, those were given up on as hopeless.
There's a better hack which is to set a magic environment variable for a
setup.cfg file which is parsed additionally to the one provided by the
project. It can contain additional settings, such as the build-base and
parallelism, which means that bdist_wheel intrinsically builds
extensions in parallel the only time it is called. And we can set the
output directory for all build artifacts to outside of the source tree,
so it is no longer necessary to delete them (which among other things,
makes debugging difficult).
This is similar to .pydistutils.cfg, but is processed later and can be
in arbitrary locations. Since we store it in the per-impl build
directory we don't need to wipe it after using it to avoid leakage.
Signed-off-by: Eli Schwartz
---
eclass/distutils-r1.eclass | 48 --
1 file changed, 10 insertions(+), 38 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 91de144e1110..dd197a5f0693 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1461,12 +1461,6 @@ distutils_pep517_install() {
[[ -n ${wheel} ]] || die "No wheel name returned"
distutils_wheel_install "${root}" "${WHEEL_BUILD_DIR}/${wheel}"
-
- # clean the build tree; otherwise we may end up with PyPy3
- # extensions duplicated into CPython dists
- if [[ ${DISTUTILS_USE_PEP517:-setuptools} == setuptools ]]; then
- rm -rf build || die
- fi
}
# @FUNCTION: distutils-r1_python_compile
@@ -1478,9 +1472,6 @@ distutils_pep517_install() {
#
# If DISTUTILS_USE_PEP517 is set to any other value, builds a wheel
# using the PEP517 backend and installs it into ${BUILD_DIR}/install.
-# May additionally call build_ext prior to that when using setuptools
-# and the eclass detects a potential benefit from parallel extension
-# builds.
#
# In legacy mode, runs 'esetup.py build'. Any parameters passed to this
# function will be appended to setup.py invocation, i.e. passed
@@ -1495,40 +1486,21 @@ distutils-r1_python_compile() {
# call setup.py build when using setuptools (either via
PEP517
# or in legacy mode)
- if [[ ${DISTUTILS_USE_PEP517} ]]; then
- if [[ -d build ]]; then
- eqawarn "A 'build' directory exists
already. Artifacts from this directory may"
- eqawarn "be picked up by setuptools
when building for another interpreter."
- eqawarn "Please remove this directory
prior to building."
- fi
- else
- _distutils-r1_copy_egg_info
- fi
-
# distutils is parallel-capable since py3.5
local jobs=$(makeopts_jobs "${MAKEOPTS} ${*}")
if [[ ${DISTUTILS_USE_PEP517} ]]; then
- # issue build_ext only if it looks like we have
at least
- # two source files to build; setuptools is
expensive
- # to start and parallel builds can only benefit
us if we're
- # compiling at least two files
- #
- # see extension.py for list of suffixes
- # .pyx is added for Cython
- #
- # esetup.py does not respect SYSROOT, so skip
it there
- if [[ -z ${SYSROOT} && ${DISTUTILS_EXT} && 1
-ne ${jobs}
- && 2 -eq $(
- find '(' -name '*.c' -o -name
'*.cc' -o -name '*.cpp' \
- -o -name '*.cxx' -o
-name '*.c++' -o -name '*.m' \
- -o -name '*.mm' -o
-name '*.pyx
