In fact it doesn't work on either py3.11 or py3.12 but that is because
it doesn't know how to find any logs. The actual package seems to
function equivalently, and passes unittest mocks, and can load logs via
the command line, so I guess the py3.12 migration is not, itself, a
problem.
Closes: https://bugs.gentoo.org/929350
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
It was removed from the stdlib, and now comes from setuptools. This
package cannot actually be built without it, which is problematic if you
don't yet have the rest of the python ecosystem built and hence no
sideloaded setuptools.
Fixes: f60a09dfb2
Bug: https://bugs.gentoo.org/929486
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
They control inert files installed to the plugins directory, and you
have to enable the plugins in the pluma settings.
Half these plugins require nothing other than python itself, and cannot
be disabled other than via --disable-python, which means offering to
refrain from installing them is a QA violation of PG-0301 (installation
of small files).
The remaining plugins have trivially satisfiable dependencies and still
violate the small files policy. The build system provides zero help
here, since the dependencies are automagically detected and there is no
option to disable them.
Having 5 different USE flags on top of the python one is pointless
complexity, so delete them.
...
Also while we are moving the USE-dependent plugin dependencies into the
python block? dbus-python was missing a USEDEP on the python impl, so
even enabling synctex would not actually help... add that in properly.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
There is a ./configure --enable-python but it was not passed. As a
result it automagically detected python (and always succeeded since core
distro tooling requires one).
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Most likely this was copy-pasted from app-editors/gedit-plugins. In its
current state, there isn't even a good explanation for how this ever
built on anyone's machine, or passed stabilization checks, except that
stabilization of pluma-plugins plainly occurred in a batch alongside,
but after, pluma itself, leading to silently available undeclared
dependencies.
And yes, not only does this package check in configure for an installed
pluma -- it builds C code that includes headers named "pluma".
Most likely, anyone using the package doesn't suffer this confusion,
because they already have pluma installed; still, this metadata problem
is rather bad. Revbump via `mv`, drop old + immediate to stable, because
we want to get the metadata fix out ASAP.
Bug: https://github.com/gentoo/gentoo/pull/28508
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
... in the slot for gcr 3.x
It is only used by the build system, which runs some scripts that will
work on any version of the python stdlib. It's kind of pointless to
require a specific one but do not argue; python-any-r1 is basically
lightweight on the package metadata.
It is removed in gcr 4 anyway.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
... in the slot for gcr 3.x
It is only used by the build system, which runs some scripts that will
work on any version of the python stdlib. It's kind of pointless to
require a specific one but do not argue; python-any-r1 is basically
lightweight on the package metadata.
It is removed in gcr 4 anyway.
Closes: https://bugs.gentoo.org/929290
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
In gcr 3, some *.py scripts were executed by the build system, and could
technically use any version of python. In gcr 4, it is a moot point
since those scripts were dropped and python is no longer run at all.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>