500 USD bounty for DOSBox Staging official Debian package

[Grounded0]

Modified: Wed 10 Jul 2024 21:58:13 UTC

Deploy DOSBox Staging into the official Debian package repository with a one-year commitment to being the package maintainer and collect your 500 USD. I will not raise this any further.

I can pay via SWIFT, the cryptos available in Coinbase, or PayPal.

Resolves a long-standing ticket opened in 2020:

• 664

Links

Debian ITP for DOSBox Staging Debian ITS for DOSBox Staging

Connected issues and PRs

• 418

• 664

• 3806

• 3809

Code of Conduct & Contributing Guidelines

• [X] Yes, I agree.

[okias]

I recommend specifying the outcome more precisely.

Do you want to get this into Debian or just external repository.

• Maintained by who? For how long? etc. etc.
• Should the person become the maintainer of the package in Debian? etc. etc.

[runlevel5]

Packaging would be easy part. The hard part is to get it accepted into Debian. Who's going to be the maintainer moving forward? I highly recommend you bring this up with the Debian community instead.

[Castor215]

This was mentioned on the mailing lists but I'm bringing it up here, too. What are the binary blobs in contrib/resources? I'm talking about files that end in .com, .sys, .exe and .cpx/cpi. These seem to be already-compiled files and would be a violation of the DFSG (specifically guideline 2 "Inclusion of source code"). As it is, dosbox-staging would need to go in the contrib or non-free sections. Can dosbox-staging function without these files?

[FeralChild64]

1. *.EXE, *.COM files - these are DOS commands (programs) from the FreeDOS projects, which are not (yet) internally implemented. DOSBox should work without these files - just the commands won’t be available, 99.9% of the time this shouldn’t matter.

2. KEYBOARD.SYS and friends - these are keyboard layout files from the FreeDOS project, see https://gitlab.com/FreeDOS/base/keyb_lay. AFAIK they were compiled using some tool from the source .KL files, but I don’t know the details. Expect trouble if you remove these files.

3. *.CPI / *.CPX files - these are screen font files from the FreeDOS project, see https://gitlab.com/FreeDOS/base/cpidos. CPI are just bitmap font files, there is no source code for them - AFAIK they were created using a specialized bitmap editor. CPX are UPX-compressed versions (these files contain a binary decompressor code). Due to some inconveniences, I got rid of the CPX files recently, see https://github.com/dosbox-staging/dosbox-staging/pull/3413. To create CPI file from the CPX one, just execute upx -d file.CPX command, under any OS. Expect trouble if you remove these files.

Regarding points 2. and 3. - I believe every single DOSBox fork has them in some form, even the original DOSBox - see:

• https://sourceforge.net/p/dosbox/code-0/HEAD/tree/dosbox/trunk/src/dos/dos_codepages.h
• https://sourceforge.net/p/dosbox/code-0/HEAD/tree/dosbox/trunk/src/dos/dos_keyboard_layout_data.h

The original DOSBox contains them (well, actually older versions) as embedded binary blobs, not as separate files.

[Castor215]

@FeralChild64 Fair enough. It was just that lintian throws up a warning about xcopy.exe and I was trying to predict what a Debian Developer might say when approached for sponsorship.

[Grounded0]

Raising this to 300 USD.

[Grounded0]

Raising this to 500 USD. I will not raise this any further.

[johnnovak]

Can we close this @Grounded0 now that we've done as much as we could from our side?

[Grounded0]

I'm still open to paying 500 USD to anyone who gets this done. I don't see a problem here.

[johnnovak]

Well, this is a Debian maintainer's job to get the package we publish into their official repos. And maintain it going forward. We deal with Staging dev here, so now that I think about it, this ticket should live in some Debian issue tracker IMO, not ours.

[Grounded0]

Debian-jobs mailing list is dead:

https://lists.debian.org/debian-jobs/

My evaluation is that I get more potential traction here than posting to a dead mailing list that few people read anyway. After all, we've got some people asking questions here about our package who are part of the Debian Team, so I call it progress since it's getting to the right eyeballs.

[johnnovak]

Sure, and I don't mind the ticket being in our tracker, don't get me wrong 😄 It's just that none of us from the core team will go and fight it out with the Debian people 😅 But hey, maybe someone will read this ticket and have the fighting spirit in them 🥊 😎

[Grounded0]

I'm retired so I got time and money to be Don Quixote of DOSBox Staging. 👊

[interloper98]

Can we transplant this ticket into Debian's repo with references back to our project-generated packages and Debian metadata?

Looks like their repos are here: https://github.com/orgs/Debian/repositories ... but which one? (there's quite a few!)

[Castor215]

For those unaware, this is the process for getting a package into Debian:

1. File an Intent to Package (ITP) on the appropriate Debian mailing list
2. After people have had a chance to respond to the ITP, you will need to modify the source to comply with Debian packaging policy
3. Make a Debian Salsa account (the official Git repository for staging packages) and upload the package source there
4. Upload the source to Debian Mentors
5. Find a sponsor for your package (this is the tricky part)
6. If a sponsor agrees to upload it for you, it will need to go through the Debian NEW queue, where the Debian legal team will make sure it's okay to distribute
7. Once your package clears NEW, it will be uploaded to unstable, where it will then propagate to testing and stable*
8. Congratulations! You are now a package maintainer. Any further development will be done by liaising between you and your sponsor

The details of each of these steps are quite involved and I won't go into them here. Here are some starting points:

• WNPP. You don't generally file an ITP in the mailing list directly. You use the reportbug utility to file a bug against the wnpp package and fill in the template.
• Debian Salsa. This is where you stage the source code for your package.
• Debian Mentors. This is where you'll upload your package once it's ready for sponsorship.
• Debian Policy Manual. Trying to digest this all in one go would be absurdly unfeasible, so just refer to this as needed.
• You may also want to look into tools for actually building the packages such as dh_make and sbuild, but this "brief" introduction of mine is already long enough.

I hope this helps any prospective DOSBox maintainers. Source: Almost became a maintainer, but didn't (Citra got nuked).

* Kind of, there's a caveat with brand new packages where an "empty" upload must be made before a package can migrate to testing. I forget the details but your sponsor will know more.

[johnnovak]

For those unaware, this is the process for getting a package into Debian:

Fucking hell; lodging my annual tax papers is a walk in the park compared to this process 🤣

Thanks for this @Castor215, by the way 👍🏻

[Grounded0]

[hosiet]

Jokes aside, speaking with my Debian Developer hat on:

The biggest problem is not about the bureaucracy; it's still the unclear file status as stated in https://github.com/dosbox-staging/dosbox-staging/issues/3677#issuecomment-2142105816 . I am slowly sorting out files in the dosbox-staging repo; embedded binary blobs are definitely not going to get in and alternatives are needed. This also applied to the Debian packaging of the original dosbox project.

I will try to spend some of my spare time on this issue but probably not that fast; I am a newbie in the DOS world. I will let you know when I have anything certain.

[johnnovak]

I am slowly sorting out files in the dosbox-staging repo; embedded binary blobs are definitely not going to get in and alternatives are needed.

Not quite sure why they are a problem at all. They're not copyrighted, they're not native executables, so they can be seen as data used by DOSBox. I'm sure lots of packages included in Debian have all sorts of data files which are neither text files nor native executables. PNG is data, WAV files are data, TTF files are surely not plain text files, etc. Then I'm sure you must have programs thar just used some random custom DAT file...

So maybe one way to hammer this through the bureaucrats is to point out similar precedents, the more and the older, the better (well, that's what I would do 😆).

[Grounded0]

I am slowly sorting out files in the dosbox-staging repo; embedded binary blobs are definitely not going to get in and alternatives are needed.

DOSBox-X Debian package also ships with binary blobs but they're hidden in the source code so I don't see a problem here (DEVICE.COM for example):

https://github.com/joncampbell123/dosbox-x/blob/master/src/builtin/device_com.cpp

[hosiet]

I am slowly sorting out files in the dosbox-staging repo; embedded binary blobs are definitely not going to get in and alternatives are needed.

DOSBox-X Debian package also ships with binary blobs but they're hidden in the source code so I don't see a problem here (DEVICE.COM for example):

https://github.com/joncampbell123/dosbox-x/blob/master/src/builtin/device_com.cpp

Thanks for pointing out. As you can see from https://sources.debian.org/src/dosbox-x/2024.07.01%2Bdfsg-1/debian/copyright/ , the embedded version has been explicitly handled and removed.

I appreciate the comments above; but executables, native or not, are usually stripped out or rebuilt from source. Even if I let it slip out of my hand, the final package review team will still reject it.

I see that dosbox-x as a reference has been properly treated in Debian; similarly dosbox-staging can be handled as well.

[johnnovak]

I appreciate the comments above; but executables, native or not, are usually stripped out or rebuilt from source.

Sure, the FreeDOS executables can be rebuilt for sure, but we're not interested in doing that as part of our build process. They are also non-essential, as pointed out.