[gentoo-dev] Last rites: dev-python/sphinxcontrib-newsfeed

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# No py3.12, no tests, no maintainer.  Also no revdeps.
# Removal on 2024-05-23.  Bug #929513.
dev-python/sphinxcontrib-newsfeed

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/pytest-faulthandler

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Integrated into >=dev-python/pytest-5.0.  No revdeps.
# Removal on 2024-05-23.  Bug #929496.
dev-python/pytest-faulthandler

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/pyannotate

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Broken with py3.12.  Last commit upstream in 2021.  No revdeps.
# Removal on 2024-05-23.  Bug #929484.
dev-python/pyannotate

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/kafka-python

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# No py3.12, broken.  Upstream literally tells people to use a fork
# "for the time being".  No revdeps.
# Removal on 2024-05-23.  Bug #929461.
dev-python/kafka-python

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/cgroup-utils

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Unmaintained.  No py3.12, failing tests.  Last upstream activity
# in 2020, triggered by our previous last rites.  No revdeps.
# Removal on 2024-05-23.  Bug #929445.
dev-python/cgroup-utils

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/guzzle_sphinx_theme

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Unmaintained Sphinx theme.  Last commit in 2021.  No revdeps.
# Removal on 2024-05-23.  Bug #929458.
dev-python/guzzle_sphinx_theme

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/fuse-python

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Unmaintained in Gentoo.  Lacking tests, py3.12 support, outdated.
# No revdeps.  The alternatives are dev-python/{llfuse,pyfuse3}.
# Removal on 2024-05-23.  Bug #929453.
dev-python/fuse-python

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Unmaintained.  Last release in 2003.  Carries a ton of patches.
# Removal on 2024-05-23.  Bug #928731.
net-analyzer/tcpstat

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: media-video/vstrip

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Added in 2005 and not updated since.  Homepage and source mirrors
# are gone.  Needs patches to even build.
# Removal on 2024-05-23.  Bug #928594.
media-video/vstrip

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: net-im/librvp

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Obsolete Pidgin plugin.  Last supported in 2008, removed from plugin
# list in 2019.
# Removal on 2024-05-23.  Bug #928578.
net-im/librvp

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: media-sound/pitchtune

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Unmaintained GTK+2 application.  Last update in 2005.
# Alternatives include media-sound/fmit and media-sound/lingot.
# Removal on 2024-05-23.  Bug #928512.
media-sound/pitchtune

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Ancient.  Homepage gone.  There are many alternative network testing
# tools, such as net-misc/iperf.
# Removal on 2024-05-23.  Bug #928133.
net-analyzer/gensink

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/sphinx-py3doc-enhanced-theme

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# An old, unmaintained theme.  The last revdep stopped using it.
# Removal on 2024-05-23.  Bug #927764.
dev-python/sphinx-py3doc-enhanced-theme

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-util/android-ndk

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Unmaintained in Gentoo and seriously outdated.  EAPI 6.  No revdeps.
# There seem to be an up-to-date ebuilds in ::mva.
# Removal on 2024-05-23.  Bug #928070.
dev-util/android-ndk

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: app-forensics/libewf

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Unmaintained in Gentoo and seriously outdated.  Its only reverse
# dependency is app-admin/testdisk, and the current TestDisk versions
# do not build against this version anyway
# Removal on 2024-05-23.  Bug #927076.
app-forensics/libewf

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/tinycss

2024-04-23 Thread Michał Górny
# Michał Górny  (2024-04-23)
# Superseded by dev-python/tinycss2.  No revdeps.
# Removal on 2024-05-23.  Bug #930503.
dev-python/tinycss

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Package up for grabs: net-p2p/eiskaltdcpp

2024-04-21 Thread Michał Górny
Hi,

Due to the maintainer being retired, the following package is now
looking for a new maintainer:

  net-p2p/eiskaltdcpp

It has a few build failures reported.  Overall, it is at the latest
upstream release but it's from 2021, and there seems to be some actibity
in the upstream repository since.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] AI policy approved

2024-04-15 Thread Michał Górny
Hello,

On 2024-04-14, the Gentoo Council has unanimously approved the new AI
policy.  The original wording from the mailing list thread was approved:

"""
It is expressly forbidden to contribute to Gentoo any content that has
been created with the assistance of Natural Language Processing
artificial intelligence tools.  This motion can be revisited, should
a case been made over such a tool that does not pose copyright, ethical
and quality concerns.
"""

I have started drafting a Wiki page detailing this at [1].  We will also
look into how best provide this new information to our contributors.

[1] https://wiki.gentoo.org/wiki/Project:Council/AI_policy

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Package up for grabs: dev-vcs/git-filter-repo

2024-04-14 Thread Michał Górny
Hi,

The following package needs a new maintainer:

  dev-vcs/git-filter-repo

The test suite fails with modern git versions, it's entirely possible
that the whole package is broken.  The upstream repository has barely
seen any activity since 2022, and the bug reports remain unanswered. 
Also, the package needs py3.12 and PEP517 ports.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-04-07 Thread Michał Górny
On Mon, 2024-04-08 at 01:22 +0100, Alex Boag-Munroe wrote:
> On Sun, 7 Apr 2024 at 22:09, Michael Orlitzky  wrote:
> 
> > What I am saying is that I want the freedom to not have things
> > pointlessly enabled on my systems, because similar problems (and worse)
> > happen all day every day. The less exposure I have, the better. The
> > liblzma backdoor was timely because it will prevent most people from
> > telling me I'm being paranoid, but it could have been USE=anything on
> > any other day. Moving the defaults out of the high-level profiles will
> > give control back to the user, hence my complaint about it.
> > 
> 
> I agree, to be honest. The spirit of profiles has always felt like it
> switches on safe/sane defaults that you'd expect for the name (a
> desktop plasma profile switches on all the useful desktop USE flags, a
> basic profile enables the bare minimum for a bootable system, etc),
> giving an expected functionality in the resulting outcome of a
> re-merge of world.

Precisely.

> Outside of this, preferred compression tools, preferred editors
> etc...should be up to the user, or implied in the profile name if it's
> going to be switched on in the profile defaults. I don't use zstd
> myself, I prefer xz or lz4 depending on my purpose. It's on my system
> because some things I chose to have required it. It feels un-Gentoo
> for me to have zstd around _just because_, which the profile default
> would bring into play.
> 

It's not a "preferred compression tool".  "Preferred compression tool"
is selected via adding the package to your @world set.  The flag is used
for enable specific functionality on packages.  This function may be
limited to being able to optionally compress something.  But it could
e.g. also be responsible for being able to, say, open a specific file
format (and I'm not talking of explicitly .xz compressed files)
or a database, or receive proper interoperability elsewhere.

The cost of enabling support for a compression library that's already
installed by default (because you need it to unpack distfiles) is very
little compared to the cost of suddenly discovering that things don't
work.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-04-07 Thread Michał Górny
On Sun, 2024-04-07 at 08:51 -0400, Michael Orlitzky wrote:
> On Sun, 2024-04-07 at 14:35 +0200, Andreas K. Huettel wrote:
> > 
> > Uhh, I dont really remember, I think some Chinese-sounding guy asked
> > me for it... (j/k) 
> 
> It is remarkably bad timing. How it looks: Gentoo's response to the xz
> incident is to have me rebuild my entire system with everything that
> could possibly be linked to liblzma, linked to liblzma. Even on the
> hardened profiles, and with no easy way to prevent it.

So, what you're basically saying, is that the best Gentoo response right
now would be to frantically remove LZMA support everywhere?  I'm sure
that would be so much better than our response of masking vulnerable
versions and issuing a statement.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Packages up for grabs

2024-04-03 Thread Michał Górny
The following packages are looking for a new home:

net-irc/limnoria
net-irc/limnoria-plugins-chantracker
net-irc/limnoria-plugins-jlu5
net-irc/limnoria-plugins-progval
sys-apps/kcheck
sys-apps/the_silver_searcher
x11-wm/jwm

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Packages up for grabs

2024-04-03 Thread Michał Górny
The following packages are up for grabs due to the inactivity of their
maintainers:

acct-group/oprofile
acct-group/privoxy
acct-group/sobexsrv
acct-user/oprofile
acct-user/privoxy
acct-user/sobexsrv
app-admin/apg
app-admin/clsync
app-admin/cpulimit
app-arch/unrpa
app-doc/e16-docs
app-misc/brewtarget
app-mobilephone/sobexsrv
app-text/sdcv
app-text/xpdf
dev-debug/ald
dev-debug/duma
dev-libs/openobex
dev-python/pygame_sdl2
dev-util/dissembler
dev-util/dropwatch
dev-util/lsuio
dev-util/oprofile
dev-util/pretrace
dev-util/tinlink
dev-util/usb-robot
media-libs/imlib2
media-libs/svgalib
media-plugins/imlib2_loaders
media-sound/apulse
net-dialup/openl2tp
net-fs/openafs
net-misc/l7-filter-userspace
net-misc/l7-protocols
net-proxy/pingtunnel
net-proxy/privoxy
net-proxy/tsocks
sec-keys/openpgp-keys-xpdf
sys-block/flashbench
sys-power/nvclock
sys-power/suspend
x11-misc/e16-keyedit
x11-misc/e16menuedit2
x11-plugins/e16-epplets
x11-themes/e16-themes
x11-wm/e16


-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Packages up for grabs

2024-04-03 Thread Michał Górny
The following packages are now looking for a new maintainer due to
the previous maintainer being inactive:

acct-group/zeppelin
acct-user/zeppelin
app-admin/pydf
app-doc/diveintopython
app-misc/cpipe
app-misc/i2bits
app-misc/pfm
app-misc/screenfetch
app-misc/sl
app-misc/ttyrec
app-misc/vifm
app-text/html-xml-utils
app-vim/scala-syntax
dev-lang/micropython
dev-libs/http-fetcher
dev-python/brython
dev-python/nodeenv
dev-util/dwdiff
dev-util/kup
dev-util/xmlindent
dev-util/yacc
games-action/supermariowar
media-gfx/ttygif
net-irc/irssistats
net-misc/redir
net-misc/spiped
sys-apps/crazydiskinfo
sys-process/ftop
sys-process/memwatch
www-apps/zeppelin-bin
www-client/fetch
x11-libs/xforms
x11-misc/sct


-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-04-01 Thread Michał Górny
On Mon, 2024-04-01 at 08:57 +0100, Eddie Chapman wrote:
> 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 would like to point out that the xz/sshd issue was primarily a social
one, not a technical one.

The primary problem in open source today isn't bad code.  It's projects
relying on overburdened, burned out maintainers.  And on top of that,
users who are complaining, demanding, outright hostile or primarily
contributing by walls of text on a mailing lists, that bring nothing to
discussion except for furthering the burnout of open source developers
who are actually trying to do something.

Think about that.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/nspektr

2024-03-30 Thread Michał Górny
# Michał Górny  (2024-03-30)
# NIH package that was added for dev-python/setuptools but is no longer
# used there.
# Removal on 2024-04-29.  Bug #928270.
dev-python/nspektr

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-03-30 Thread Michał Górny
On Sat, 2024-03-30 at 15:17 +, Eddie Chapman wrote:
> Michał Górny wrote:
> > On Sat, 2024-03-30 at 14:57 +, Eddie Chapman wrote:
> > 
> > > Note, I'm not advocating ripping xz-utils out of tree, all I'm saying
> > > is wouldn't it be nice if there were at least 2 alternatives to choose
> > > from? That doesn't have to be disruptive in any way, people who wish to
> > > continue using and trusting xz-utils should be able to continue to do so
> > > without any friction whatsoever.
> > 
> > So, you're basically saying we should go out of our way, recompress all
> > distfiles using two alternative compression formats, increase mirror load
> > four times and add a lot of complexity to ebuilds, right?
> > 
> > --
> > Best regards,
> > Michał Górny
> > 
> 
> 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.
> 

Should we convert git repositories to Mercurial and Bazaar too, to avoid
relying too much on a single tool?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-03-30 Thread Michał Górny
On Sat, 2024-03-30 at 14:57 +, Eddie Chapman wrote:
> Note, I'm not advocating ripping xz-utils out of tree, all I'm saying is
> wouldn't it be nice if there were at least 2 alternatives to choose from?
> That doesn't have to be disruptive in any way, people who wish to continue
> using and trusting xz-utils should be able to continue to do so without
> any friction whatsoever.

So, you're basically saying we should go out of our way, recompress all
distfiles using two alternative compression formats, increase mirror
load four times and add a lot of complexity to ebuilds, right?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, error out on missing async plugin

2024-03-29 Thread Michał Górny
Explicitly error out if epytest is run without an appropriate async
plugin, and the test suite contains async tests.  Currently, these tests
are skipped with a warning but that is usually a mistake, and one can
easily miss it when pytest-asyncio or a similar plugin is installed
on the test system.  However, a missing dependency can result
in the tests being skipped afterwards on the tinderbox.

Signed-off-by: Michał Górny 
---
 eclass/python-utils-r1.eclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index caa39813feec..bbf751399476 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1349,6 +1349,9 @@ epytest() {
# override filterwarnings=error, we do not really want -Werror
# for end users, as it tends to fail on new warnings from deps
-Wdefault
+   # however, do error out if the package failed to load
+   # an appropriate async plugin
+   -Werror::pytest.PytestUnhandledCoroutineWarning
# override color output
"--color=${color}"
# count is more precise when we're dealing with a large number
-- 
2.44.0




Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: make the FHS paths warning easier to read

2024-03-29 Thread Michał Górny
On Thu, 2024-03-28 at 23:54 -0400, Eli Schwartz wrote:
>  * 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

LGTM.  Thanks!

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH 7/7] distutils-r1.eclass: Remove more junk from .dist-info

2024-03-26 Thread Michał Górny
Closes: https://bugs.gentoo.org/927818
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 22b28e915859..7a314673a90b 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1314,14 +1314,23 @@ distutils_wheel_install() {
printf '%s\n' "${cmd[*]}"
"${cmd[@]}" || die "Wheel install failed"
 
-   # remove installed licenses
+   # remove installed licenses and other junk
find "${root}$(python_get_sitedir)" -depth \
-   \( -path '*.dist-info/COPYING*' \
-   -o -path '*.dist-info/LICENSE*' \
+   \( -ipath '*.dist-info/AUTHORS*' \
+   -o -ipath '*.dist-info/CHANGELOG*' \
+   -o -ipath '*.dist-info/CODE_OF_CONDUCT*' \
+   -o -ipath '*.dist-info/COPYING*' \
+   -o -ipath '*.dist-info/*LICEN[CS]E*' \
+   -o -ipath '*.dist-info/NOTICE*' \
+   -o -ipath '*.dist-info/*Apache*' \
+   -o -ipath '*.dist-info/*GPL*' \
+   -o -ipath '*.dist-info/*MIT*' \
+   -o -path '*.dist-info/RECORD' \
-o -path '*.dist-info/license_files/*' \
-o -path '*.dist-info/license_files' \
-o -path '*.dist-info/licenses/*' \
-o -path '*.dist-info/licenses' \
+   -o -path '*.dist-info/zip-safe' \
\) -delete || die
 }
 
-- 
2.44.0




[gentoo-dev] [PATCH 6/7] distutils-r1.eclass: Fix `det unittest` with 3.12 only

2024-03-26 Thread Michał Górny
Closes: https://bugs.gentoo.org/926964
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index a1617999a037..22b28e915859 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -628,11 +628,11 @@ distutils_enable_tests() {
;;
unittest)
# unittest-or-fail is needed in py<3.12
-   test_deps+="
-   $(python_gen_cond_dep '
+   local test_pkgs="$(python_gen_cond_dep '

dev-python/unittest-or-fail[${PYTHON_USEDEP}]
-   ' 3.10 3.11)
-   "
+   ' 3.10 3.11
+   )"
+   [[ -n ${test_pkgs} ]] && test_deps+=" ${test_pkgs}"
;;
*)
die "${FUNCNAME}: unsupported argument: ${1}"
-- 
2.44.0




[gentoo-dev] [PATCH 5/7] distutils-r1.eclass: Refactor `distutils_enable_tests pytest`

2024-03-26 Thread Michał Górny
Refactor `distutils_enable_tests pytest` to move `test_pkgs` logic
straight into pytest block, as it is not used by any other variant
anymore.

Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 44553f8da6f3..a1617999a037 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -606,16 +606,23 @@ distutils_enable_tests() {
[[ ${#} -eq 1 ]] || die "${FUNCNAME} takes exactly one argument: 
test-runner"
 
local test_deps=${RDEPEND}
-   local test_pkgs
case ${1} in
pytest)
-   test_pkgs='>=dev-python/pytest-7.4.4[${PYTHON_USEDEP}]'
+   local 
test_pkgs='>=dev-python/pytest-7.4.4[${PYTHON_USEDEP}]'
if [[ -n ${EPYTEST_TIMEOUT} ]]; then
test_pkgs+=' 
dev-python/pytest-timeout[${PYTHON_USEDEP}]'
fi
if [[ ${EPYTEST_XDIST} ]]; then
test_pkgs+=' 
dev-python/pytest-xdist[${PYTHON_USEDEP}]'
fi
+
+   if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
+   test_deps+=" 
${test_pkgs//'${PYTHON_USEDEP}'/${PYTHON_USEDEP}}"
+   else
+   test_deps+=" $(python_gen_cond_dep "
+   ${test_pkgs}
+   ")"
+   fi
;;
setup.py)
;;
@@ -634,15 +641,6 @@ distutils_enable_tests() {
_DISTUTILS_TEST_RUNNER=${1}
python_test() { distutils-r1_python_test; }
 
-   if [[ -n ${test_pkgs} ]]; then
-   if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
-   test_deps+=" 
${test_pkgs//'${PYTHON_USEDEP}'/${PYTHON_USEDEP}}"
-   else
-   test_deps+=" $(python_gen_cond_dep "
-   ${test_pkgs}
-   ")"
-   fi
-   fi
if [[ -n ${test_deps} ]]; then
IUSE+=" test"
RESTRICT+=" !test? ( test )"
-- 
2.44.0




[gentoo-dev] [PATCH 4/7] distutils-r1.eclass: Remove nosetests support

2024-03-26 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 8 
 1 file changed, 8 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 16d97501012b..44553f8da6f3 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -572,8 +572,6 @@ distutils_enable_sphinx() {
 # with the specified test runner.  Also copies the current value
 # of RDEPEND to test?-BDEPEND.  The test-runner argument must be one of:
 #
-# - nose: nosetests (dev-python/nose)
-#
 # - pytest: dev-python/pytest
 #
 # - setup.py: setup.py test (no deps included)
@@ -610,9 +608,6 @@ distutils_enable_tests() {
local test_deps=${RDEPEND}
local test_pkgs
case ${1} in
-   nose)
-   
test_pkgs='>=dev-python/nose-1.3.7_p20221026[${PYTHON_USEDEP}]'
-   ;;
pytest)
test_pkgs='>=dev-python/pytest-7.4.4[${PYTHON_USEDEP}]'
if [[ -n ${EPYTEST_TIMEOUT} ]]; then
@@ -1594,9 +1589,6 @@ distutils-r1_python_test() {
fi
 
case ${_DISTUTILS_TEST_RUNNER} in
-   nose)
-   "${EPYTHON}" -m nose -v "${@}"
-   ;;
pytest)
epytest
;;
-- 
2.44.0




[gentoo-dev] [PATCH 3/7] dev-python/jsonref: Use pdm-backend

2024-03-26 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 dev-python/jsonref/jsonref-1.1.0.ebuild | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/dev-python/jsonref/jsonref-1.1.0.ebuild 
b/dev-python/jsonref/jsonref-1.1.0.ebuild
index 59041a7158cf..6233424f0523 100644
--- a/dev-python/jsonref/jsonref-1.1.0.ebuild
+++ b/dev-python/jsonref/jsonref-1.1.0.ebuild
@@ -1,9 +1,9 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
 
-DISTUTILS_USE_PEP517=pdm
+DISTUTILS_USE_PEP517=pdm-backend
 PYTHON_COMPAT=( python3_{10..12} )
 
 inherit distutils-r1
-- 
2.44.0




[gentoo-dev] [PATCH 2/7] distutils-r1.eclass: Run pdm.pep517.api via pdm-backend

2024-03-26 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index e4b17c433e5d..16d97501012b 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -124,8 +124,6 @@ esac
 #
 # - pbr - pbr backend
 #
-# - pdm - pdm.pep517 backend
-#
 # - pdm-backend - pdm.backend backend
 #
 # - poetry - poetry-core backend
@@ -257,11 +255,6 @@ _distutils_set_globals() {
>=dev-python/pbr-6.0.0[${PYTHON_USEDEP}]
'
;;
-   pdm)
-   bdep+='
-   
>=dev-python/pdm-pep517-1.1.4[${PYTHON_USEDEP}]
-   '
-   ;;
pdm-backend)
bdep+='

>=dev-python/pdm-backend-2.1.8[${PYTHON_USEDEP}]
@@ -1002,12 +995,6 @@ _distutils-r1_print_package_versions() {
dev-python/wheel
)
;;
-   pdm)
-   packages+=(
-   dev-python/pdm-pep517
-   dev-python/setuptools
-   )
-   ;;
pdm-backend)
packages+=(
dev-python/pdm-backend
@@ -1214,12 +1201,9 @@ _distutils-r1_backend_to_key() {
pbr.build)
echo pbr
;;
-   pdm.backend)
+   pdm.backend|pdm.pep517.api)
echo pdm-backend
;;
-   pdm.pep517.api)
-   echo pdm
-   ;;
poetry.core.masonry.api|poetry.masonry.api)
echo poetry
;;
@@ -1280,6 +1264,9 @@ _distutils-r1_get_backend() {
flit.buildapi)
new_backend=flit_core.buildapi
;;
+   pdm.pep517.api)
+   new_backend=pdm.backend
+   ;;
poetry.masonry.api)
new_backend=poetry.core.masonry.api
;;
-- 
2.44.0




