Description of problem: Dosbox-staging is not available in Fedora 33 Version-Release number of selected component (if applicable): 0.76.0-2 How reproducible: Always Steps to Reproduce: 1. dnf install dosbox-staging Actual results: Package not found Expected results: Package found and installed Additional info: Is available for Fedora 34 and Rawhide. In src.fedoraproject.org, f33 branch points to the same commit as f34 [1] But there is no update for Fedora 33 in Bodhi [2] From the discussion at bug 1884608 I get the impression that dosbox-staging should work on Fedora 33 (but not 32). If so, adding it in F33 would be great, since the standard dosbox does not work well - arrow keys do not do anything for instance. [1]: https://src.fedoraproject.org/rpms/dosbox-staging/commits/rawhide [2]: https://bodhi.fedoraproject.org/updates/?search=dosbox-staging
FEDORA-2021-c96edcd678 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c96edcd678
@oturpe Thanks for the report - I made the build for F33 but forgot to submit it to Bodhi after I tested it on F34. I pushed the update to Bodhi. If 0.76.0-2 works for you, then vote to raise karma so the package can be pushed to stable :)
FEDORA-2021-c96edcd678 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2021-c96edcd678 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c96edcd678 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Great! I will vote in Bodhi as soon as the update is available in testing repository so I can try to get it from the repositories. However, in the meantime, I downloaded the rpm from Koji and installed that. Unfortunately, of the five dos games I currently have installed, two (Master of Orion 2 and Settlers 2) fail to start due to selinux violation. For example this is what happens with Settlers 2: $ cd Settlers\ 2/ $ dosbox S2.EXE dosbox-staging version 0.76.0 --- (snip) Setting execute permission on the code cache has failed Segmentation fault (core dumped) And SELinux Alert Browser pops up. The gist of its complaint is: SELinux is preventing dosbox from using the execheap access on a process. Raw Audit Messages type=AVC msg=audit(1614887505.954:1495): avc: denied { execheap } for pid=11114 comm="dosbox" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Master of Orion 2 crashes in the same way. This is issue 253 in dosbox-staging [1]. Since some games that work with the standard dosbox do not work with dosbox-staging, I suggest this update is put on hold until the problem is fixed. Since configuring dosbox-staging with `core = normal` makes everything work for now, and the root cause will be fixed upstream eventually, I suppose the most actionable would be to ship a working configuration file in the rpm? [1]: https://github.com/dosbox-staging/dosbox-staging/issues/253
Ok, maybe shipping a working configuration file is not as easy as I thought, since according to dosbox-staging wiki [1], there is no layering of config files where the base config is read from /etc and then overwritten with user config, project config etc. Perhaps a patch that forces `core = normal` then, if such can be easily made for the config file parsing part? [1]: https://github.com/dosbox-staging/dosbox-staging/wiki/Config-file-FAQ
As for issue 253 [1] (SELinux protection kicking in / "W^X memory issue") - this is a bug, but it's not a regression when compared to 0.74-3. This bug is present in all versions of DOSBox. 0.74-3 does not have x86_64 dynamic recompiler (`core = dynamic` does not work on x86_64), so it "seems to work" in 0.74-3, because emulator silently falls back to `core = normal` (which breaks other games, e.g. Carmageddon has black bars across the screen or Stargunner has random game speedups and slowdowns). The only valid workaround ATM is for a user to either disable SELinux or manually select `core = normal` for some games. :( This is a high-priority bug for us (fix planned for 0.77.0), but it's highly unlikely that we'll backport it to 0.76.x release… [1] https://github.com/dosbox-staging/dosbox-staging/issues/253 Layering of config files: yup, unfortunately, this is also a problem. Right now it's not possible to provide system-wide conf files in /etc - the configuration file system we inherited from DOSBox is designed in a way that makes it almost impossible to add proper layering and maintain backwards-compatibility at the same time (the issue is in how DOSBox handles [autoexec] sections - unlike all other ini sections, autoexec lines are merged and not replaced; in such case conf layering would break DOS games being started via GUI frontends like Lutris). > Perhaps a patch that forces `core = normal` then, if such can be easily made for the config file parsing part? Such patch is possible and it would be tiny… I do have some reservations about doing it though (default .conf file is not overwritten during upgrades so some users could be stuck in suboptimal core=normal for years after we would have W^X issue sorted out). I'll do some experiments, maybe another solution is possible. In the meantime - thank you for thorough testing! :)
Thank you for explanations. I completely understand the situation where fixing bugs uncovers other, dormant bugs. Certainly, in such situations, it is very difficult to get releases out. Patching in a way that changes how default configuration file is written does not sound good. Ideally, the file should be unchanged, but the problem values `auto` and `dynamic` and should be just interpreted as `normal`. Then, when new dosbox-staging that does not try to do heapexec anymore, the patch can be discarded. I will take a look at dosbox-staging code and see it could be done. Regarding disabling SELinux, a less drastic action would be to allow execheap: $ sudo setsebool -P selinuxuser_execheap on This change cannot be packaged, of course, but writing this down here in case somebody needs it.
This pull request disables the problematic behavior when default configuration is used: https://src.fedoraproject.org/rpms/dosbox-staging/pull-request/1#
Discussion about the crash continues at bug 1960865.
There is new version 0.77 that does not crash packaged, so this can be finally properly resolved. I will take care of this, for both Fedora 33 and Fedora 34.
FEDORA-2021-0ef14bbe74 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-0ef14bbe74
FEDORA-2021-0ef14bbe74 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-0ef14bbe74` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0ef14bbe74 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-0ef14bbe74 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.