https://bugzilla.redhat.com/show_bug.cgi?id=2180418 --- Comment #12 from Alexander Ploumistos <alex.ploumistos@xxxxxxxxx> --- 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. -- 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 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