[gentoo-dev] [PATCH 1/7] distutils-r1.eclass: Bump minimal dep versions

2024-03-26 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 9be994595529..e4b17c433e5d 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -230,7 +230,7 @@ _distutils_set_globals() {
;;
hatchling)
bdep+='
-   
>=dev-python/hatchling-1.17.0[${PYTHON_USEDEP}]
+   
>=dev-python/hatchling-1.21.1[${PYTHON_USEDEP}]
'
;;
jupyter)
@@ -240,7 +240,7 @@ _distutils_set_globals() {
;;
maturin)
bdep+='
-   
>=dev-util/maturin-1.0.1[${PYTHON_USEDEP}]
+   
>=dev-util/maturin-1.4.0[${PYTHON_USEDEP}]
'
;;
no)
@@ -249,12 +249,12 @@ _distutils_set_globals() {
;;
meson-python)
bdep+='
-   
>=dev-python/meson-python-0.13.1[${PYTHON_USEDEP}]
+   
>=dev-python/meson-python-0.15.0[${PYTHON_USEDEP}]
'
;;
pbr)
bdep+='
-   
>=dev-python/pbr-5.11.1[${PYTHON_USEDEP}]
+   >=dev-python/pbr-6.0.0[${PYTHON_USEDEP}]
'
;;
pdm)
@@ -264,27 +264,27 @@ _distutils_set_globals() {
;;
pdm-backend)
bdep+='
-   
>=dev-python/pdm-backend-2.1.0[${PYTHON_USEDEP}]
+   
>=dev-python/pdm-backend-2.1.8[${PYTHON_USEDEP}]
'
;;
poetry)
bdep+='
-   
>=dev-python/poetry-core-1.6.1[${PYTHON_USEDEP}]
+   
>=dev-python/poetry-core-1.9.0[${PYTHON_USEDEP}]
'
;;
scikit-build-core)
bdep+='
-   
>=dev-python/scikit-build-core-0.4.6[${PYTHON_USEDEP}]
+   
>=dev-python/scikit-build-core-0.8.2[${PYTHON_USEDEP}]
'
;;
setuptools)
bdep+='
-   
>=dev-python/setuptools-67.8.0-r1[${PYTHON_USEDEP}]
+   
>=dev-python/setuptools-69.0.3[${PYTHON_USEDEP}]
'
;;
sip)
bdep+='
-   >=dev-python/sip-6.7.9[${PYTHON_USEDEP}]
+   >=dev-python/sip-6.8.3[${PYTHON_USEDEP}]
'
;;
standalone)
@@ -299,7 +299,7 @@ _distutils_set_globals() {
eqawarn "is enabled."
fi
else
-   local 
setuptools_dep='>=dev-python/setuptools-67.8.0-r1[${PYTHON_USEDEP}]'
+   local 
setuptools_dep='>=dev-python/setuptools-69.0.3[${PYTHON_USEDEP}]'
 
case ${DISTUTILS_USE_SETUPTOOLS:-bdepend} in
no|manual)
@@ -508,7 +508,7 @@ distutils_enable_sphinx() {
_DISTUTILS_SPHINX_PLUGINS=( "${@}" )
 
local deps autodoc=1 d
-   deps=">=dev-python/sphinx-5.3.0[\${PYTHON_USEDEP}]"
+   deps=">=dev-python/sphinx-7.2.6[\${PYTHON_USEDEP}]"
for d; do
if [[ ${d} == --no-autodoc ]]; then
autodoc=
@@ -532,7 +532,7 @@ distutils_enable_sphinx() {
use doc || return 0
 
local p
-   for p in ">=dev-python/sphinx-5.3.0" \
+   for p in ">=dev-python/sphinx-7.2.6" \
"${_DISTUTILS_SPHINX_PLUGINS[@]}"
do
python_has_version "${p}[${PYTHON_USEDEP}]" ||
@@ 

Re: [gentoo-dev] [PATCH 2/2] sys-apps/systemd-utils: add workaround for no-multilib

2024-03-26 Thread Michał Górny
On Tue, 2024-03-26 at 11:01 -0400, Mike Gilbert wrote:
> meson.build has some logic to build ia32 EFI binaries on x86_64 if the
> toolchain is compatible. Rather than trying to reproduce this logic in
> the ebuild, just try to build it and ignore any failures.
> 
> If meson.build actually defines the targets but we have some other
> compile error, this will move the failure to the install phase instead.
> 

That's not a correct use of nonfatal.  It is supposed to be used to
provide customized error handling (e.g. cleanup step before dying), not
a cheap way to ignore errors.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/simplegeneric

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Last release in 2012.  No reverse dependencies.
# Removal on 2024-04-25.  Bug #927524.
dev-python/simplegeneric

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: net-misc/blinkperl

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Unmaintained.  EAPI 6.  Homepage gone.  No keywords for modern
# architectures.
# Removal on 2024-04-25.  Bug #927208.
net-misc/blinkperl

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: net-misc/felix

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Unmaintained.  Multiple bugs open.  The current version is from 2018,
# and it has been discontinued as a separate package since.
# Removal on 2024-04-25.  Bug #926861.
net-misc/felix

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: app-pda/iripdb

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Unmaintained.  EAPI 6.  Homepage gone.
# Removal on 2024-04-25.  Bug #926860.
app-pda/iripdb

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: media-fonts/dzongkha-fonts

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Unfetchable proprietary fonts.  The alternatives include
# media-fonts/jomolhari and "Noto Serif Tibetan" from media-fonts/noto.
# Removal on 2024-04-25.  Bug #926836.
media-fonts/dzongkha-fonts

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: x11-libs/scw

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# A dead wiget library with no reverse dependencies.  Homepage gone.
# Removal on 2024-04-25.  Bug #926604.
x11-libs/scw

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: sys-firmware/bluez-firmware

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Deprecated upstream and the URL no longer works.
# Removal on 2024-04-25.  Bug #926550.
sys-firmware/bluez-firmware

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/anyqt

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Wrapper library that's stuck on Qt5.  No reverse dependencies left.
# Removal on 2024-04-25.  Bug #926548.
dev-python/anyqt

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/sumtypes

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Unfinished package from 2021 that was added as a short-lived
# dependency of dev-python/GitPython.  No reverse dependencies remain.
# Removal on 2024-04-25.  Bug #924683.
dev-python/sumtypes

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: sci-biology/HTSeq

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Uses deprecated distutils-r1 API.  The current version is outdated,
# from mid-2022.  No reverse dependencies.
# Removal on 2024-04-25.  Bug #910015.
sci-biology/HTSeq

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: media-libs/libopenshot, media-libs/libopenshot-audio, media-video/openshot

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Uses deprecated distutils-r1 API.  Depends on dev-qt/qtwebengine:5.
# Includes the libraries with no other reverse dependencies.
# Removal on 2024-04-25.  Bug #909996.
media-libs/libopenshot
media-libs/libopenshot-audio
media-video/openshot

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: sys-auth/pam_ssh

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Issues with OpenSSL 3.  Unmaintained.  Last activity in 2019.
# Removal on 2024-04-25.  Bug #892031.
sys-auth/pam_ssh

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: app-misc/tek

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Fails to compile.  Unmaintained.  Last activity in 2016.
# Depends on an old wxGTK slot.
# Removal on 2024-04-25.  Bug #895222.
app-misc/tek

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-libs/zthread

2024-03-26 Thread Michał Górny
# Michał Górny  (2024-03-26)
# Bad C++ code.  Unmaintained.  Carries a number of patches already.
# No reverse dependencies.
# Removal on 2024-04-25.  Bug #924925.
dev-libs/zthread

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/prov

2024-03-23 Thread Michał Górny
# Michał Górny  (2024-03-23)
# No maintainer.  Broken tests.  Not ported to PEP517 build.
# No release since 2020, little activity since.  No revdeps.
# Removal on 2024-04-22.  Bug #911780.
dev-python/prov

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/sphinxcontrib-asyncio

2024-03-23 Thread Michał Górny
# Michał Górny  (2024-03-23)
# Apparently broken.  No tests.  Last code change in 2016.  No revdeps.
# Removal on 2024-04-22.  Bug #892613.
dev-python/sphinxcontrib-asyncio

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-03-21 Thread Michał Górny
On Tue, 2024-02-27 at 15:45 +0100, Michał Górny wrote:
> Given the recent spread of the "AI" bubble, I think we really need to
> look into formally addressing the related concerns.  In my opinion,
> at this point the only reasonable course of action would be to safely
> ban "AI"-backed contribution entirely.  In other words, explicitly
> forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to
> create ebuilds, code, documentation, messages, bug reports and so on for
> use in Gentoo.
> 
> Just to be clear, I'm talking about our "original" content.  We can't do
> much about upstream projects using it.

Since I've been asked to flesh out a specific motion, here's what I
propose specifically:

"""
It is expressly forbidden to contribute to Gentoo any content that has
been created with the assistance of Natural Language Processing
artificial intelligence tools.  This motion can be revisited, should
a case been made over such a tool that does not pose copyright, ethical
and quality concerns.
"""

This explicitly covers all GPTs, including ChatGPT and Copilot, which is
the category causing the most concern at the moment.  At the same time,
it doesn't block more specific uses of machine learning to problem
solving.

Special thanks to Arthur Zamarin for consulting me on this.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] mirror storage growth rate

2024-03-15 Thread Michał Górny
On Fri, 2024-03-15 at 10:06 +0200, Jaco Kroon wrote:
> Hi All,
> 
> I was messing with some storage related caching on some of our hosts 
> this morning when I wondered about how much storage the gentoo mirrors 
> were consuming.  I'm not too worried about the current storage, but I am 
> noticing that the storage requirements are creeping quite a bit (as per 
> attached), and if that growth rate continues it may become a problem 
> *eventually*.
> 
> Can this growth be explained?
> 

I guess the simplest explanation is that software is growing larger,
and in the end we should be expecting to adding new packages faster than
removing dead ones.  Add to that the grotesque inefficiency of modern
programming languages such as Go and Rust.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/pygame_sdl2

2024-03-10 Thread Michał Górny
# Michał Górny  (2024-03-10)
# Packages that still require 

signature.asc
Description: This is a digitally signed message part


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

2024-03-09 Thread Michał Górny
On Fri, 2024-03-08 at 03:59 +, Duncan wrote:
> Robin H. Johnson posted on Tue, 5 Mar 2024 06:12:06 + as excerpted:
> 
> > The energy waste argument is also one that needs to be made carefully:
> 
> Indeed.  In a Gentoo context, condemning AI for the computative energy 
> waste?  Maybe someone could argue that effectively.  That someone isn't 
> Gentoo.  Something about people living in glass houses throwing stones...

Could you support that claim with actual numbers?  Particularly,
on average energy use specifically due to use of Gentoo on machines vs.
energy use of dedicated data centers purely for training LLMs?  I'm not
even talking of all the energy wasted as a result of these LLMs at work.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-03-09 Thread Michał Górny
On Fri, 2024-03-01 at 07:06 +, Sam James wrote:
> Another person approached me after this RFC and asked whether tooling
> restricted to the current repo would be okay. For me, that'd be mostly
> acceptable, given it won't make suggestions based on copyrighted code.

I think an important question is: how is it restricted?  Are we talking
about a tool that was clearly trained on specific code, or about a tool
that was trained on potentially copyright material, then artificially
restricted to the repository (to paper over the concerns)?  Can we trust
the latter?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-03-09 Thread Michał Górny
On Tue, 2024-02-27 at 18:04 +, Sam James wrote:
> I'm a bit worried this is slightly performative - which is not a dig at
> you at all - given we can't really enforce it, and it requires honesty,
> but that's also not a reason to not try ;)

I don't think it's really possible or feasible to reliably detect such
contributions, and even if it were, I don't think we want to go as far
as to actively pursue anything that looks like one.  The point
of the policy is rather to make a statement that we don't want these,
and to kindly ask users not to do that.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Please migrate your distutils-r1 ebuilds to use PEP517 builds

2024-03-09 Thread Michał Górny
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.

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.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH v2 7/7] distutils-r1.eclass: wire up meson-python to meson.eclass

