Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On 12/10/23 12:08, Bas Wijnen wrote: On Sun, Dec 03, 2023 at 02:18:38AM -0600, Aaron Rainbolt wrote: [Catch 2] While it is definitely possible to port the openMSX tests to use catch2 v3, we will be departing from what upstream supports, and that seems like it could lead to way more work than necessary (for instance, what if the next major release of openMSX still uses catch2 v2 and uses it in a way that's incompatible with catch2 v3? Then we have to maintain that delta from upstream ourselves, possibly for an extended period of time). You are misunderstanding me. First of all, I was expecting the changes to be minor. So I was thinking we can write a patch and let upstream use it. They are very responsive, so I would expect them to include our patch immediately. However, if it is a lot of work, it might be better to just file a bug report upstream. I would expect them to respond to that as well, by doing it themselves. Although it might take some time. So because we are in a bit of a hurry with openMSX dropping from testing, I think the approach for now is to use the bundled catch2-v2, and either port it for them, or let them know it needs to be ported. One possible solution might be for Debian to ship multiple major versions of catch2. I don't know enough about catch2 to know if that is a good idea. It might be, but it's certainly out of the scope of this problem. Maybe this is something we can bring up to whoever maintains catch2 in Debian. Yes, that sounds like a good idea. They will probably have an intelligent opinion about it. I'm not so sure it's a Lintian bug since HTML files oftentimes *are* compiled from other source code. They are, but Lintian is now very forceful in saying that files like these are definitely compiled, which is just false. So if there is no better way to detect this, at the very least the certainty of the problem should be decreased (from error to warning, for example). It is quite common for hand-written text files (including html files) to contain long lines and it is not reasonable for all those files to either be required to be line-wrapped, nor for all those packages to contain overrides. I think that due to the urgency, I'll make a new package based on your work and upload it. We can figure out how to handle the remaining issues after that. Sounds good, and I'll see about a catch2 v3 port. (Part of the reason I was against that idea was because I actually tried to do it and it failed miserably. I didn't understand enough about how exactly the openMSX build system worked to do it "right" and the quick-and-dirty way of doing it was discouraged in the catch2 documentation.) I'll probably have to learn Perl before I can look into Lintian, but I've wanted to learn it before anyway, so may as well do so now. Thanks you for all your help with this! Thanks again, Bas -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On Sun, Dec 03, 2023 at 02:18:38AM -0600, Aaron Rainbolt wrote: > > [Catch 2] > While it is definitely possible to port the > openMSX tests to use catch2 v3, we will be departing from what > upstream supports, and that seems like it could lead to way more work > than necessary (for instance, what if the next major release of > openMSX still uses catch2 v2 and uses it in a way that's incompatible > with catch2 v3? Then we have to maintain that delta from upstream > ourselves, possibly for an extended period of time). You are misunderstanding me. First of all, I was expecting the changes to be minor. So I was thinking we can write a patch and let upstream use it. They are very responsive, so I would expect them to include our patch immediately. However, if it is a lot of work, it might be better to just file a bug report upstream. I would expect them to respond to that as well, by doing it themselves. Although it might take some time. So because we are in a bit of a hurry with openMSX dropping from testing, I think the approach for now is to use the bundled catch2-v2, and either port it for them, or let them know it needs to be ported. > One possible solution might be for Debian to ship multiple major > versions of catch2. I don't know enough about catch2 to know if that is a good idea. It might be, but it's certainly out of the scope of this problem. > Maybe this is something we can bring up to whoever maintains catch2 in > Debian. Yes, that sounds like a good idea. They will probably have an intelligent opinion about it. > I'm not so sure it's a Lintian bug since HTML files oftentimes *are* > compiled from other source code. They are, but Lintian is now very forceful in saying that files like these are definitely compiled, which is just false. So if there is no better way to detect this, at the very least the certainty of the problem should be decreased (from error to warning, for example). It is quite common for hand-written text files (including html files) to contain long lines and it is not reasonable for all those files to either be required to be line-wrapped, nor for all those packages to contain overrides. I think that due to the urgency, I'll make a new package based on your work and upload it. We can figure out how to handle the remaining issues after that. Thanks again, Bas signature.asc Description: PGP signature
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Alright, so apparently I can't read. I totally missed that you had mentioned there was already a bug report against Lintian about this problem. I think we probably should override the errors anyway for now since I am not an experienced Lintian or Perl developer and it will take me some time to try and get things fixed there, but I do agree with getting it fixed, and am happy to add this to my todo list and then help remove the overrides once the bug is fixed. As for not excluding the C-BIOS .xml files, I think it should be sufficient to simply change the file exclude pattern "Contrib/cbios" to "Contrib/cbios/*.rom" in debian/copyright. The change is minor enough I don't think it warrants a whole new debdiff attachment, though I'm happy to make one if it would make your life easier. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Is this bug something we're still actively working on? It's been a few days. If I missed something, feel free to let me know. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On Sun, Dec 3, 2023 at 2:04 AM Dr. Bas Wijnen wrote: > > Hi, > > This is starting to look great, thanks a lot of all the work. :-) However, I > still see a few issues with it: > > - the references to C-BIOS in the XML configuration files should not be > removed. When running, they are usually availably from the cbios package. > And if the user didn't install that, OpenMSX will detect this and handle it > properly. Good to know, will fix. > - The bundled catch2 should not be used. So the proper solution would be to > port the code to the newer version, and to keep the bundled version out of > it. Using the bundled version is acceptable as a temporary solution, but if > we do that, we should file a bug report that the packaged version should be > used again. Well... I'm not sure I agree there. The reason we switched away from the bundled catch2 was because it wouldn't build due to a change in glibc, and that has now been fixed in the vendored catch2. But more importantly, openMSX upstream is still depending on catch2 v2, whereas the version of catch2 in Debian is now catch2 v3, which has quite a bit of breaking changes. While it is definitely possible to port the openMSX tests to use catch2 v3, we will be departing from what upstream supports, and that seems like it could lead to way more work than necessary (for instance, what if the next major release of openMSX still uses catch2 v2 and uses it in a way that's incompatible with catch2 v3? Then we have to maintain that delta from upstream ourselves, possibly for an extended period of time). One possible solution might be for Debian to ship multiple major versions of catch2. Then we could depend on a catch2-v2 package or something like that and avoid having to use the vendored one. Then when upstream switches to catch2 v3, we just change the dependency to catch2 (which would then be catch2 v3). IMO the catch2 package should have the equivalent of sonames since it acts very much like a library in the sense that there are API breaking changes between major versions... but that's not what Debian does with it at the moment, so we're stuck finding alternate solutions. Maybe this is something we can bring up to whoever maintains catch2 in Debian. > - I prefer to not override the source-is-missing lintian messages. The reason > is that there are 3 kinds of messages, each with their own solution: > > 1. An actual bug in the code. The solution is to fix the code. > 2. A bug in Lintian. This code should not trigger the message. The solution > is to fix Lintian. > 3. A special (and rare) case. This code should not trigger the message, but > it is unreasonable to expect Lintian to understand that. The solution is > to add an override. > > IMO what we have here is 2, not 3. Adding an override implies that there is > nothing wrong with Lintian's behavior, which is incorrect; there is a bug > filed against Lintian for this and it should be fixed there. Unused > overrides > can unexpectedly hide actual problems, so when it gets fixed in Lintian, the > overrides need to be removed, but it is unlikely that anyone will think of > this, because there will not be a notification that the bug is fixed. > > Because of all this, I prefer to not silence Lintian. The messages do > indicate an actual bug, it's just not in this package. I'm not so sure it's a Lintian bug since HTML files oftentimes *are* compiled from other source code. Perhaps there's some sort of heuristic there though (I've not looked at the Lintian code and I don't know Perl, so I'm not sure). > Thanks, > Bas > > On Wed, Nov 29, 2023 at 06:50:59PM -0600, Aaron Rainbolt wrote: > > Alright, here's the latest openMSX package with all C-BIOS binaries patched > > out. Now that there's no new binaries, I can just send this as a debdiff > > attachment. Keep in mind all the binary files mentioned in the diff have to > > be deleted from the source tree. > > > > Thanks for collaborating with me so we could come up with the best solution > > possible for this! The debdiff is attached. > > > > -- > > Aaron Rainbolt > > Lubuntu Developer > > Matrix: @arraybolt3:matrix.org > > IRC: arraybolt3 on irc.libera.chat > > GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Hi, This is starting to look great, thanks a lot of all the work. :-) However, I still see a few issues with it: - the references to C-BIOS in the XML configuration files should not be removed. When running, they are usually availably from the cbios package. And if the user didn't install that, OpenMSX will detect this and handle it properly. - The bundled catch2 should not be used. So the proper solution would be to port the code to the newer version, and to keep the bundled version out of it. Using the bundled version is acceptable as a temporary solution, but if we do that, we should file a bug report that the packaged version should be used again. - I prefer to not override the source-is-missing lintian messages. The reason is that there are 3 kinds of messages, each with their own solution: 1. An actual bug in the code. The solution is to fix the code. 2. A bug in Lintian. This code should not trigger the message. The solution is to fix Lintian. 3. A special (and rare) case. This code should not trigger the message, but it is unreasonable to expect Lintian to understand that. The solution is to add an override. IMO what we have here is 2, not 3. Adding an override implies that there is nothing wrong with Lintian's behavior, which is incorrect; there is a bug filed against Lintian for this and it should be fixed there. Unused overrides can unexpectedly hide actual problems, so when it gets fixed in Lintian, the overrides need to be removed, but it is unlikely that anyone will think of this, because there will not be a notification that the bug is fixed. Because of all this, I prefer to not silence Lintian. The messages do indicate an actual bug, it's just not in this package. Thanks, Bas On Wed, Nov 29, 2023 at 06:50:59PM -0600, Aaron Rainbolt wrote: > Alright, here's the latest openMSX package with all C-BIOS binaries patched > out. Now that there's no new binaries, I can just send this as a debdiff > attachment. Keep in mind all the binary files mentioned in the diff have to > be deleted from the source tree. > > Thanks for collaborating with me so we could come up with the best solution > possible for this! The debdiff is attached. > > -- > Aaron Rainbolt > Lubuntu Developer > Matrix: @arraybolt3:matrix.org > IRC: arraybolt3 on irc.libera.chat > GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Alright, here's the latest openMSX package with all C-BIOS binaries patched out. Now that there's no new binaries, I can just send this as a debdiff attachment. Keep in mind all the binary files mentioned in the diff have to be deleted from the source tree. Thanks for collaborating with me so we could come up with the best solution possible for this! The debdiff is attached. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3 Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_basic.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_basic.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_disk.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_disk.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_logo_msx1.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_logo_msx1.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_logo_msx2.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_logo_msx2.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_logo_msx2+.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_logo_msx2+.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx1_br.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx1_br.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx1_eu.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx1_eu.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx1_jp.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx1_jp.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx1.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx1.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2_br.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2_br.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2+_br.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2+_br.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2_eu.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2_eu.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2+_eu.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2+_eu.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2_jp.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2_jp.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2+_jp.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2+_jp.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2.rom differ Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios_main_msx2+.rom and /tmp/0osCJlIw1e/openmsx-19.1+dfsg/Contrib/cbios/cbios_main_msx2+.rom differ diff -Nru openmsx-19.1/Contrib/cbios/C-BIOS_MSX1_BR.xml openmsx-19.1+dfsg/Contrib/cbios/C-BIOS_MSX1_BR.xml --- openmsx-19.1/Contrib/cbios/C-BIOS_MSX1_BR.xml 2023-08-29 13:20:30.0 -0500 +++ openmsx-19.1+dfsg/Contrib/cbios/C-BIOS_MSX1_BR.xml 1969-12-31 18:00:00.0 -0600 @@ -1,78 +0,0 @@ - - - - - -C-BIOS -MSX1 BR -2010 -An MSX1 machine using C-BIOS, with Brazillian settings, like 60Hz interrupt frequency. -MSX - - - - - - - - - - - 583cda86979ff4cd1eef75e79c7fda96e425317a - cbios_main_msx1_br.rom - - - - - - - 9fbbe400dbaf186aeba42e170d9424b032412c42 - cbios_logo_msx1.rom - - - - - - - - - - - - - - - - - -16000 - - false - int - true - false - false - - - - - - TMS99X8A - 16 - - - - YM2149 - - -21000 - - - - - - - - - - diff -Nru openmsx-19.1/Contrib/cbios/C-BIOS_MSX1_EU.xml openmsx-19.1+dfsg/Contrib/cbios/C-BIOS_MSX1_EU.xml --- openmsx-19.1/Contrib/cbios/C-BIOS_MSX1_EU.xml 2023-08-29 13:20:30.0 -0500 +++ openmsx-19.1+dfsg/Contrib/cbios/C-BIOS_MSX1_EU.xml 1969-12-31 18:00:00.0 -0600 @@ -1,78 +0,0 @@ - - - - - -C-BIOS -MSX1 EU -2003 -An MSX1 machine using C-BIOS, with an international keyboard layout and 50Hz interrupt frequency. -MSX - - - - - - - - - - - baf2e9c69252fd9b350b488d89c71887b9d05eec - cbios_main_msx1_eu.rom - - - - - - - 9fbbe400dbaf186aeba42e170d9424b032412c42 - cbios_logo_msx1
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On 11/29/23 14:40, Bas Wijnen wrote: On Wed, Nov 29, 2023 at 01:52:46PM -0600, Aaron Rainbolt wrote: It appears that the C-BIOS package in Debian only ships the most recent C-BIOS files. I think we can't just depend on it for this reason, since the older C-BIOS ROMs are needed to avoid save state breakage. See Contrib/cbios-old/README in the openMSX package. Well, in that case that problem exists right now as well, as the openmsx package does not include any version of cbios; it just Depends: on the cbios package. Oy. I see that you're right (just tested it). While I'm not sure if this is something that requires fixing (I need to think more about that), the proper way to fix it would be inside the cbios package, I think. Those copies are only included in openmsx for convenience; the cbios package (including old versions of it) is the source for those binaries. If they need to be installed, it should be done from the package that has their source. Copying the source to also be available in the openmsx package (where the binaries aren't even used) doesn't make sense to me. Agreed. If the old save C-BIOS ROMs aren't being installed in the first place, there's no point in them (or their source) being there. So as far as the openmsx package is concerned, I think we should just remove the binaries from the source package. Then the next step is to solve this problem (or decide that it does not need solving) in the cbios package. I like it. I'll redo the packaging again to repack out the Contrib/cbios-old and Contrib/cbios directories (and get rid of the needless source code I added to debian/missing-sources), then upload the packaging to GitHub one more time for review. Thanks for your help! Thanks, Bas -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On Wed, Nov 29, 2023 at 01:52:46PM -0600, Aaron Rainbolt wrote: > It appears that the C-BIOS package in Debian only ships the most recent > C-BIOS files. I think we can't just depend on it for this reason, since the > older C-BIOS ROMs are needed to avoid save state breakage. See > Contrib/cbios-old/README in the openMSX package. Well, in that case that problem exists right now as well, as the openmsx package does not include any version of cbios; it just Depends: on the cbios package. While I'm not sure if this is something that requires fixing (I need to think more about that), the proper way to fix it would be inside the cbios package, I think. Those copies are only included in openmsx for convenience; the cbios package (including old versions of it) is the source for those binaries. If they need to be installed, it should be done from the package that has their source. Copying the source to also be available in the openmsx package (where the binaries aren't even used) doesn't make sense to me. So as far as the openmsx package is concerned, I think we should just remove the binaries from the source package. Then the next step is to solve this problem (or decide that it does not need solving) in the cbios package. Thanks, Bas
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
It appears that the C-BIOS package in Debian only ships the most recent C-BIOS files. I think we can't just depend on it for this reason, since the older C-BIOS ROMs are needed to avoid save state breakage. See Contrib/cbios-old/README in the openMSX package. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub:https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On Wed, Nov 29, 2023 at 5:17 AM Dr. Bas Wijnen wrote: > > Hi, > > Thanks a lot for not just finding those issues, but also fixing them! That is > much appreciated. > > As for the license, Manuel (who is upstream) pointed out that the entire > source > code is (and always has been) GPL-2 only. The only issue with that is the > packaging, which is GPL-3+. But that was my doing; the original was GPL-2 (I > thought GPL-2+, but perhaps that isn't true and I wasn't even allowed to make > it GPL-3+). > > In any case, I'll happily change the license to my work into GPL-2+, so that > it > is compatible with the rest of OpenMSX. Obviously the link should also point > to > GPL-2. I don't think changing the packaging license now is necessary, and it may require a significant amount of extra work - other people have worked on the packaging since you first set its license, which means that changing that license would require a relicensing effort (contact all the previous packagers who made significant changes and ask for permission). Easier to just leave the packaging as GPL-3+, it won't do any harm and makes things simpler. > As for cbios: I was not aware that it was included in the source tree. Fact is > that it doesn't need to be; it is useful for running the system, but it is not > even required for that and it is also not required for compiling it. If it > were, I'd build-depend on the Debian package. > > So while I appreciate your efforts to track down and package the sources, I > think the better approach is to remove the binaries from Debian's source > package, just like the Windows dll. > > Do you agree that that would be a more elegant solution? Does the C-BIOS package contain multiple previous versions of C-BiOS, and put them where openMSX expects? openMSX has many older versions of C-BIOS included for loading older save states. It's possible this would be a workable solution, I'd just need to look at it a bit closer. We don't want to break people's old save states. If the C-BIOS package only ships the latest version of C-BIOS, then this solution will not work. If it ships all needed versions and has them in the right spots, then this would probably work.. > Thanks, > Bas > > On Mon, Nov 27, 2023 at 03:14:37PM -0600, Aaron Rainbolt wrote: > > On 11/27/23 15:02, Manuel Bilderbeek wrote: > > > On 27-11-2023 02:11, Aaron Rainbolt wrote: > > > > Alright, I have fully rebuilt the copyright file. I also ended up > > > > adding the source code for several releases of C-BIOS into the > > > > packaging. As this code is in the form of zipped files for the sake > > > > of size, it's not exactly practical to provide the new source > > > > package changes as a debdiff since debdiffs don't communicate binary > > > > file changes very well. So here's a .tar.gz of the new source > > > > package tree, detach-signed with my GPG key. > > > > https://github.com/ArrayBolt3/openmsx-packaging (I put it on GitHub > > > > since Gmail didn't want to let me send the package as a file > > > > attachment.) > > > But why would you include the cbios sources in the openMSX package, as > > > there is already a cbios package, which provides the binaries and has > > > the sources as source package? > > > > Because openMSX vendors pre-built C-BIOS binaries, so therefore the source > > package must include the sources for it to be DFSG compliant. See > > https://www.debian.org/social_contract DFSG section 2. There is no build > > dependency on C-BIOS since C-BIOS binaries are provided in openMSX rather > > than sources. There is no binary dependency on C-BIOS either for the same > > reason. A user who downloads the source for the Debian openMSX package will > > not get all of the source, since there are multiple C-BIOS binaries with no > > source code. openMSX does point to the C-BIOS sources on SourceForge, but > > SourceForge isn't guaranteed to always exist. I do not think it is > > sufficient for some of the sources the user should have been given to just > > be "somewhere in the archive", leaving it up to the user to find them. > > Including C-BIOS source in the source package of openMSX ensures that even > > if all else fails (no upstream source, no way of pulling the C-BIOS source > > package for some reason) a user will always get the sources for the software > > they downloaded the source package of. > > > > > > > > > > (You probably will notice some superfluous-file-pattern warnings > > > > from Lintian when you build this - I do not understand why these are > > > > occurring as the file patterns it's griping about are *not* > > > > superfluous and don't appear to be overridden by any later > > > > statements in the copyright file. I suspect a Lintian bug here.) > > > > > > > > > > -- > > > Kind regards, > > > Manuel > > > > -- > > Aaron Rainbolt > > Lubuntu Developer > > Matrix: @arraybolt3:matrix.org > > IRC: arraybolt3 on irc.libera.chat > > GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Hi, Thanks a lot for not just finding those issues, but also fixing them! That is much appreciated. As for the license, Manuel (who is upstream) pointed out that the entire source code is (and always has been) GPL-2 only. The only issue with that is the packaging, which is GPL-3+. But that was my doing; the original was GPL-2 (I thought GPL-2+, but perhaps that isn't true and I wasn't even allowed to make it GPL-3+). In any case, I'll happily change the license to my work into GPL-2+, so that it is compatible with the rest of OpenMSX. Obviously the link should also point to GPL-2. As for cbios: I was not aware that it was included in the source tree. Fact is that it doesn't need to be; it is useful for running the system, but it is not even required for that and it is also not required for compiling it. If it were, I'd build-depend on the Debian package. So while I appreciate your efforts to track down and package the sources, I think the better approach is to remove the binaries from Debian's source package, just like the Windows dll. Do you agree that that would be a more elegant solution? Thanks, Bas On Mon, Nov 27, 2023 at 03:14:37PM -0600, Aaron Rainbolt wrote: > On 11/27/23 15:02, Manuel Bilderbeek wrote: > > On 27-11-2023 02:11, Aaron Rainbolt wrote: > > > Alright, I have fully rebuilt the copyright file. I also ended up > > > adding the source code for several releases of C-BIOS into the > > > packaging. As this code is in the form of zipped files for the sake > > > of size, it's not exactly practical to provide the new source > > > package changes as a debdiff since debdiffs don't communicate binary > > > file changes very well. So here's a .tar.gz of the new source > > > package tree, detach-signed with my GPG key. > > > https://github.com/ArrayBolt3/openmsx-packaging (I put it on GitHub > > > since Gmail didn't want to let me send the package as a file > > > attachment.) > > But why would you include the cbios sources in the openMSX package, as > > there is already a cbios package, which provides the binaries and has > > the sources as source package? > > Because openMSX vendors pre-built C-BIOS binaries, so therefore the source > package must include the sources for it to be DFSG compliant. See > https://www.debian.org/social_contract DFSG section 2. There is no build > dependency on C-BIOS since C-BIOS binaries are provided in openMSX rather > than sources. There is no binary dependency on C-BIOS either for the same > reason. A user who downloads the source for the Debian openMSX package will > not get all of the source, since there are multiple C-BIOS binaries with no > source code. openMSX does point to the C-BIOS sources on SourceForge, but > SourceForge isn't guaranteed to always exist. I do not think it is > sufficient for some of the sources the user should have been given to just > be "somewhere in the archive", leaving it up to the user to find them. > Including C-BIOS source in the source package of openMSX ensures that even > if all else fails (no upstream source, no way of pulling the C-BIOS source > package for some reason) a user will always get the sources for the software > they downloaded the source package of. > > > > > > > (You probably will notice some superfluous-file-pattern warnings > > > from Lintian when you build this - I do not understand why these are > > > occurring as the file patterns it's griping about are *not* > > > superfluous and don't appear to be overridden by any later > > > statements in the copyright file. I suspect a Lintian bug here.) > > > > > > > -- > > Kind regards, > > Manuel > > -- > Aaron Rainbolt > Lubuntu Developer > Matrix: @arraybolt3:matrix.org > IRC: arraybolt3 on irc.libera.chat > GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
I had a Debian Developer review my packaging work. I got the package version string wrong and was slightly vague about the debhelper version update in the changelog. Both of those things are now fixed and I have the fixed files pushed to the same GitHub repo as last time, https://github.com/ArrayBolt3/openmsx-packaging. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On 11/27/23 15:02, Manuel Bilderbeek wrote: On 27-11-2023 02:11, Aaron Rainbolt wrote: Alright, I have fully rebuilt the copyright file. I also ended up adding the source code for several releases of C-BIOS into the packaging. As this code is in the form of zipped files for the sake of size, it's not exactly practical to provide the new source package changes as a debdiff since debdiffs don't communicate binary file changes very well. So here's a .tar.gz of the new source package tree, detach-signed with my GPG key. https://github.com/ArrayBolt3/openmsx-packaging (I put it on GitHub since Gmail didn't want to let me send the package as a file attachment.) But why would you include the cbios sources in the openMSX package, as there is already a cbios package, which provides the binaries and has the sources as source package? Because openMSX vendors pre-built C-BIOS binaries, so therefore the source package must include the sources for it to be DFSG compliant. See https://www.debian.org/social_contract DFSG section 2. There is no build dependency on C-BIOS since C-BIOS binaries are provided in openMSX rather than sources. There is no binary dependency on C-BIOS either for the same reason. A user who downloads the source for the Debian openMSX package will not get all of the source, since there are multiple C-BIOS binaries with no source code. openMSX does point to the C-BIOS sources on SourceForge, but SourceForge isn't guaranteed to always exist. I do not think it is sufficient for some of the sources the user should have been given to just be "somewhere in the archive", leaving it up to the user to find them. Including C-BIOS source in the source package of openMSX ensures that even if all else fails (no upstream source, no way of pulling the C-BIOS source package for some reason) a user will always get the sources for the software they downloaded the source package of. (You probably will notice some superfluous-file-pattern warnings from Lintian when you build this - I do not understand why these are occurring as the file patterns it's griping about are *not* superfluous and don't appear to be overridden by any later statements in the copyright file. I suspect a Lintian bug here.) -- Kind regards, Manuel -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On 27-11-2023 02:11, Aaron Rainbolt wrote: Alright, I have fully rebuilt the copyright file. I also ended up adding the source code for several releases of C-BIOS into the packaging. As this code is in the form of zipped files for the sake of size, it's not exactly practical to provide the new source package changes as a debdiff since debdiffs don't communicate binary file changes very well. So here's a .tar.gz of the new source package tree, detach-signed with my GPG key. https://github.com/ArrayBolt3/openmsx-packaging (I put it on GitHub since Gmail didn't want to let me send the package as a file attachment.) But why would you include the cbios sources in the openMSX package, as there is already a cbios package, which provides the binaries and has the sources as source package? (You probably will notice some superfluous-file-pattern warnings from Lintian when you build this - I do not understand why these are occurring as the file patterns it's griping about are *not* superfluous and don't appear to be overridden by any later statements in the copyright file. I suspect a Lintian bug here.) -- Kind regards, Manuel
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Alright, I have fully rebuilt the copyright file. I also ended up adding the source code for several releases of C-BIOS into the packaging. As this code is in the form of zipped files for the sake of size, it's not exactly practical to provide the new source package changes as a debdiff since debdiffs don't communicate binary file changes very well. So here's a .tar.gz of the new source package tree, detach-signed with my GPG key. https://github.com/ArrayBolt3/openmsx-packaging (I put it on GitHub since Gmail didn't want to let me send the package as a file attachment.) (You probably will notice some superfluous-file-pattern warnings from Lintian when you build this - I do not understand why these are occurring as the file patterns it's griping about are *not* superfluous and don't appear to be overridden by any later statements in the copyright file. I suspect a Lintian bug here.) -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: Fwd: Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Failed to reply to the right address, so forwarding. -- Forwarded message - From: Aaron Rainbolt Date: Sun, Nov 26, 2023 at 1:30 PM Subject: Re: Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues) To: Manuel Bilderbeek Thanks! I was able to find the code for all ROMs and get it included, so C-BIOS is now no longer an issue. I still have quite a bit more code to look through so I'll probably take a while longer to get this done, but it's coming along nicely. On Sun, Nov 26, 2023 at 1:22 PM Manuel Bilderbeek wrote: > > On 26-11-2023 18:39, Aaron Rainbolt wrote: > > Further investigation trying to rebuild the copyright file has revealed more > binaries without source code (the C-BIOS ROMs for instance). So I'll have to > find the sources for those also. Thanks for your patience. > > The C-BIOS ROMs have their source code, see e.g. the cbios package in Debian, > which contains all info to the upstream sources. (As they're packaged > separately, they are not part of the openMSX (source) packages in Debian.) > > -- > Kind regards, > > Manuel Bilderbeek
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On 26-11-2023 18:39, Aaron Rainbolt wrote: Further investigation trying to rebuild the copyright file has revealed more binaries without source code (the C-BIOS ROMs for instance). So I'll have to find the sources for those also. Thanks for your patience. The C-BIOS ROMs have their source code, see e.g. the cbios package in Debian, which contains all info to the upstream sources. (As they're packaged separately, they are not part of the openMSX (source) packages in Debian.) -- Kind regards, Manuel Bilderbeek
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Further investigation trying to rebuild the copyright file has revealed more binaries without source code (the C-BIOS ROMs for instance). So I'll have to find the sources for those also. Thanks for your patience. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
My reasoning here is that the openMSX code specifies "Some source files contain a license notice; all other source files are licensed under the GNU Public License (GPL), of which you can find a copy in the file 'GPL.txt'." That file contains a GPL-2 license, so the repository-wide license is GPL-2. To me specifying it as such seemed reasonable, and Lintian was complaining that the package pointed to the /usr/share/common-licenses/GPL symlink, which insinuates that all of the source code is licensed as GPL version 3 and will be relicensed to a newer version of the GPL when that license is published and Debian introduces it. This is at least *more* accurate than what was there before. I do not disagree that this is only partially accurate as it places a blanket licensing statement over the entirety of the source code that individual files may override. Ideally the copyright file should be rebuilt from scratch by auditing the entirety of the openMSX source code licenses. I can do that if it would be helpful. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Hi, The license of openMSX has always been GPL 2 only. Is there a problem somewhere? Op zo 26 nov. 2023 09:57 schreef Dr. Bas Wijnen : > Hi, > > First of all, thank you for the report and patch. I'll look in more detail > shortly. > > However, after quickly looking over it, I have one question: you change the > license from "GPL (any version)" to "GPL (version 2)". Why did you do that? > > The upstream license information is admittedly not very clear, but I > certainly > don't think it says this. Anyway, upstream is also monitoring the Debian > BTS, > so perhaps they can let us know what license version they intend to use. > Manuel? > > There is code included that says "version 3 or later", so version 2 is not > allowed for that. I had not checked license information for a while, but > after > checking now, I see one file which specifically says "version 2" as well. > That > may be a problem, but I think it will be fine; I'll check it. > > Anyway, relicensing the entire tree as "GPL2 only" is a pretty big change > that > doesn't seem like a good idea to me (and it's possibly incorrect/not > allowed). > > What was your reasoning behind this? > > Thanks, > Bas > > On Sun, Nov 26, 2023 at 12:35:15AM -0600, Aaron Rainbolt wrote: > > Uh... ok so apparently either Gmail or the Debian BTS ate my patch, so > > here's a second attempt, this time as a file attachment. > > > > Also, it appears that the openMSX maintainer's debian.org email address > must > > be pointing to an Apple support address since I've now gotten two "Thank > you > > for contacting us" emails from apple.com. > > > > -- > > Aaron Rainbolt > > Lubuntu Developer > > Matrix: @arraybolt3:matrix.org > > IRC: arraybolt3 on irc.libera.chat > > GitHub: https://github.com/ArrayBolt3 > > > Binary files /tmp/phkMJNskDj/openmsx-19.1/Contrib/codec/Win32/zmbv.dll > and /tmp/Cd74GNmEnl/openmsx-19.1+dfsg/Contrib/codec/Win32/zmbv.dll differ > > diff -Nru openmsx-19.1/debian/changelog > openmsx-19.1+dfsg/debian/changelog > > --- openmsx-19.1/debian/changelog 2023-09-01 01:39:39.0 -0500 > > +++ openmsx-19.1+dfsg/debian/changelog2023-11-24 > 13:47:59.0 -0600 > > @@ -1,3 +1,25 @@ > > +openmsx (19.1+dfsg-2) unstable; urgency=medium > > + > > + * Override spurious source-is-missing Lintian errors. > > + * Don't build-depend on dpkg-dev, it's guaranteed to be installed in a > > +Debian build environment. > > + * Repack the upstream tarball to remove a prebuilt Windows binary. > > +(Closes: #1056780) > > + * Set 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' in debian/rules. > > + * Remove debian/source/include-binaries, every file listed in it > doesn't > > +exist. > > + * Make debian/copyright point to more specific license files in > > +/usr/share/common-licenses. > > + * Set 'Rules-Requires-Root: no' in debian/control. > > + * Use debhelper 13 rather than debhelper 10. > > + * Override spurious > package-contains-documentation-outside-usr-share-doc > > +Lintian gripes. > > + * Created debian/upstream/metadata file. > > + * Switch back to using vendored catch2, the catch2 Debian package now > ships > > +catch2 v3 whereas openMSX uses catch2 v2. > > + > > + -- Aaron Rainbolt Fri, 24 Nov 2023 13:47:59 > -0600 > > + > > openmsx (19.1-1) unstable; urgency=medium > > > >* New upstream release. > > diff -Nru openmsx-19.1/debian/compat openmsx-19.1+dfsg/debian/compat > > --- openmsx-19.1/debian/compat2017-08-06 07:57:22.0 -0500 > > +++ openmsx-19.1+dfsg/debian/compat 1969-12-31 18:00:00.0 -0600 > > @@ -1 +0,0 @@ > > -10 > > diff -Nru openmsx-19.1/debian/control openmsx-19.1+dfsg/debian/control > > --- openmsx-19.1/debian/control 2023-08-03 02:11:39.0 -0500 > > +++ openmsx-19.1+dfsg/debian/control 2023-11-24 13:47:59.0 -0600 > > @@ -2,9 +2,10 @@ > > Section: otherosfs > > Priority: optional > > Maintainer: Bas Wijnen > > -Build-Depends: debhelper (>= 10), dpkg-dev, docbook-to-man, > libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, > python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, > libfreetype-dev, catch2 > > +Build-Depends: debhelper-compat (= 13), docbook-to-man, libsdl2-dev, > libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, > libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev > > Standards-Version: 4.6.2 > > Homepage: https://openmsx.org > > +Rules-Requires-Root: no > > > > Package: openmsx > > Architecture: any > > diff -Nru openmsx-19.1/debian/copyright > openmsx-19.1+dfsg/debian/copyright > > --- openmsx-19.1/debian/copyright 2021-06-17 06:21:11.0 -0500 > > +++ openmsx-19.1+dfsg/debian/copyright2023-11-24 > 13:47:59.0 -0600 > > @@ -2,29 +2,31 @@ > > Upstream-Name: openMSX > > Upstream-Contact: https://web.libera.chat/#openMSX > > Source: https://github.com/openMSX/openMSX/ > > +Files-Excluded: Contrib/codec/Win32/zmbv.dll > > > > File
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Hi, First of all, thank you for the report and patch. I'll look in more detail shortly. However, after quickly looking over it, I have one question: you change the license from "GPL (any version)" to "GPL (version 2)". Why did you do that? The upstream license information is admittedly not very clear, but I certainly don't think it says this. Anyway, upstream is also monitoring the Debian BTS, so perhaps they can let us know what license version they intend to use. Manuel? There is code included that says "version 3 or later", so version 2 is not allowed for that. I had not checked license information for a while, but after checking now, I see one file which specifically says "version 2" as well. That may be a problem, but I think it will be fine; I'll check it. Anyway, relicensing the entire tree as "GPL2 only" is a pretty big change that doesn't seem like a good idea to me (and it's possibly incorrect/not allowed). What was your reasoning behind this? Thanks, Bas On Sun, Nov 26, 2023 at 12:35:15AM -0600, Aaron Rainbolt wrote: > Uh... ok so apparently either Gmail or the Debian BTS ate my patch, so > here's a second attempt, this time as a file attachment. > > Also, it appears that the openMSX maintainer's debian.org email address must > be pointing to an Apple support address since I've now gotten two "Thank you > for contacting us" emails from apple.com. > > -- > Aaron Rainbolt > Lubuntu Developer > Matrix: @arraybolt3:matrix.org > IRC: arraybolt3 on irc.libera.chat > GitHub: https://github.com/ArrayBolt3 > Binary files /tmp/phkMJNskDj/openmsx-19.1/Contrib/codec/Win32/zmbv.dll and > /tmp/Cd74GNmEnl/openmsx-19.1+dfsg/Contrib/codec/Win32/zmbv.dll differ > diff -Nru openmsx-19.1/debian/changelog openmsx-19.1+dfsg/debian/changelog > --- openmsx-19.1/debian/changelog 2023-09-01 01:39:39.0 -0500 > +++ openmsx-19.1+dfsg/debian/changelog2023-11-24 13:47:59.0 > -0600 > @@ -1,3 +1,25 @@ > +openmsx (19.1+dfsg-2) unstable; urgency=medium > + > + * Override spurious source-is-missing Lintian errors. > + * Don't build-depend on dpkg-dev, it's guaranteed to be installed in a > +Debian build environment. > + * Repack the upstream tarball to remove a prebuilt Windows binary. > +(Closes: #1056780) > + * Set 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' in debian/rules. > + * Remove debian/source/include-binaries, every file listed in it doesn't > +exist. > + * Make debian/copyright point to more specific license files in > +/usr/share/common-licenses. > + * Set 'Rules-Requires-Root: no' in debian/control. > + * Use debhelper 13 rather than debhelper 10. > + * Override spurious package-contains-documentation-outside-usr-share-doc > +Lintian gripes. > + * Created debian/upstream/metadata file. > + * Switch back to using vendored catch2, the catch2 Debian package now ships > +catch2 v3 whereas openMSX uses catch2 v2. > + > + -- Aaron Rainbolt Fri, 24 Nov 2023 13:47:59 -0600 > + > openmsx (19.1-1) unstable; urgency=medium > >* New upstream release. > diff -Nru openmsx-19.1/debian/compat openmsx-19.1+dfsg/debian/compat > --- openmsx-19.1/debian/compat2017-08-06 07:57:22.0 -0500 > +++ openmsx-19.1+dfsg/debian/compat 1969-12-31 18:00:00.0 -0600 > @@ -1 +0,0 @@ > -10 > diff -Nru openmsx-19.1/debian/control openmsx-19.1+dfsg/debian/control > --- openmsx-19.1/debian/control 2023-08-03 02:11:39.0 -0500 > +++ openmsx-19.1+dfsg/debian/control 2023-11-24 13:47:59.0 -0600 > @@ -2,9 +2,10 @@ > Section: otherosfs > Priority: optional > Maintainer: Bas Wijnen > -Build-Depends: debhelper (>= 10), dpkg-dev, docbook-to-man, libsdl2-dev, > libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, > libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev, catch2 > +Build-Depends: debhelper-compat (= 13), docbook-to-man, libsdl2-dev, > libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, > libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev > Standards-Version: 4.6.2 > Homepage: https://openmsx.org > +Rules-Requires-Root: no > > Package: openmsx > Architecture: any > diff -Nru openmsx-19.1/debian/copyright openmsx-19.1+dfsg/debian/copyright > --- openmsx-19.1/debian/copyright 2021-06-17 06:21:11.0 -0500 > +++ openmsx-19.1+dfsg/debian/copyright2023-11-24 13:47:59.0 > -0600 > @@ -2,29 +2,31 @@ > Upstream-Name: openMSX > Upstream-Contact: https://web.libera.chat/#openMSX > Source: https://github.com/openMSX/openMSX/ > +Files-Excluded: Contrib/codec/Win32/zmbv.dll > > Files: * > Copyright: copyright © 2001-2021 by the openMSX developers. > -License: GPL > +License: GPL-2 > This program is free software: you can redistribute it and/or modify > it under the terms of any version of the GNU General Public License as > published by the Free Software Foundation. > . > - The latest version of the GPL can be f
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Uh... ok so apparently either Gmail or the Debian BTS ate my patch, so here's a second attempt, this time as a file attachment. Also, it appears that the openMSX maintainer's debian.org email address must be pointing to an Apple support address since I've now gotten two "Thank you for contacting us" emails from apple.com. -- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: https://github.com/ArrayBolt3 Binary files /tmp/phkMJNskDj/openmsx-19.1/Contrib/codec/Win32/zmbv.dll and /tmp/Cd74GNmEnl/openmsx-19.1+dfsg/Contrib/codec/Win32/zmbv.dll differ diff -Nru openmsx-19.1/debian/changelog openmsx-19.1+dfsg/debian/changelog --- openmsx-19.1/debian/changelog 2023-09-01 01:39:39.0 -0500 +++ openmsx-19.1+dfsg/debian/changelog 2023-11-24 13:47:59.0 -0600 @@ -1,3 +1,25 @@ +openmsx (19.1+dfsg-2) unstable; urgency=medium + + * Override spurious source-is-missing Lintian errors. + * Don't build-depend on dpkg-dev, it's guaranteed to be installed in a +Debian build environment. + * Repack the upstream tarball to remove a prebuilt Windows binary. +(Closes: #1056780) + * Set 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' in debian/rules. + * Remove debian/source/include-binaries, every file listed in it doesn't +exist. + * Make debian/copyright point to more specific license files in +/usr/share/common-licenses. + * Set 'Rules-Requires-Root: no' in debian/control. + * Use debhelper 13 rather than debhelper 10. + * Override spurious package-contains-documentation-outside-usr-share-doc +Lintian gripes. + * Created debian/upstream/metadata file. + * Switch back to using vendored catch2, the catch2 Debian package now ships +catch2 v3 whereas openMSX uses catch2 v2. + + -- Aaron Rainbolt Fri, 24 Nov 2023 13:47:59 -0600 + openmsx (19.1-1) unstable; urgency=medium * New upstream release. diff -Nru openmsx-19.1/debian/compat openmsx-19.1+dfsg/debian/compat --- openmsx-19.1/debian/compat 2017-08-06 07:57:22.0 -0500 +++ openmsx-19.1+dfsg/debian/compat 1969-12-31 18:00:00.0 -0600 @@ -1 +0,0 @@ -10 diff -Nru openmsx-19.1/debian/control openmsx-19.1+dfsg/debian/control --- openmsx-19.1/debian/control 2023-08-03 02:11:39.0 -0500 +++ openmsx-19.1+dfsg/debian/control 2023-11-24 13:47:59.0 -0600 @@ -2,9 +2,10 @@ Section: otherosfs Priority: optional Maintainer: Bas Wijnen -Build-Depends: debhelper (>= 10), dpkg-dev, docbook-to-man, libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev, catch2 +Build-Depends: debhelper-compat (= 13), docbook-to-man, libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev Standards-Version: 4.6.2 Homepage: https://openmsx.org +Rules-Requires-Root: no Package: openmsx Architecture: any diff -Nru openmsx-19.1/debian/copyright openmsx-19.1+dfsg/debian/copyright --- openmsx-19.1/debian/copyright 2021-06-17 06:21:11.0 -0500 +++ openmsx-19.1+dfsg/debian/copyright 2023-11-24 13:47:59.0 -0600 @@ -2,29 +2,31 @@ Upstream-Name: openMSX Upstream-Contact: https://web.libera.chat/#openMSX Source: https://github.com/openMSX/openMSX/ +Files-Excluded: Contrib/codec/Win32/zmbv.dll Files: * Copyright: copyright © 2001-2021 by the openMSX developers. -License: GPL +License: GPL-2 This program is free software: you can redistribute it and/or modify it under the terms of any version of the GNU General Public License as published by the Free Software Foundation. . - The latest version of the GPL can be found in - /usr/share/common-licenses/GPL. + Version 2 of the GPL can be found in + /usr/share/common-licenses/GPL-2. Files: debian/* Copyright: © 2004-2009, Joost Yervante Damad Copyright 2012-2021, Bas Wijnen + Copyright 2023, Aaron Rainbolt License: GPL-3+ This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. . - The latest version of the GPL can be found in - /usr/share/common-licenses/GPL. + On Debian systems, the GPL version 3 can be found in + /usr/share/common-licenses/GPL-3. Files: src/serial/Midi_w32.* diff -Nru openmsx-19.1/debian/openmsx-data.lintian-overrides openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides --- openmsx-19.1/debian/openmsx-data.lintian-overrides 1969-12-31 18:00:00.0 -0600 +++ openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides 2023-11-24 13:47:59.0 -0600 @@ -0,0 +1,22 @@ +# All of these are either false positives or they describe what should go in the directories they are in. +openmsx-data: package-contains-documentation-outside-usr-share-doc [usr/share/openmsx/extensions/README] +openm
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Here's a debdiff between the current version of the openMSX package and a proposed new version that fixes this bug. **Note**: It is necessary to also delete the Contrib/codec/Win32/zmbv.dll file in the source package tree (debdiffs don't seem to communicate deleted binary files very well). -- Binary files /tmp/phkMJNskDj/openmsx-19.1/Contrib/codec/Win32/zmbv.dll and /tmp/Cd74GNmEnl/openmsx-19.1+dfsg/Contrib/codec/Win32/zmbv.dll differ diff -Nru openmsx-19.1/debian/changelog openmsx-19.1+dfsg/debian/changelog --- openmsx-19.1/debian/changelog 2023-09-01 01:39:39.0 -0500 +++ openmsx-19.1+dfsg/debian/changelog 2023-11-24 13:47:59.0 -0600 @@ -1,3 +1,25 @@ +openmsx (19.1+dfsg-2) unstable; urgency=medium + + * Override spurious source-is-missing Lintian errors. + * Don't build-depend on dpkg-dev, it's guaranteed to be installed in a + Debian build environment. + * Repack the upstream tarball to remove a prebuilt Windows binary. + (Closes: #1056780) + * Set 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' in debian/rules. + * Remove debian/source/include-binaries, every file listed in it doesn't + exist. + * Make debian/copyright point to more specific license files in + /usr/share/common-licenses. + * Set 'Rules-Requires-Root: no' in debian/control. + * Use debhelper 13 rather than debhelper 10. + * Override spurious package-contains-documentation-outside-usr-share-doc + Lintian gripes. + * Created debian/upstream/metadata file. + * Switch back to using vendored catch2, the catch2 Debian package now ships + catch2 v3 whereas openMSX uses catch2 v2. + + -- Aaron Rainbolt Fri, 24 Nov 2023 13:47:59 -0600 + openmsx (19.1-1) unstable; urgency=medium * New upstream release. diff -Nru openmsx-19.1/debian/compat openmsx-19.1+dfsg/debian/compat --- openmsx-19.1/debian/compat 2017-08-06 07:57:22.0 -0500 +++ openmsx-19.1+dfsg/debian/compat 1969-12-31 18:00:00.0 -0600 @@ -1 +0,0 @@ -10 diff -Nru openmsx-19.1/debian/control openmsx-19.1+dfsg/debian/control --- openmsx-19.1/debian/control 2023-08-03 02:11:39.0 -0500 +++ openmsx-19.1+dfsg/debian/control 2023-11-24 13:47:59.0 -0600 @@ -2,9 +2,10 @@ Section: otherosfs Priority: optional Maintainer: Bas Wijnen -Build-Depends: debhelper (>= 10), dpkg-dev, docbook-to-man, libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev, catch2 +Build-Depends: debhelper-compat (= 13), docbook-to-man, libsdl2-dev, libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev Standards-Version: 4.6.2 Homepage: https://openmsx.org +Rules-Requires-Root: no Package: openmsx Architecture: any diff -Nru openmsx-19.1/debian/copyright openmsx-19.1+dfsg/debian/copyright --- openmsx-19.1/debian/copyright 2021-06-17 06:21:11.0 -0500 +++ openmsx-19.1+dfsg/debian/copyright 2023-11-24 13:47:59.0 -0600 @@ -2,29 +2,31 @@ Upstream-Name: openMSX Upstream-Contact: https://web.libera.chat/#openMSX Source: https://github.com/openMSX/openMSX/ +Files-Excluded: Contrib/codec/Win32/zmbv.dll Files: * Copyright: copyright © 2001-2021 by the openMSX developers. -License: GPL +License: GPL-2 This program is free software: you can redistribute it and/or modify it under the terms of any version of the GNU General Public License as published by the Free Software Foundation. . - The latest version of the GPL can be found in - /usr/share/common-licenses/GPL. + Version 2 of the GPL can be found in + /usr/share/common-licenses/GPL-2. Files: debian/* Copyright: © 2004-2009, Joost Yervante Damad Copyright 2012-2021, Bas Wijnen + Copyright 2023, Aaron Rainbolt License: GPL-3+ This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. . - The latest version of the GPL can be found in - /usr/share/common-licenses/GPL. + On Debian systems, the GPL version 3 can be found in + /usr/share/common-licenses/GPL-3. Files: src/serial/Midi_w32.* diff -Nru openmsx-19.1/debian/openmsx-data.lintian-overrides openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides --- openmsx-19.1/debian/openmsx-data.lintian-overrides 1969-12-31 18:00:00.0 -0600 +++ openmsx-19.1+dfsg/debian/openmsx-data.lintian-overrides 2023-11-24 13:47:59.0 -0600 @@ -0,0 +1,22 @@ +# All of these are either false positives or they describe what should go in the directories they are in. +openmsx-data: package-contains-documentation-outside-usr-share-doc [usr/share/openmsx/extensions/README] +openmsx-data: package-contains-documentation-outside-usr-share-doc [usr/share/openmsx/machines/Boosted_MSX2+_JP.txt]
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Package: openmsx Version: 19.1-1 Severity: serious Justification: Policy 2.2.1 X-Debbugs-Cc: arraybo...@ubuntu.com Packages in the Debian `main` archive area *must* comply with the DFSG, of which section 2 states "The program must include source code, and must allow distribution in source code as well as compiled form." The openMSX package currently ships a Windows library (Contrib/codec/Win32/zmbv.dll) allegedly built from code that is part of DOSBox. The source code of the library is not included, and the library is fairly useless in Debian for obvious reasons. On top of this, there are a number of packaging issues that could be improved but that aren't so serious - the most problematic of these is an autopkgtest failure caused by catch2 (Debian currently ships catch2 v3, but openMSX's tests are only designed for catch2 v2 - thankfully there's a vendored version of catch2 in openMSX that builds successfully on Debian Sid now). As there does not appear to be a VCS link to the openMSX packaging in tracker.debian.org, I'm assuming openMSX isn't in Debian Salsa yet, and will provide a debdiff in this bug report. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openmsx depends on: ii cbios 0.29a-1 ii libasound2 1.2.10-1 ii libc6 2.37-12 ii libgcc-s1 13.2.0-7 ii libgl1 1.7.0-1 ii libglew2.2 2.2.0-4+b1 ii libogg01.3.5-3 ii libpng16-161.6.40-2 ii libsdl2-2.0-0 2.28.5+dfsg-2 ii libsdl2-ttf-2.0-0 2.20.2+dfsg-1 ii libstdc++6 13.2.0-7 ii libtcl8.6 8.6.13+dfsg-2 ii libtheora0 1.1.1+dfsg.1-16.1+b1 ii libvorbis0a1.3.7-1 ii openmsx-data 19.1-1 ii zlib1g 1:1.3.dfsg-3 openmsx recommends no packages. Versions of packages openmsx suggests: pn dmktools pn openmsx-catapult pn openmsx-debugger -- no debconf information
