Spec URL: https://alexpl.fedorapeople.org/packages/python-input-remapper/python-input-remapper.spec SRPM URL: https://alexpl.fedorapeople.org/packages/python-input-remapper/python-input-remapper-2.0.0-1.fc37.src.rpm Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=98975689 Description: An easy to use tool to change the mapping of your input device buttons. Supports mice, keyboards, gamepads, X11, Wayland, combined buttons and programmable macros. Allows mapping non-keyboard events (click, joystick, wheel) to keys of keyboard devices. Fedora Account System Username: alexpl
Copr build: https://copr.fedorainfracloud.org/coprs/build/5690113 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2180418-python-input-remapper/fedora-rawhide-x86_64/05690113-python-input-remapper/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
License field in spec file is set to LGPL-2.1-only but upstream license is rather GPL-3.0 https://github.com/sezanzeb/input-remapper/blob/main/LICENSE or did i miss something?
(In reply to Paweł from comment #2) > License field in spec file is set to LGPL-2.1-only but upstream license is > rather GPL-3.0 https://github.com/sezanzeb/input-remapper/blob/main/LICENSE > or did i miss something? Thank you Paweł, you are very right. My guess would be that I messed something up when I was switching my packages to SPDX license identifiers. Now I am going to check all my other packages… Considering that most of the source files use GPLv3+ and taking into account the advice from legal[1], I have set the license field to GPL-3.0-or-later in the spec file. I am going to get in touch with upstream about that.
The missing link: 1. https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/N53I6BXKTPR2YQRLGBIL52FHUM4VIQBA/
I think the package name should be just 'input-remapper'. The guidlines [1] say: > Packages that primarily provide applications, services or any kind of executables > SHOULD be named according to the general Fedora naming guidelines (e.g. ansible). > > Consider adding a virtual provide according to Library naming above (e.g. python3-PROJECTNAME), > if it would help users find the package. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_application_naming 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?). > Release: 1%{?dist} %autorelease and %autochangelog are now the recommended defaults (https://pagure.io/packaging-committee/pull-request/1255 was merged). > %__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. 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/ > BuildRequires: git Is this necessary? > %systemd_postun %{up_name}.service %systemd_postun_with_restart would be better. Unless the service breaks on restart, it should be restarted on upgrades.
Requires are duplicated. The automatic dependency generator seems to work fine, so the manual Requires for python stuff should be dropped: Requires -------- python3-input-remapper (rpmlib, GLIBC filtered): /bin/sh /usr/bin/python3 gtksourceview4 python(abi) python3-evdev python3-gobject python3-pydantic python3-pydbus python3.11dist(evdev) python3.11dist(pydantic) python3.11dist(pydbus) python3.11dist(pygobject) python3.11dist(setuptools) > 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/. > 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
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.0.0-1.fc38.src.rpm 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/#_must_not_require_manual_configuration_to_function 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?
Copr build: https://copr.fedorainfracloud.org/coprs/build/5940677 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2180418-input-remapper/fedora-rawhide-x86_64/05940677-input-remapper/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
(In reply to Alexander Ploumistos from comment #7) > > %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? Use 'fedpkg srpm' instead of 'rpmbuild -bs'. Note that 'changelog' file needs to be committed to the repo, it's not enough to just create it. > 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/ > #_must_not_require_manual_configuration_to_function Oh, I didn't look at the file contents. It has 'disable input-remapper.service', so this has no effect; 'disable' is the default. Please just drop this file. > 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: I don't know too much about this either. Let's leave it for now, maybe somebody else will have some idea. > 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 ... > Do I need to undeclare everything that %{pyproject_files} handles? %{pyproject_files} would normally handle everything that is installed via the python installer, so only stuff like READMEs and license files would be listed explicitly. In a way, that's the point: we want the automatic mechanism to cover as much of the installation and packaging and metadata as possible.
To clarify this part: > Oh, I didn't look at the file contents. It has 'disable input-remapper.service', > so this has no effect; 'disable' is the default. Please just drop this file. Earlier I wrote: > You can open a ticket or pull request to add the service to presets in fedora-release. I assumed without looking that you want the service to be enabled upon installation. But you want it to be disabled, so please disregard this: there is no need to do anything special about presets, and the the default scriptlet you already have does the right thing.
> if [ $1 -eq 1 ] && [ -x systemctl ]; then > systemctl start %{name}.service > /dev/null 2>&1 || : > fi This must to be removed. >> 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: >I don't know too much about this either. Let's leave it for now, >maybe somebody else will have some idea. /usr/lib/rpm/find-lang.sh checks only some pecific locations for the language files. This package uses different locations, so it is hard to reconcile the two. But it also has just a bunch of those files, so I think it's OK to just ignore the issue (%lang attribute is not applied). > URL: https://github.com/sezanzeb https://github.com/sezanzeb/input-remapper would be better. /usr/share/doc/input-remapper/README.md is not useful for Fedora users. It describes how to install the package from the web and knows nothing about the ready-to-install rpm. My suggestion would be to add a README.Fedora file that mentions 'dnf install input-remapper', and 'systemctl enable --now input-remapper' and gives some instructions how to start configuring the service under gnome-shell and other systems. With the above changes: + package name is correct + license is acceptable for Fedora (GPL-3.0-or-later) + license is specified correctly + P/R/BR look OK + builds and installs OK + the program seems to work (*). (*) I did a very simple test that remapping 'x' to 'KEY_BACKSLASH' works as expected for a user logged in with gnome. I also wanted to remap to KEY_A, but the dialog says KEY_A is not valid. It seems something is buggy about the listing of the keys, and more complicated keys like KEY_BACKSLASH are accepted, but simple ones like KEY_A are not. But it's also possible I misunderstood the interface, I wasn't trying very hard. Anyway, the packaging is OK. Whether the package has bugs is not in scope of the review, so I only did some very superficial check.
I wasn't going to, but I think I got everything, with the caveat that my brain is already in bed without me. I'll post on devel about the issues with %find_lang, I hope someone has an answer. Spec URL: https://alexpl.fedorapeople.org/packages/input-remapper/input-remapper.spec SRPM URL: https://alexpl.fedorapeople.org/packages/input-remapper/input-remapper-2.0.0-1.fc39.src.rpm Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=101469697 (In reply to Zbigniew Jędrzejewski-Szmek from comment #9) > (In reply to Alexander Ploumistos from comment #7) > > > %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? > Use 'fedpkg srpm' instead of 'rpmbuild -bs'. Note that 'changelog' file needs > to be committed to the repo, it's not enough to just create it. I did a 'git init' to make a repo of my local directory, I added all the files, including the changelog and commited the changes. I did the dance as described in https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/ and I ended up with input-remapper-2.0.0-1.fc39.src.rpm, though 'rpm -qp --changelog input-remapper-2.0.0-1.fc39.src.rpm' starts at 2.0.0-3. Of course, I got the same errors from rpmlint as we saw with pyinstrument, e.g. "W: incoherent-version-in-changelog 2.0.0-3 ['2.0.0-1.fc39', '2.0.0-1']". Where is the changelog hidden? <whining> Why do we prefer this for local builds to "rpmbuild -bs foo.spec && mock foo.src.rpm && rpmlint *.rpm"? </whining> > > 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/ > > #_must_not_require_manual_configuration_to_function > Oh, I didn't look at the file contents. It has 'disable > input-remapper.service', > so this has no effect; 'disable' is the default. Please just drop this file. Dropped. (In reply to Zbigniew Jędrzejewski-Szmek from comment #11) > > if [ $1 -eq 1 ] && [ -x systemctl ]; then > > systemctl start %{name}.service > /dev/null 2>&1 || : > > fi > This must to be removed. Removed. > > URL: https://github.com/sezanzeb > https://github.com/sezanzeb/input-remapper would be better. Fixed. > /usr/share/doc/input-remapper/README.md is not useful for Fedora users. > It describes how to install the package from the web and knows nothing about > the ready-to-install rpm. My suggestion would be to add a README.Fedora > file that mentions 'dnf install input-remapper', and 'systemctl enable --now > input-remapper' > and gives some instructions how to start configuring the service under > gnome-shell and > other systems. Great idea, I've added a README.Fedora file, I can only hope someone finds it useful. > (*) I did a very simple test that remapping 'x' to 'KEY_BACKSLASH' works as > expected > for a user logged in with gnome. > > I also wanted to remap to KEY_A, but the dialog says KEY_A is not valid. It > seems something > is buggy about the listing of the keys, and more complicated keys like > KEY_BACKSLASH are > accepted, but simple ones like KEY_A are not. But it's also possible I > misunderstood the > interface, I wasn't trying very hard. Actually, I just wanted to write to you about this, but I ended up reworking the package. In https://github.com/sezanzeb/input-remapper/blob/main/readme/usage.md#key-names they mention: "Key names that start with KEY_ are keyboard layout independent constants that might not result in the expected output. For example using KEY_Y would result in "z" if the layout of the environment is set to german. Using y on the other hand would correctly result in "y" to be written." I could be wrong, but I think they meant to write "keyboard layout-dependent". I had actually tried this when I first started playing with the program and indeed, KEY_* is not all that reliable, except for keys like KEY_RIGHTMETA and such. You'll need to examine things through evtest, if you've got anything complicated going on. I always manage to have input devices with extra keys or keys that are supposed to do something in windows and that's why I've been going through remapping programs. If you've got a key somewhere that does nothing and it's bugging you, this is the solution! Thank you very much for your time Zbigniew, it's looking much neater now.
Created attachment 1966313 [details] The .spec file difference from Copr build 5940677 to 5945010
Copr build: https://copr.fedorainfracloud.org/coprs/build/5945010 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2180418-input-remapper/fedora-rawhide-x86_64/05945010-input-remapper/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
<sigh> I've messed up with the source tarball, here are the correct ones: Spec URL: https://alexpl.fedorapeople.org/packages/input-remapper/input-remapper.spec SRPM URL: https://alexpl.fedorapeople.org/packages/input-remapper/input-remapper-2.0.0-2.fc39.src.rpm
Created attachment 1966317 [details] The .spec file difference from Copr build 5945010 to 5945066
Copr build: https://copr.fedorainfracloud.org/coprs/build/5945066 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2180418-input-remapper/fedora-rawhide-x86_64/05945066-input-remapper/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
> Why do we prefer this for local builds to "rpmbuild -bs foo.spec && mock foo.src.rpm && rpmlint *.rpm"? It works fairly reliably for me. I think it's time to abandon those strenuous rpmlint checks. They were added because people needed to manage the changelog manually, so errors were made. But when this is automatized, the check should just be skipped. > Key names that start with KEY_ are keyboard layout independent constants "Layout" can refer to the "key map", i.e. what is set in /etc/vconsole.conf. The physical scan codes are independent of the keys that they map to later. (On the console, do 'localectl set-keymap fr', 'evtest /dev/input/eventX' (the keyboard), and press 'W'. evtest shows KEY_W, but we get 'z' on the console.) --- In README.Fedora: sudo systemctl enable --now input-remapper --- + package name is correct + latest version + license is acceptable for Fedora (GPL-3.0-or-later) + license is specified correctly + %pyproject is used as recommended by the python packaging guidelines + P/R/BR look OK + builds and installs OK + the program seems to work (see above) Package is APPROVED.
Thank you very much Zbigniew, I am really grateful! If you have any odd devices you'd like to reconfigure with input-remapper, I'll be happy to help. I'll wait a while for any input from devel (I am going to finish that message right now) before I submit my builds.
The Pagure repository was created at https://src.fedoraproject.org/rpms/input-remapper
FEDORA-2023-e7bae8683c has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e7bae8683c
FEDORA-2023-e7bae8683c has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.