Bug 1933849 - dosbox-staging not available in Fedora 33
Summary: dosbox-staging not available in Fedora 33
Alias: None
Product: Fedora
Classification: Fedora
Component: dosbox-staging
Version: 33
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Otto Liljalaakso
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2021-03-01 20:45 UTC by Otto Liljalaakso
Modified: 2021-08-07 01:14 UTC (History)
2 users (show)

Fixed In Version: dosbox-staging-0.77.0-4.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-08-07 01:14:24 UTC
Type: Bug

Attachments (Terms of Use)

Description Otto Liljalaakso 2021-03-01 20:45:05 UTC
Description of problem:
Dosbox-staging is not available in Fedora 33

Version-Release number of selected component (if applicable):

How reproducible:

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

Comment 1 Fedora Update System 2021-03-04 13:20:28 UTC
FEDORA-2021-c96edcd678 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c96edcd678

Comment 2 Patryk Obara 2021-03-04 13:27:41 UTC
@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 :)

Comment 3 Fedora Update System 2021-03-04 20:42:54 UTC
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.

Comment 4 Otto Liljalaakso 2021-03-04 21:37:52 UTC
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
    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

Comment 5 Otto Liljalaakso 2021-03-04 21:47:53 UTC
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

Comment 6 Patryk Obara 2021-03-05 17:09:54 UTC
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! :)

Comment 7 Otto Liljalaakso 2021-03-08 10:57:11 UTC
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.

Comment 8 Otto Liljalaakso 2021-03-09 20:50:26 UTC
This pull request disables the problematic behavior when default configuration is used:


Comment 9 Otto Liljalaakso 2021-06-19 18:27:57 UTC
Discussion about the crash continues at bug 1960865.

Comment 10 Otto Liljalaakso 2021-07-28 04:19:08 UTC
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.

Comment 11 Fedora Update System 2021-07-29 09:30:54 UTC
FEDORA-2021-0ef14bbe74 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-0ef14bbe74

Comment 12 Fedora Update System 2021-07-30 01:15:03 UTC
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.

Comment 13 Fedora Update System 2021-08-07 01:14:24 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.