On Sun, Dec 3, 2023 at 2:04 AM Dr. Bas Wijnen <wij...@debian.org> 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
