| Summary: | config dynlinked against older xmonad version breaks when version is updated | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Erik del Toro Streb <erik> |
| Component: | xmonad | Assignee: | Jens Petersen <petersen> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | fedora, haskell-devel, petersen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-10 01:27:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Erik del Toro Streb
2012-03-25 13:46:14 UTC
Additional info: A file called /usr/lib64/ghc-7.0.4/xmonad-contrib-0.10/libHSxmonad-contrib-0.10-ghc7.0.4.so exists, so I don’t know why xmonad complains and how this got broken. No manual changes to the system. Sorry you need to recompile your xmonad config for the version change. The easiest way to do that is $ xmonad --recompile which forces a recompilation. That should fix your issue. This kind of problem is the reason why I reverted the Fedora specific patch to xmonad to use dynamic instead of static linking. If we get to do this again we'd need to think about how to handle this problem in the future, but perhaps I should think about a workaround for your upgrade case. (In reply to comment #2) > Sorry you need to recompile your xmonad config for the version change. > > The easiest way to do that is > > $ xmonad --recompile > > which forces a recompilation. That should fix your issue. Thank you very much. That fixed it. > If we get to do this again we'd need to think about how to handle > this problem in the future, but perhaps I should think about a > workaround for your upgrade case. Why not put a recompile command in the post of the rpm-update-package? (In reply to comment #3) > Why not put a recompile command in the post of the rpm-update-package? We'd have to run it per user that runs xmonad. > > Why not put a recompile command in the post of the rpm-update-package?
>
> We'd have to run it per user that runs xmonad.
Right - perhaps it could be done in xmonad-start,
though it could be a little messy.
I have added a fix in xmonad-0.10-7.fc18 such that xmonad-start (which normally starts xmonad in Fedora) will try to check if a user's custom binary has broken shared libs and if so touch xmonad.hs to force recompiling at startup. A test upgrade to pre-release F17 made me realise that this issue also affects people upgrading to F17 because of the gmp soname bump. I plan to backport the fix to F16 and F17 shortly. xmonad-0.10-8.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/xmonad-0.10-8.fc17 xmonad-0.10-3.5.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/xmonad-0.10-3.5.fc16 Package xmonad-0.10-9.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xmonad-0.10-9.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-8438/xmonad-0.10-9.fc17 then log in and leave karma (feedback). xmonad-0.10-11.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. xmonad-0.10-3.7.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |