https://bugzilla.redhat.com/show_bug.cgi?id=2180418
Alexander Ploumistos <alex.ploumistos(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Review Request: |Review Request:
|python-input-remapper - An |input-remapper - An easy to
|easy to use tool to change |use tool to change the
|the mapping of your input |mapping of your input
|device buttons |device buttons
--- Comment #7 from Alexander Ploumistos <alex.ploumistos(a)gmail.com> ---
This is still in progress, I ended up in a mess that I've barely started to
untangle and I have a lot of questions.
Spec URL:
https://alexpl.fedorapeople.org/packages/input-remapper/input-remapper.spec
SRPM URL:
https://alexpl.fedorapeople.org/packages/input-remapper/input-remapper-2....
Scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=101415782
(In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
I think the package name should be just 'input-remapper'.
You are right, in the meantime I looked at other packages written in python
that use their upstream name. This falls well under this category, so I've
changed the name everywhere.
The description should be wrapped to <= 80 columns, right now
it's 67.
It'd be nice to add some general information how the package works
(by injecting input system events?).
I've added a line (hopefully) explaining what happens behind the scenes,
without getting too technical.
%autorelease and %autochangelog are now the recommended defaults
(
https://pagure.io/packaging-committee/pull-request/1255 was merged).
I co-maintain bubblemail, which uses a separate changelog file, that I edit
whenever it's needed. I created a separate changelog file for input-remapper, I
placed it in ~/rpmbuild/SOURCES/ but it's not part of the source rpm (created
with `rpmbuild -bs`) and the release does not get incremented. Is there a way
to do that when the package is not (yet) in a repo?
> %__mv
> /usr//bin/systemctl
> %__install
Just 'mv', 'systemctl', 'install' are fine. The guidelines do NOT
say that
macros should be used, and there is really no reason to circument $PATH
in a subset of cases.
Fixed.
But I don't think the call to 'systemctl start' is OK.
The guidelines
say that presets should be used [2]. So I think you should either:
- drop the call to systemctl, or
- move it to %posttrans and check that 'systemctl is-enabled
input-remapper.service'
returns 'enabled' and only start the service in that case. (This would
mean that
the presets are respected, but the service is available immediately after
package installation if enabled.)
Oh, and packages are not allowed to include presets [2].
So %SOURCE1 must be dropped.
You can open a ticket or pull request to add the service to presets in
fedora-release.
[2]
https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/
I had read this part and I got the impression that since the program does
require manual configuration, it should be disabled, hence the preset:
https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices...
It's not possible to know beforehand what hardware each user has and what they
might want to remap, so it makes no sense to enable the service. Have I
misunderstood it completely? Are we talking about different things?
> BuildRequires: git
Is this necessary?
Gone.
> %systemd_postun %{up_name}.service
%systemd_postun_with_restart would be better. Unless the service breaks on
restart,
it should be restarted on upgrades.
It shouldn't/doesn't break, so I've changed it.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #6)
Requires are duplicated. The automatic dependency generator seems to
work
fine, so the manual Requires for python stuff should be dropped:
I think I removed everything that was superfluous, I've only left
gtksourceview4.
> python3-input-remapper.noarch: W: non-conffile-in-etc
/etc/dbus-1/system.d/inputremapper.Control.conf
That file can be moved to /usr/share/dbus-1/system.d/.
Moved.
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/fr/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/fr_FR/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/it/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/it_IT/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/ru/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/ru_RU/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/sk/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/sk_SK/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/uk/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/uk_UA/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/zh/LC_MESSAGES/input-remapper.mo
> python3-input-remapper.noarch: W: file-not-in-%lang
/usr/share/input-remapper/lang/zh_CN/LC_MESSAGES/input-remapper.mo
%find_lang should be used [3].
[3]
https://docs.fedoraproject.org/en-US/packaging-guidelines/
#handling_locale_files
After six hours of hairpulling I decided to declare defeat. I tried different
combinations of the (limited) options offered by %find_lang, even"--all-name",
but it plainly refuses to find the files:
+ /usr/lib/rpm/find-lang.sh
/builddir/build/BUILDROOT/input-remapper-2.0.0-1.fc39.x86_64 input-remapper
No translations found for input-remapper in
/builddir/build/BUILDROOT/input-remapper-2.0.0-1.fc39.x86_64
Yet the files are there, under
(/var/lib/mock/fedora-rawhide-x86_64/root)/builddir/build/BUILDROOT/input-remapper-2.0.0-1.fc39.x86_64/usr/share/input-remapper/lang.
By the way, it's usage note states:
Usage: /usr/lib/rpm/find-lang.sh TOP_DIR PACKAGE_NAME [prefix]
It is not possible to define TOP_DIR, I tried telling it to go look in lang/.
What should I have done? If by some miracle I manage to get this working, how
do I declare the language list in the %files section?
Would this below work?
%files -f %{pyproject_files} -f %{name}.lang
Finally (for now), what can I do about these warnings?
RPM build warnings:
File listed twice: /usr/bin/input-remapper-control
File listed twice: /usr/bin/input-remapper-gtk
File listed twice: /usr/bin/input-remapper-reader-service
File listed twice: /usr/bin/input-remapper-service
File listed twice:
/usr/lib/python3.11/site-packages/input_remapper-2.0.0.dist-info
File listed twice:
/usr/lib/python3.11/site-packages/input_remapper-2.0.0.dist-info/INSTALLER
File listed twice:
/usr/lib/python3.11/site-packages/input_remapper-2.0.0.dist-info/LICENSE
File listed twice:
/usr/lib/python3.11/site-packages/input_remapper-2.0.0.dist-info/METADATA
File listed twice:
/usr/lib/python3.11/site-packages/input_remapper-2.0.0.dist-info/WHEEL
File listed twice:
/usr/lib/python3.11/site-packages/input_remapper-2.0.0.dist-info/top_level.txt
File listed twice: /usr/lib/python3.11/site-packages/inputremapper
File listed twice:
/usr/lib/python3.11/site-packages/inputremapper/__init__.py
File listed twice:
/usr/lib/python3.11/site-packages/inputremapper/__pycache__
File listed twice:
/usr/lib/python3.11/site-packages/inputremapper/__pycache__/__init__.cpython-311.opt-1.pyc
File listed twice:
/usr/lib/python3.11/site-packages/inputremapper/__pycache__/__init__.cpython-311.pyc
File listed twice:
/usr/lib/python3.11/site-packages/inputremapper/__pycache__/daemon.cpython-311.opt-1.pyc
File listed twice:
/usr/lib/python3.11/site-packages/inputremapper/__pycache__/daemon.cpython-311.pyc
File listed twice:
/usr/lib/python3.11/site-packages/inputremapper/__pycache__/exceptions.cpython-311.opt-1.pyc
[…]
Do I need to undeclare everything that %{pyproject_files} handles?
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2180418