2024-03-05 Thread Michał Górny
From: Eli Schwartz 

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.

[sam: Tweak '=' style.]
[sam: Tweak mesonargs->MESONARGS for final version of 
e9189344b971f7ee0e2bec36650c57dbade4f122.]
[sam: Update local variable list.]
[mgorny: Add local variables for LTO filtering.]

Signed-off-by: Eli Schwartz 
Signed-off-by: Sam James 
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 134cb39f276a..e0c54d81a846 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,19 @@ distutils_pep517_install() {
)
;;
meson-python)
+   # variables defined by setup_meson_src_configure
+   local MESONARGS=() BOOST_INCLUDEDIR BOOST_LIBRARYDIR NM 
READELF
+   # it also calls filter-lto
+   local x
+   for x in $(all-flag-vars); do
+   local -x "${x}=${!x}"
+   done
+
+   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.44.0




[gentoo-dev] [PATCH v2 6/7] meson.eclass: move python_export_utf8_locale to meson_src_configure

2024-03-05 Thread Michał Górny
From: Sam James 

We don't need it in setup_meson_src_configure as distutils-r1 uses it and
it'll get called twice then.

Signed-off-by: Sam James 
---
 eclass/meson.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 3bf0ba9ebe97..85f024de1b0c 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -393,9 +393,6 @@ setup_meson_src_configure() {
tc-export NM
tc-getPROG READELF readelf >/dev/null
 
-   # https://bugs.gentoo.org/625396
-   python_export_utf8_locale
-
# https://bugs.gentoo.org/721786
export BOOST_INCLUDEDIR="${BOOST_INCLUDEDIR-${EPREFIX}/usr/include}"
export 
BOOST_LIBRARYDIR="${BOOST_LIBRARYDIR-${EPREFIX}/usr/$(get_libdir)}"
@@ -412,6 +409,9 @@ meson_src_configure() {
 
BUILD_DIR="${BUILD_DIR:-${WORKDIR}/${P}-build}"
 
+   # https://bugs.gentoo.org/625396
+   python_export_utf8_locale
+
(
setup_meson_src_configure "$@"
MESONARGS+=(
-- 
2.44.0




[gentoo-dev] [PATCH v2 5/7] python-utils-r1.eclass: Fix python_doheader install location with ROOT

2024-03-05 Thread Michał Górny
From: James Le Cuirot 

python_get_includedir is prefixed with ESYSROOT, not EPREFIX, so we need
to strip off the former, not the latter.

This is currently only used for dev-python/pillow, which I have tested.

Signed-off-by: James Le Cuirot 
---
 eclass/python-utils-r1.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 3af3cbdb075e..caa39813feec 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -884,7 +884,7 @@ python_doheader() {
[[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is 
null).'
 
local includedir=$(python_get_includedir)
-   local d=${includedir#${EPREFIX}}
+   local d=${includedir#${ESYSROOT}}
 
(
insopts -m 0644
-- 
2.44.0




[gentoo-dev] [PATCH v2 4/7] distutils-r1.eclass: Make vars local before calling filter-lto

2024-03-05 Thread Michał Górny
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
-- 
2.44.0




[gentoo-dev] [PATCH v2 3/7] distutils-r1.eclass: Move filter-lto into DISTUTILS_EXT block

2024-03-05 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 60554944a5a0..ee1dcef24ff6 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1824,17 +1824,17 @@ distutils-r1_run_phase() {
# bug fixes from Cython (this works only when setup.py is using
# cythonize() but it's better than nothing)
local -x CYTHON_FORCE_REGEN=1
+
+   # Rust extensions are incompatible with C/C++ LTO compiler
+   # see e.g. https://bugs.gentoo.org/910220
+   if has cargo ${INHERITED}; then
+   filter-lto
+   fi
fi
 
# silence warnings when pydevd is loaded on Python 3.11+
local -x PYDEVD_DISABLE_FILE_VALIDATION=1
 
-   # Rust extensions are incompatible with C/C++ LTO compiler
-   # see e.g. https://bugs.gentoo.org/910220
-   if has cargo ${INHERITED}; then
-   filter-lto
-   fi
-
# How to build Python modules in different worlds...
local ldopts
case "${CHOST}" in
-- 
2.44.0




[gentoo-dev] [PATCH v2 2/7] distutils-r1.eclass: Limit DISTUTILS_EXT logic to compile & test

2024-03-05 Thread Michał Górny
Perform the environment modifications specific to DISTUTILS_EXT
to python_compile and python_test phases.  These are the only phases
where we expect extension builds to be called.  This allows us to
limit the scope of localized CPPFLAGS, as we both want to avoid leaking
changes to non-Python parts of the build and let ebuilds to manipulate
flags at their leisure, particularly prior to python_compile.

Signed-off-by: Michał Górny 
---
 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 fb0c2dfaa693..60554944a5a0 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1812,7 +1812,13 @@ distutils-r1_run_phase() {
local -x AR=${AR} CC=${CC} CPP=${CPP} CXX=${CXX}
tc-export AR CC CPP CXX
 
-   if [[ ${DISTUTILS_EXT} ]]; then
+   # Perform additional environment modifications only for python_compile
+   # phase.  This is the only phase where we expect to be calling the 
Python
+   # build system.  We want to localize the altered variables to avoid them
+   # leaking to other parts of multi-language ebuilds.  However, we want
+   # to avoid localizing them in other phases, particularly
+   # python_configure_all, where the ebuild may wish to alter them 
globally.
+   if [[ ${DISTUTILS_EXT} && ( ${1} == *compile* || ${1} == *test* ) ]]; 
then
local -x CPPFLAGS="${CPPFLAGS} $(usex debug '-UNDEBUG' 
'-DNDEBUG')"
# always generate .c files from .pyx files to ensure we get 
latest
# bug fixes from Cython (this works only when setup.py is using
-- 
2.44.0




[gentoo-dev] [PATCH v2 1/7] distutils-r1.eclass: Remove -Werror... hack (now in cython)

2024-03-05 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 5 -
 1 file changed, 5 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index c0d1992ccce0..fb0c2dfaa693 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1813,11 +1813,6 @@ distutils-r1_run_phase() {
tc-export AR CC CPP CXX
 
if [[ ${DISTUTILS_EXT} ]]; then
-   if [[ ${BDEPEND} == *dev-python/cython* ]] ; then
-   # Workaround for 
https://github.com/cython/cython/issues/2747 (bug #918983)
-   local -x CFLAGS="${CFLAGS} $(test-flags-CC 
-Wno-error=incompatible-pointer-types)"
-   fi
-
local -x CPPFLAGS="${CPPFLAGS} $(usex debug '-UNDEBUG' 
'-DNDEBUG')"
# always generate .c files from .pyx files to ensure we get 
latest
# bug fixes from Cython (this works only when setup.py is using
-- 
2.44.0




[gentoo-dev] [PATCH v2 0/7] distutils-r1.eclass + python-utils-r1.eclass + meson.eclass: combined patches

2024-03-05 Thread Michał Górny
Hi,

The same set as previously + extra patches from Eli, James and Sam.



Eli Schwartz (1):
  distutils-r1.eclass: wire up meson-python to meson.eclass

James Le Cuirot (1):
  python-utils-r1.eclass: Fix python_doheader install location with ROOT

Michał Górny (4):
  distutils-r1.eclass: Remove -Werror... hack (now in cython)
  distutils-r1.eclass: Limit DISTUTILS_EXT logic to compile & test
  distutils-r1.eclass: Move filter-lto into DISTUTILS_EXT block
  distutils-r1.eclass: Make vars local before calling filter-lto

Sam James (1):
  meson.eclass: move python_export_utf8_locale to meson_src_configure

 eclass/distutils-r1.eclass| 45 +--
 eclass/meson.eclass   |  6 ++---
 eclass/python-utils-r1.eclass |  2 +-
 3 files changed, 36 insertions(+), 17 deletions(-)

-- 
2.44.0




[gentoo-dev] Python 3.12 to become the default in May-June 2024

2024-03-03 Thread Michał Górny
Hello,

Following the tradition of previous years, I think we should switch
the Gentoo default to Python 3.12 around May-June this year.

Please do port your packages.

As usual, the remaining package list and graph are on qa-reports:

https://qa-reports.gentoo.org/output/gpyutils/311-to-312.txt
https://qa-reports.gentoo.org/output/gpyutils/311-to-312.svg

We have a few porting tips in the Guide:

https://projects.gentoo.org/python/guide/porting.html#python-3-12

If you think we should mention something else, please let me know.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH 4/4] distutils-r1.eclass: Make vars local before calling filter-lto

2024-03-02 Thread Michał Górny
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 | 8 
 1 file changed, 8 insertions(+)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index ee1dcef24ff6..8193d6d8ecd0 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1828,6 +1828,14 @@ 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
+   # see all-flag-vars in flag-o-matic.eclass
+   local -x ADAFLAGS="${ADAFLAGS}"
+   local -x CFLAGS="${CFLAGS}"
+   local -x CXXFLAGS="${CXXFLAGS}"
+   local -x CCASFLAGS="${CCASFLAGS}"
+   local -x FFLAGS="${FFLAGS}"
+   local -x FCFLAGS="${FCFLAGS}"
+   local -x LDFLAGS="${LDFLAGS}"
filter-lto
fi
fi
-- 
2.44.0




[gentoo-dev] [PATCH 3/4] distutils-r1.eclass: Move filter-lto into DISTUTILS_EXT block

2024-03-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 60554944a5a0..ee1dcef24ff6 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1824,17 +1824,17 @@ distutils-r1_run_phase() {
# bug fixes from Cython (this works only when setup.py is using
# cythonize() but it's better than nothing)
local -x CYTHON_FORCE_REGEN=1
+
+   # Rust extensions are incompatible with C/C++ LTO compiler
+   # see e.g. https://bugs.gentoo.org/910220
+   if has cargo ${INHERITED}; then
+   filter-lto
+   fi
fi
 
# silence warnings when pydevd is loaded on Python 3.11+
local -x PYDEVD_DISABLE_FILE_VALIDATION=1
 
-   # Rust extensions are incompatible with C/C++ LTO compiler
-   # see e.g. https://bugs.gentoo.org/910220
-   if has cargo ${INHERITED}; then
-   filter-lto
-   fi
-
# How to build Python modules in different worlds...
local ldopts
case "${CHOST}" in
-- 
2.44.0




[gentoo-dev] [PATCH 2/4] distutils-r1.eclass: Limit DISTUTILS_EXT logic to compile & test

2024-03-02 Thread Michał Górny
Perform the environment modifications specific to DISTUTILS_EXT
to python_compile and python_test phases.  These are the only phases
where we expect extension builds to be called.  This allows us to
limit the scope of localized CPPFLAGS, as we both want to avoid leaking
changes to non-Python parts of the build and let ebuilds to manipulate
flags at their leisure, particularly prior to python_compile.

Signed-off-by: Michał Górny 
---
 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 fb0c2dfaa693..60554944a5a0 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1812,7 +1812,13 @@ distutils-r1_run_phase() {
local -x AR=${AR} CC=${CC} CPP=${CPP} CXX=${CXX}
tc-export AR CC CPP CXX
 
-   if [[ ${DISTUTILS_EXT} ]]; then
+   # Perform additional environment modifications only for python_compile
+   # phase.  This is the only phase where we expect to be calling the 
Python
+   # build system.  We want to localize the altered variables to avoid them
+   # leaking to other parts of multi-language ebuilds.  However, we want
+   # to avoid localizing them in other phases, particularly
+   # python_configure_all, where the ebuild may wish to alter them 
globally.
+   if [[ ${DISTUTILS_EXT} && ( ${1} == *compile* || ${1} == *test* ) ]]; 
then
local -x CPPFLAGS="${CPPFLAGS} $(usex debug '-UNDEBUG' 
'-DNDEBUG')"
# always generate .c files from .pyx files to ensure we get 
latest
# bug fixes from Cython (this works only when setup.py is using
-- 
2.44.0




[gentoo-dev] [PATCH 1/4] distutils-r1.eclass: Remove -Werror... hack (now in cython)

2024-03-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 5 -
 1 file changed, 5 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index c0d1992ccce0..fb0c2dfaa693 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1813,11 +1813,6 @@ distutils-r1_run_phase() {
tc-export AR CC CPP CXX
 
if [[ ${DISTUTILS_EXT} ]]; then
-   if [[ ${BDEPEND} == *dev-python/cython* ]] ; then
-   # Workaround for 
https://github.com/cython/cython/issues/2747 (bug #918983)
-   local -x CFLAGS="${CFLAGS} $(test-flags-CC 
-Wno-error=incompatible-pointer-types)"
-   fi
-
local -x CPPFLAGS="${CPPFLAGS} $(usex debug '-UNDEBUG' 
'-DNDEBUG')"
# always generate .c files from .pyx files to ensure we get 
latest
# bug fixes from Cython (this works only when setup.py is using
-- 
2.44.0




Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: Fix python_doheader install location with ROOT

2024-03-02 Thread Michał Górny
On Sat, 2024-03-02 at 15:20 +, James Le Cuirot wrote:
> python_get_includedir is prefixed with ESYSROOT, not EPREFIX, so we need
> to strip off the former, not the latter.
> 
> This is currently only used for dev-python/pillow, which I have tested.
> 
> Signed-off-by: James Le Cuirot 
> ---
>  eclass/python-utils-r1.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index 3af3cbdb075e1..caa39813feec7 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -884,7 +884,7 @@ python_doheader() {
>   [[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is 
> null).'
>  
>   local includedir=$(python_get_includedir)
> - local d=${includedir#${EPREFIX}}
> + local d=${includedir#${ESYSROOT}}
>  
>   (
>   insopts -m 0644

Good catch, thanks!  I'll add it onto
https://github.com/gentoo/gentoo/pull/35554 to avoid double cache regen.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH 3/3] texlive-common.eclass: Use nonfatal-respecting die for fmtutil-sys

2024-02-29 Thread Michał Górny
On Thu, 2024-02-29 at 14:38 +0100, Florian Schmaus wrote:
> Signed-off-by: Florian Schmaus 
> ---
>  eclass/texlive-common.eclass | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
> index 96e962cb8027..85cdb8ff204e 100644
> --- a/eclass/texlive-common.eclass
> +++ b/eclass/texlive-common.eclass
> @@ -199,7 +199,8 @@ efmtutil-sys() {
>   if has_version 'app-text/texlive-core' ; then
>   if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/bin/fmtutil-sys ]] ; 
> then
>   einfo "Rebuilding formats"
> - "${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null || 
> die
> + "${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null \
> + || die -n "fmtutil-sys returned non-zero exit 
> status ${res}"

Put '||' at end of the line, then you won't need the redundant
backslash.

>   else
>   ewarn "Cannot run fmtutil-sys for some reason."
>   ewarn "Your formats might be inconsistent with your 
> installed ${PN} version"

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-02-29 Thread Michał Górny
On Thu, 2024-02-29 at 15:21 +0100, Florian Schmaus wrote:
> On 29/02/2024 15.08, Michael Orlitzky wrote:
> > On Thu, 2024-02-29 at 14:47 +0100, Florian Schmaus wrote:
> > > >
> > > > +if [[ -z ${TL_PV} ]] \
> > > > +  && [[ ${EAPI} -ge 8 ]] \
> > > 
> > > I am skeptical of this construct, as in the past we had non-numeric
> > > EAPIs. So I may have to go with EAPI == 8 for now. Input appreciated.
> > > 
> > 
> > 
> > The eclass only supports EAPIs {7,8,...} so it should suffice to
> > blacklist EAPI=7.
> 
> Fair point, but that would mean to remember to adjust this line once the 
> eclass gets support for EAPI 9.
> 
> It appears that bash does the right thing:
> 
> $ if [[ "eapi-future" -gt 8 ]]; then echo "is greater than 8"; else echo 
> "is NOT greater than 8"; fi
> is NOT greater than 8
> 
> even considering
> 
> $ if [[ "9-eapi-future" -gt 8 ]]; then echo "is greater than 8"; else 
> echo "is NOT greater than 8"; fi
> is greater than 8
> 
> which would be fine.
> 
> Although I prefer the current approach, it is not a hill to die on for me.
> 

It is invalid to treat EAPI as an integer.

The standard practice is to explicitly list old EAPIs, so that no
changes need to preserve the new behavior for new EAPIs.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-02-28 Thread Michał Górny
On Wed, 2024-02-28 at 11:08 +0100, Ulrich Mueller wrote:
> > > > > > On Wed, 28 Feb 2024, Michał Górny wrote:
> 
> > On Tue, 2024-02-27 at 21:05 -0600, Oskari Pirhonen wrote:
> > > What about cases where someone, say, doesn't have an excellent grasp of
> > > English and decides to use, for example, ChatGPT to aid in writing
> > > documentation/comments (not code) and puts a note somewhere explicitly
> > > mentioning what was AI-generated so that someone else can take a closer
> > > look?
> > > 
> > > I'd personally not be the biggest fan of this if it wasn't in something
> > > like a PR or ml post where it could be reviewed before being made final.
> > > But the most impportant part IMO would be being up-front about it.
> 
> > I'm afraid that wouldn't help much.  From my experiences, it would be
> > less effort for us to help writing it from scratch, than trying to
> > untangle whatever verbose shit ChatGPT generates.  Especially that
> > a person with poor grasp of the language could have trouble telling
> > whether the generated text is actually meaningful.
> 
> But where do we draw the line? Are translation tools like DeepL allowed?
> I don't see much of a copyright issue for these.

I have a strong suspicion that these translation tools are trained
on copyrighted translations of books and other copyrighted material.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/nose

2024-02-27 Thread Michał Górny
# Michał Górny  (2024-02-28)
# Nosetests have been abandoned in 2015.  Upstream (while technically
# still around) has refused to accept any patches since, and we have
# already had to fork it, to keep it somewhat working.  All
# the remaining reverse dependencies were finally ported or last rited.
# Removal on 2024-03-29.  Bug #822414.
dev-python/nose

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: app-misc/rmlint

2024-02-27 Thread Michał Górny
# Michał Górny  (2024-02-28)
# The project is not really actively maintained upstream, and it still
# depends on dev-python/nose.  There are other tools with similar
# functionality.
# Removal on 2024-03-29.  Bug #878695.
app-misc/rmlint

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-02-27 Thread Michał Górny
On Tue, 2024-02-27 at 21:05 -0600, Oskari Pirhonen wrote:
> What about cases where someone, say, doesn't have an excellent grasp of
> English and decides to use, for example, ChatGPT to aid in writing
> documentation/comments (not code) and puts a note somewhere explicitly
> mentioning what was AI-generated so that someone else can take a closer
> look?
> 
> I'd personally not be the biggest fan of this if it wasn't in something
> like a PR or ml post where it could be reviewed before being made final.
> But the most impportant part IMO would be being up-front about it.

I'm afraid that wouldn't help much.  From my experiences, it would be
less effort for us to help writing it from scratch, than trying to
untangle whatever verbose shit ChatGPT generates.  Especially that
a person with poor grasp of the language could have trouble telling
whether the generated text is actually meaningful.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: app-admin/salt, dev-python/pytest-salt-factories, dev-python/boto

2024-02-27 Thread Michał Górny
# Michał Górny  (2024-02-27)
# dev-python/boto is dead, with last release in 2018.  It has been
# replaced by dev-python/boto3.  It carries a ton of patches and still
# depends on dev-python/nose.
#
# app-admin/salt is its only remaining reverse dependency.  The ebuild
# is of very low quality.
#
# Removal on 2024-03-28.  Bug #888235.
app-admin/salt
dev-python/pytest-salt-factories
dev-python/boto

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: app-misc/binwalk

2024-02-27 Thread Michał Górny
# Michał Górny  (2024-02-27)
# Unmaintained upstream.  Already carries a few patches.
# Depends on dev-python/nose.
# Removal on 2024-03-28.  Bug #878693.
app-misc/binwalk

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: sci-biology/biopandas

2024-02-27 Thread Michał Górny
# Michał Górny  (2024-02-27)
# Still depends on dev-python/nose.  No reverse dependencies.
# Removal on 2024-03-28.  Bug #878721.
sci-biology/biopandas

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: sci-chemistry/nmrglue

2024-02-27 Thread Michał Górny
# Michał Górny  (2024-02-27)
# Effectively unmaintained in Gentoo.  Still depends on dev-python/nose,
# on top of that tests are restricted, so we don't even know if it
# works at all.  No reverse dependencies.
# Removal on 2024-03-28.  Bug #878725.
sci-chemistry/nmrglue

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-02-27 Thread Michał Górny
Hello,

Given the recent spread of the "AI" bubble, I think we really need to
look into formally addressing the related concerns.  In my opinion,
at this point the only reasonable course of action would be to safely
ban "AI"-backed contribution entirely.  In other words, explicitly
forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to
create ebuilds, code, documentation, messages, bug reports and so on for
use in Gentoo.

Just to be clear, I'm talking about our "original" content.  We can't do
much about upstream projects using it.


Rationale:

1. Copyright concerns.  At this point, the copyright situation around
generated content is still unclear.  What's pretty clear is that pretty
much all LLMs are trained on huge corpora of copyrighted material, and
all fancy "AI" companies don't give shit about copyright violations.
In particular, there's a good risk that these tools would yield stuff we
can't legally use.

2. Quality concerns.  LLMs are really great at generating plausibly
looking bullshit.  I suppose they can provide good assistance if you are
careful enough, but we can't really rely on all our contributors being
aware of the risks.

3. Ethical concerns.  As pointed out above, the "AI" corporations don't
give shit about copyright, and don't give shit about people.  The AI
bubble is causing huge energy waste.  It is giving a great excuse for
layoffs and increasing exploitation of IT workers.  It is driving
enshittification of the Internet, it is empowering all kinds of spam
and scam.


Gentoo has always stood out as something different, something that
worked for people for whom mainstream distros were lacking.  I think
adding "made by real people" to the list of our advantages would be
a good thing — but we need to have policies in place, to make sure shit
doesn't flow in.

Compare with the shitstorm at:
https://github.com/pkgxdev/pantry/issues/5358

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH v2 1/2] check-reqs.eclass: runtime disk checks for any path.

2024-02-26 Thread Michał Górny
On Sun, 2024-02-25 at 22:31 -0800, Robin H. Johnson wrote:
> Allow checking any runtime path for installing ever-larger packages.
> 
> CHECKREQS_DISK_RUNTIME=( /boot:40M /:350M /opt:500M )
> 
> Recent example of large packages:
> 
> gentoo-kernel-bin:
> / >=350MB/version (in /lib/modules)
> /boot >=40MB/version
> 
> rust-bin:
> /opt  >=450MB/version
> 
> Signed-off-by: Robin H. Johnson 
> ---
>  eclass/check-reqs.eclass | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
> index fac2f4553d74..1c59c69489a9 100644
> --- a/eclass/check-reqs.eclass
> +++ b/eclass/check-reqs.eclass
> @@ -30,6 +30,13 @@
>  # # install will need this much space in /var
>  # CHECKREQS_DISK_VAR="1024M"
>  #
> +# # install will need this much space in listed paths.
> +# CHECKREQS_DISK_RUNTIME=(
> +#   /var:1G
> +#   /boot/efi:32M

I'd avoid listing /boot/efi as an example, as /boot is a bit special
and might need special handling in the eclass.  In particular,
on the system here I have EFI mounted at /boot, so there
is no /boot/efi.

A possible generic solution would be to "fall back" from non-existing
locations to a "higher" directory, assuming they would normally be
created as subdirectories.

> +#   /opt/giant-package-with-dedicated-disk:100G
> +# )
> +#
>  # @CODE
>  #
>  # If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is 
> not
> @@ -66,6 +73,11 @@ _CHECK_REQS_ECLASS=1
>  # @DESCRIPTION:
>  # How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M
>  
> +# @ECLASS_VARIABLE: CHECKREQS_DISK_RUNTIME
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# How much space is needed in paths? Eg.: CHECKREQS_DISK_RUNTIME=( /:1G 
> /var:5G )
> +
>  # @ECLASS_VARIABLE: CHECKREQS_DONOTHING
>  # @USER_VARIABLE
>  # @DEFAULT_UNSET
> @@ -120,6 +132,7 @@ _check-reqs_prepare() {
>   debug-print-function ${FUNCNAME} "$@"
>  
>   if [[ -z ${CHECKREQS_MEMORY} &&
> + "${#CHECKREQS_DISK_RUNTIME[@]}" -eq 0 &&
>   -z ${CHECKREQS_DISK_BUILD} &&
>   -z ${CHECKREQS_DISK_USR} &&
>   -z ${CHECKREQS_DISK_VAR} ]]; then

Considering all the extra logic discussed in this thread, it might be
reasonable to implicitly convert CHECKREQS_DISK_* into
CHECKREQS_DISK_RUNTIME, so they'd share all the solutions discussed.

So ideally the logic would be something like:

1. Append CHECKREQS_DISK_* into CHECKREQS_DISK_RUNTIME.

2. Replace missing paths with the first parent directory that exists.

3. Replace paths with their respective mount points.

4. Sum the values corresponding to the same mount point.

> @@ -161,6 +174,16 @@ _check-reqs_run() {
>   fi
>  
>   if [[ ${MERGE_TYPE} != buildonly ]]; then
> + if [[ "${#CHECKREQS_DISK_RUNTIME[@]}" -gt 0 ]]; then
> + for _path_size in "${CHECKREQS_DISK_RUNTIME[@]}"; do
> + _path=${_path_size/:*}
> + _size=${_path_size/*:}
> + _check-reqs_disk \
> + "${EROOT%/}${_path}" "${_size}"
> +     done
> + unset _path_size _path _size

Instead of setting them globally, then unsetting, you should use local
variables.

> + fi
> +
>   [[ -n ${CHECKREQS_DISK_USR} ]] && \
>   _check-reqs_disk \
>   "${EROOT%/}/usr" \

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH 2/2] dev-python/reflink: Use PROPERTIES=test_privileged

2024-02-22 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 dev-python/reflink/reflink-0.2.2.ebuild | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/dev-python/reflink/reflink-0.2.2.ebuild 
b/dev-python/reflink/reflink-0.2.2.ebuild
index 83e0653fe4a1..7c9681db2505 100644
--- a/dev-python/reflink/reflink-0.2.2.ebuild
+++ b/dev-python/reflink/reflink-0.2.2.ebuild
@@ -18,6 +18,8 @@ HOMEPAGE="
 LICENSE="MIT"
 SLOT="0"
 KEYWORDS="~amd64 ~ppc64 ~x86"
+PROPERTIES="test_privileged"
+RESTRICT="test"
 
 RDEPEND="
$(python_gen_cond_dep '
@@ -41,15 +43,13 @@ src_prepare() {
 }
 
 src_test() {
-   rm -rf reflink || die
-
-   if [[ ${EUID} != 0 ]]; then
-   ewarn "Tests require root permissions (FEATURES=-userpriv)"
-   elif [[ ! -c /dev/loop-control ]]; then
+   if [[ ! -c /dev/loop-control ]]; then
die "Tests require /dev/loop-control"
-   else
-   local -x PYTEST_DISABLE_PLUGIN_AUTOLOAD=1
-   addwrite /dev
-   distutils-r1_src_test
fi
+
+   rm -rf reflink || die
+
+   local -x PYTEST_DISABLE_PLUGIN_AUTOLOAD=1
+   addwrite /dev
+   distutils-r1_src_test
 }
-- 
2.43.2




[gentoo-dev] [PATCH 1/2] metadata/layout.conf: Recognize PROPERTIES=test_privileged

2024-02-22 Thread Michał Górny
Bug: https://bugs.gentoo.org/924585
Signed-off-by: Michał Górny 
---
 metadata/layout.conf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

PR: https://github.com/gentoo/gentoo/pull/35487

diff --git a/metadata/layout.conf b/metadata/layout.conf
index fff2d6072f99..5fb0b20d5f8a 100644
--- a/metadata/layout.conf
+++ b/metadata/layout.conf
@@ -1,11 +1,11 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # For details on this file, see the layout.conf section of the
 # portage(5) man page.
 
 # Allow specific PROPERTIES and RESTRICT values in ebuilds.
-properties-allowed = interactive live test_network
+properties-allowed = interactive live test_network test_privileged
 restrict-allowed = binchecks bindist fetch installsources mirror preserve-libs 
splitdebug strip test userpriv
 
 # manifest-hashes specify hashes used for new/updated entries
-- 
2.43.2




[gentoo-dev] Package up for grabs: app-shells/bash-completion

2024-02-21 Thread Michał Górny
Hello,

app-shells/bash-completion is looking for a new maintainer.  The package
is full of random test regressions, and I don't have the energy to deal
with them.  On top of that, it seems that upstream broke them even more
in 2.12.0 (compared to the same tests in 2.11).

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH] llvm-r1.eclass: Use := slot op in examples

2024-02-21 Thread Michał Górny
Include the ':=' slot operator in examples.  While generally LLVM
does not change its ABI within a single slot, it technically reserves
that possibility and it has historically been used in LLVM 11.1.0.

Signed-off-by: Michał Górny 
---
 eclass/llvm-r1.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/llvm-r1.eclass b/eclass/llvm-r1.eclass
index 658946a1ecbd..075df9218be8 100644
--- a/eclass/llvm-r1.eclass
+++ b/eclass/llvm-r1.eclass
@@ -31,8 +31,8 @@
 # DEPEND="
 #   dev-libs/libfoo[${LLVM_USEDEP}]
 #   $(llvm_gen_dep '
-# sys-devel/clang:${LLVM_SLOT}
-# sys-devel/llvm:${LLVM_SLOT}
+# sys-devel/clang:${LLVM_SLOT}=
+# sys-devel/llvm:${LLVM_SLOT}=
 #   ')
 # "
 # @CODE
@@ -158,8 +158,8 @@ unset -f _llvm_set_globals
 # @CODE
 # DEPEND="
 #   $(llvm_gen_dep '
-# sys-devel/clang:${LLVM_SLOT}
-# sys-devel/llvm:${LLVM_SLOT}
+# sys-devel/clang:${LLVM_SLOT}=
+# sys-devel/llvm:${LLVM_SLOT}=
 #   ')
 # "
 # @CODE
-- 
2.43.2




[gentoo-dev] Last rites: dev-python/pendulum

2024-02-20 Thread Michał Górny
# Michał Górny  (2024-02-20)
# Unmaintained.  The recently merged rewrite in Rust broke compilation
# on 32-bit architecture.  No revdeps left.
# Removal on 2024-03-21.  Bug #924881.
dev-python/pendulum

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH v2 4/5] distutils-r1.eclass: wire up meson-python to meson.eclass

2024-02-19 Thread Michał Górny
On Tue, 2024-02-20 at 01:14 -0500, Eli Schwartz wrote:
> 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

We use '==' throughout.

> + 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

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH 3/3] distutils-r1.eclass: fix src_configure to handle flag-o-matic correctly

2024-02-19 Thread Michał Górny
On Mon, 2024-02-19 at 23:26 -0500, Eli Schwartz wrote:
> 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

Sigh.  While I see your point, this feels like simultaneously breaking
and half-assed change.  If we were to remove it, I'd rather move
the logic somewhere where it is actually called once.

>  
>   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)

Sounds like it will be appended multiple times.

>   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)

Likewise.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH 2/3] distutils-r1.eclass: wire up meson-python to meson.eclass

2024-02-19 Thread Michał Górny
On Mon, 2024-02-19 at 23:26 -0500, Eli Schwartz wrote:
> 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[@]}"

NAK.  You're calling configure twice, possibly with disjoint results. 
This is bound to be a mess, as you discovered yourself.

>   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

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


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

2024-02-19 Thread Michał Górny
On Mon, 2024-02-19 at 22:14 +, Robin H. Johnson wrote:
> On Mon, Feb 19, 2024 at 02:08:32PM -0800, Robin H. Johnson wrote:
> > Allow checking more disk space, for users with many split volumes and
> > ever-larger packages.
> > 
> > gentoo-kernel-bin:
> > / >=350MB/version (in /lib/modules)
> > /boot >=40MB/version
> > 
> > rust-bin:
> > /opt  >=450MB/version
> Meta:
> Is this the time where we should rethink the CHECKREQS syntax?
> 
> CHECKREQS_DISK="/:2G /opt/random:1G /usr:1G" etc?
> If we need to support paths with space, newline or array here.
> 

Precisely what I wanted to say.  Instead of adding more variables, let's
add an array and mark the existing vars as legacy.

CHECKREQ_DISK=(
  /opt:...
  /usr:...
)

However, Andrew's comment poses a bigger problem here.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] pkgcheck scan: error: failed running git log: fatal: unrecognized argument: --no-find-copies

2024-02-16 Thread Michał Górny
On Fri, 2024-02-16 at 16:51 +, Andrey Grozin wrote:
> I'm trying to bump master-pdf-editor and get
> 
> grozin@bilbo /home/gentoo/app-text/master-pdf-editor $ pkgcheck scan
> pkgcheck scan: error: failed running git log: fatal: unrecognized 
> argument: --no-find-copies
> grozin@bilbo /home/gentoo/app-text/master-pdf-editor $ pkgdev commit -m 
> 'bump to 5.9.82'
> pkgdev commit: error: failed running git log: fatal: unrecognized 
> argument: --no-find-copies
> grozin@bilbo /home/gentoo/app-text/master-pdf-editor $
> 
> What has happened with pkgcheck scan?
> 

What happened to the ability to search Bugzilla and/or upstream bug
tracker?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] games-strategy/wargus: Fix running it with games-engines/stratagus[debug]

2024-02-15 Thread Michał Górny
On Thu, 2024-02-15 at 14:23 +, parona wrote:
> On Thursday, 15 February 2024 at 16:09, Michał Górny  
> wrote:
> 
> > On Thu, 2024-02-15 at 14:21 +0100, z...@gentoo.org wrote:
> > 
> > > Am 15.02.24 um 13:59 schrieb Eli Schwartz:
> > > 
> > > > 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 z...@gentoo.org
> > > > > ---
> > > > > 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.
> > > 
> > > Exactly. It would even be simpler to patch that renaming out. I will
> > > send a change to stratagus-ebuild.
> > > 
> > > > Why is the executable name different, anyway?
> > > 
> > > I have no clue. My guess is to have a separate executable.
> > > 
> > > This is from stratagus CMakeLists.txt:
> > >  cut ===
> > > if(CMAKE_BUILD_TYPE STREQUAL "Debug")
> > > set_target_properties(stratagus PROPERTIES OUTPUT_NAME stratagus-dbg)
> > > endif()
> > >  cut ===
> > 
> > 
> > Wait, why are we changing CMAKE_BUILD_TYPE in the first place?!
> > 
> 
> The debug use flag could be dropped altogether or at least replaced with 
> append-cppflags -DDEBUG instead of setting CMAKE_BUILD_TYPE. The only 
> relevant thing that setting CMAKE_BUILD_TYPE to Debug does is to add -DDEBUG 
> to CPPFLAGS.
> 
> https://github.com/search?q=repo%3AWargus%2Fstratagus+%2F%23ifdef+DEBUG%2F=code
> 

Oh, sorry, I've just realized that I'm maintaining stratagus these days.
Will fix it, thanks!

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] games-strategy/wargus: Fix running it with games-engines/stratagus[debug]

2024-02-15 Thread Michał Górny
On Thu, 2024-02-15 at 14:21 +0100, z...@gentoo.org wrote:
> Am 15.02.24 um 13:59 schrieb Eli Schwartz:
> > 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.
> > 
> Exactly. It would even be simpler to patch that renaming out. I will 
> send a change to stratagus-ebuild.
> 
> > Why is the executable name different, anyway?
> > 
> I have no clue. My guess is to have a separate executable.
> 
> This is from stratagus CMakeLists.txt:
>  cut ===
> if(CMAKE_BUILD_TYPE STREQUAL "Debug")
>   set_target_properties(stratagus PROPERTIES OUTPUT_NAME stratagus-dbg)
> endif()
>  cut ===
> 

Wait, why are we changing CMAKE_BUILD_TYPE in the first place?!

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/fb-re2

2024-02-14 Thread Michał Górny
# Michał Górny  (2024-02-14)
# Abandoned upstream in 2020.  Has a fork that has last been released
# in 2021.  No revdeps.
# Removal on 2024-03-15.  Bug #833088.
dev-python/fb-re2

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


  1   2   3   4   5   6   7   8   9   10   >