* Package name : dosbox-staging Version : 0.76 Upstream Author : The DOSBox Staging Team * URL : https://dosbox-staging.github.io/ * License : GPL-2.0-or-later Programming Lang: C, C++ Description : DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode. DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode. It features: * A built-in DOS-like console * Emulation of several PC variants: IBM PC, IBM PCjr, Tandy 1000), and CPUs (286, 386, 486, and Pentium I) * Graphics chipsets: Hercules, CGA, EGA, VGA, and SVGA * Audio solutions: PC Speaker, Tandy Sound System, Disney Sound Source, Sound Blaster series, and Gravis UltraSound * CDROM and CD Digital Audio with audio optionally encoded as FLAC, Opus, OGG/Vorbis, MP3 or WAV * Joystick emulation working with modern game controllers * Serial port emulation including IPX over UDP and Telnet over TCP/IP * Hardware-accelerated video output including integer (pixel-perfect) scaling, sharp-bilinear scaling, OpenGL shaders, and more DOSBox Staging is highly configurable and sufficiently-optimized to run any DOS game on a modern computer. Q: why is this package useful/relevant? A: Sucessor of DOSBox, which is already inside Debian Current Debian WIP repository: https://salsa.debian.org/Feignint/dosbox-staging
Why do we need both rather than upgrading dosbox? Is this package supposed to take over the existing binary package eventually? Kind regards Philipp Kern
Hello Philipp, I've been watching DOSBox development for long time and it seems their progress is very slow, with limited number of SVN commits, not yet merged SDL 2 support and no releases it doesn't seems it will thrive in future. As I understood DOSBox Staging was originally meant as a incubator for new patches, which are not yet merged into DOSBox (similar to Wine and Wine Staging) and needs to be tested, but original DOSBox authors didn't agreed to cooperate with this project. I believe this project - written with modern standards in mind, having CI and very friendly and supportive developers is currently in much better state than old DOSBox. Comparsion of technical features and abilities can be found directly here: https://github.com/dosbox-staging/dosbox-staging Best regards David Heidelberg
On Thu, 2020-11-05 at 17:41 +0100, David Heidelberg wrote: [...] [...] DOSBox seems to be under active development even though it hasn't had a release for a while. So this is an independent fork, not a successor to a dead project. (If DOSBox had become dead upstream, I would have recommended rebasing the existing dosbox source package on DOSBox Staging instead.) I think this name is also misleading. "DOSBox Staging" sounds like a development branch of the original DOSBox project, not an independent project. Are the upstream developers set on using this name or do you think they could be persuaded to use something more distinctive? Ben.
Hello Ben, I asked about possibility of changing name and the final reply is [1]. Quoting dreamer: Right now, we are fighting to convince users (and developers) to move on from using a myriad of tiny DOSBox forks (link - very incomplete, there are ~50 other dead forks I know of) or maintain their own patchsets based on 10-year old 0.74. We have already certain (hard thought for) recognition and community formed up - changing name at this point will only cause confusion and hurt the project's prospects for future. [1] https://github.com/dosbox-staging/dosbox-staging/issues/703#issuecomment-723178233 Best regards David Heidelberg
You managed to quote me before I wrote it myself here :) I will also add the first sentence from my post: > No, we are not open for changing the project name *at this time*. We > might change the name at some point, but only once we'll have a really > good reason to do so, and pros of the name change will overweight the > cons of doing so. We are already packaged by several OSes, universally using dosbox-staging name [1]. We also have our own downstreams already and even the first commercial user. [1]: https://repology.org/project/dosbox-staging/versions Changing the name would require redesigning logo and icon and make it much more difficult to merge with other forks, at no particular benefits to us or our users. The project started as a staging repo for vanilla DOSBox and we tried to cooperate with upstream for 6 months (or several years, if we count the efforts of patch maintainers who were waiting for their functionalities to be merged and are now maintainers in our repo or at least finally landed their change). This attempt at collaboration failed, but despite of that, I hope the DOSBox team will eventually be open for merging the projects, as it seems they are not interested in doing another major release again (0.74 was released 10 years ago (!)). We carefully maintain our Git history to make it feasible. We also keep the project features allowing dosbox-staging to be a drop-in replacement. We will probably change the name when it will be prudent to do so, e.g. when merging with other DOSBox fork, or if we decide to break the backwards compatibility with the vanilla DOSBox. I don't see this happening at least for another year, we still have too long backlog of community patches to investigate and merge/redesign.
Oh well, thanks for asking anyway. I suggest you make the long description clearly state that this is independent of the original DOSBox project. Ben.
Any progress on this?
On Thu, 5 Nov 2020 19:37:39 +0100 Philipp Kern <pkern@debian.org> wrote: (independent of host architecture), capable of running DOS programs that require real or protected mode. Source, TCP/IP perfect) run regards, Zuhair al-Mrayyed
This thread started more than two years ago. Since that time "vanilla" DOSBox still has the same issues and had no releases, while DOSBox Staging is now sitting at 0.80.1, and we're working towards version 0.81.0. Debian users are forced to rely on non-native packages such as Flatpak or Snap to get software that is working properly. Is naming such a big deal that it prevents our emulator from hitting Debian repositories? We are packaged by several other distributions already: https://repology.org/project/dosbox-staging/versions Please talk to us, how we can help in making DOSBox Staging packaged on Debian? Cheers, Patryk Obara
On Thu, 05 Nov 2020 21:52:10 +0000 Ben Hutchings < ben@decadent.org.uk > wrote: > DOSBox seems to be under active development even though it hasn't had a > release for a while. So this is an independent fork, not a successor > to a dead project. (If DOSBox had become dead upstream, I would have > recommended rebasing the existing dosbox source package on DOSBox > Staging instead.) The last commit to the DOSBox SVN repository ( sourceforge.net https://sourceforge.net/p/dosbox/code-0/HEAD/ ) is dated March 10th, 2023, previous one is July 14th, 2022. Looking at their bug tracker - since about mid January 2020 no bug reported was closed, hardly any of them got any response from the DOSBox team. The latest news on their web page ( www.dosbox.com https://www.dosbox.com/ ) is dated January 27th 2021. The previous one (June 26th, 2019) states: > Ideally, 0.75 should have been released by now, but some bugs took a lot longer than expected. This was 4 years ago, release did not happen to this day. DOSBox was the best thing that happened to DOS retro-gamers, it severed us well for two decades, but it is now a 0xDEAD 0xBEEF. ----- DOSBox Staging and DOSBox-X are two really actively developed forks/successors - Staging progresses more carefully, has less features, but in my experience is more stable; X is harder to configure properly, and more like yolo-developed (but still fun to use by power users!).
Dear Patryk, I am not an expert on Debian Policy, or a Debian Developer, just a passerby who is also interested in getting dosbox-staging into Debian. One issue I can see with porting this package to Debian is that there are a lot of binary blobs in contrib/resources. Debug.com, deltree.com and xcopy.exe are the worst offenders. What are these executables? I see that they are legally redistributable but they also need to be open source and that source needs to be distributed with dosbox and compiled alongside it. I'm also concerned about the CPX/CPI files in freedos-cpi and the SYS files in freedos-keyboard. What are these files? Is there any way to distribute them as source files? Like I said, I am not an expert, so take this with a pinch of salt. I believe that if dosbox-staging was packaged as it is now, it would have to go into the contrib or non-free sections. Of course, it could be packaged without these files present, but I don't know if dosbox will just break without them. Regards, David James