https://bugzilla.redhat.com/show_bug.cgi?id=1961783
Major Hayden mhayden@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mhayden@redhat.co | |m) |
--- Comment #10 from Major Hayden mhayden@redhat.com ---
The base package is named as an application rather than a library (rofimoji rather than python-rofimoji), which I think is correct.
Since this is an application, I think you should put everything in the base package and drop the python3-rofimoji subpackage. The subpackage doesn’t offer an importable package or module called “rofimoji” as you would expect by its name, and the package that is installed (“picker”) is clearly
designed as the tool implementation rather than as an API.
You could move the BuildRequires and Requires from python3-rofimoji into the base rofimoji package, change
%files -n python3-%{srcname} -f %{pyproject_files}
to
%files -f %{pyproject_files}
and drop the python3-rofimoji subpackage altogether.
It wouldn’t hurt to add the following to the base package, then, although I am not convinced it is required because the package is only intended to be imported by the application:
%py_provides python3-picker
That makes sense. It's now fixed.
You can, if you like, move
Version: 5.1.0
back below
Name: %{srcname}
and the expansion of
%global tag %{version}
will still work.
Done!
You have placed
%%generate_buildrequires
%pyproject_buildrequires -r
%pyproject_buildrequires -r
as if it were part of %prep, but %generate_buildrequires is its own section. To make it less confusing, add a blank line before %generate_buildrequires.
While there is no technical requirement to put %generate_buildrequires in a particular part of the spec file, a more common placement for this would be after the base package’s %description.
Fixed. I wasn't aware that '%generate_buildrequires' was its own section until you mentioned it!
This looks like it is left over from an experiment:
echo "error" >&2
🤭 That was a mistake, indeed.
The quotes here are unnecessary and unusal:
%pyproject_save_files 'picker'
Fixed.
- I tried the package in an actual Wayland session on Fedora 34. I was unable to type into the filter field, and when I double-clicked an emoji, I got “Compositor does not support the virtual keyboard protocol” in the
terminal. Does it work for you?
This does work for me if I install 'wtype'. I tested in Sway (Wayland) yesterday and it seems to work properly. Which WM are you using? I can try it there.
I'll post the spec + SRPM shortly.