I believe the %post section should be written as follows: %if %{with xinit} %post %else %post xinit %endif %{_sbindir}/alternatives --install %{_sysconfdir}/X11/xinit/xinputrc xinputrc %{_xinputconf} 83 || : Perhaps the %postun section also needs to be updated accordingly? I'm not really sure. Reproducible: Always Steps to Reproduce: none Actual Results: none Expected Results: none none
Sorry, the changes I proposed are for f40 and do not apply to f41 and later branches. Subsequent branches should be modified as appropriate.
Thank you for the suggestion. Seems your patch is needed for f40. For f41: %post xinit %{_sbindir}/alternatives --install %{_sysconfdir}/X11/xinit/xinputrc xinputrc %{_xinputconf} 83 || :
Looks fine.
FEDORA-2024-01763b95cb (ibus-1.5.31~rc1-2.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-01763b95cb
FEDORA-2024-f564837cb2 (ibus-1.5.30-7.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-f564837cb2
FEDORA-2024-01763b95cb has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-01763b95cb` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-01763b95cb See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-f564837cb2 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f564837cb2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f564837cb2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-01763b95cb (ibus-1.5.31~rc1-2.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-f564837cb2 (ibus-1.5.30-7.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
TL;DR: I suspect this change possibly left systems with stale /etc/alternatives/xinputrc and /var/lib/alternatives/xinputrc files. This was done in rawhide with commit da7fce084d2cd6bc6d96bc4a1269245a0e7b6750 ("Resolves #2321990 Move xinit post scripts"). Link: https://src.fedoraproject.org/rpms/ibus/c/da7fce084d2cd6bc6d96bc4a1269245a0e7b6750 But if one has ever upgraded ibus to a release that included that commit _on a system that didn't have ibus-xinit installed_ I think neither /etc/alternatives/xinputrc nor /var/lib/alternatives/xinputrc will ever be removed "automagically". I need to check the timestamps on those files with what has probably happened to my current setup in the last few years - that system had a pretty wild ride the last few years - but if things match this theory I might reopen this report.
TL;DR: the timestamps make sense, mostly. But can anyone confirm this situation on their system? You need to have a system upgraded from Fedora 40 or older to run into my issue. 0) The timestamp on /etc/alternatives/xinputrc matches the timestamp of that file in the squashfs.img of the Fedora 38 Workstation Live image. (That is a dangling symlink, because apparently ibux-xinit wasn't shipped by default.) My journey on this system began with Fedora 38. And I don't see why I should have ever installed ibus-xinit. 1) The timestamp on /var/lib/alternatives/xinputrc is a few weeks older than the release of ibus-1.5.30-7.fc40. That is the first Fedora 40 update of ibus shipping the fix for this bug. (It was also the last update to ibus for Fedora 40.) I'm unsure why the timestamp got updated with that update, though. 2) So since I've never uninstalled ibus I never triggered its %postun. And since I've never installed or uninstalled ibus-xinit I never triggered its %postun. Ergo, "alternatives --remove xinputrc" never was run on my system. 3) So it seems the fix for this issue does indeed make stale /etc/alternatives/xinputrc and /var/lib/alternatives/xinputrc files possible. Can anyone confirm?
(In reply to Paul Bolle from comment #10) > TL;DR: I suspect this change possibly left systems with stale > /etc/alternatives/xinputrc and /var/lib/alternatives/xinputrc files. > > This was done in rawhide with commit > da7fce084d2cd6bc6d96bc4a1269245a0e7b6750 ("Resolves #2321990 Move xinit post > scripts"). Link: > https://src.fedoraproject.org/rpms/ibus/c/ > da7fce084d2cd6bc6d96bc4a1269245a0e7b6750 > > But if one has ever upgraded ibus to a release that included that commit _on > a system that didn't have ibus-xinit installed_ I think neither > /etc/alternatives/xinputrc nor /var/lib/alternatives/xinputrc will ever be > removed "automagically". > OK, probably it's good to keep the postrun in both ibus core and ibus xinit for the back compatibility for a while. It would be good to open a new bug.