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)
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)
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
Bug#1014255: Long lines should also be ignored from non-code text files
Hi, Axel writes that README.md and LICENSE are likely valid cases. I disagree. While I (and I expect many developers in Debian) are used to using short lines in text files, this is not that common for other people. Many will use the automatic word-wrap feature of text editors and write a whole paragraph on a single line. I don't think I should ask upstream to reformat their non-code text files; it's not a good use of their time, and also they would likely not even do it. Instead, I hope lintian can avoid emitting this tag for non-code text files (in particular: *.txt, *.html, *.md). Although CMakeLists.txt is probably an exception: that is code and it shouldn't contain long lines. I could add overrides, but I don't think this would be an appropriate case for that. But please let me know if it is. Thanks, Bas
Bug#1037804: Fixed upstream
control: tags -1 +fixed-upstream This bug has been fixed upstream. Since a new version is released soon, I'll wait for that. That fix will be included when it is packaged. Thanks, Bas
Bug#1029001: Different link
I just checked again, the link I gave was for the vcs. The homepage is linked wrong from its own README as well. But the link in the github sidebar does point to the actual homepage: https://seanh.github.io/storymaps/. (Which redirects to https://www.seanh.cc/storymaps/.) Thanks, Bas signature.asc Description: PGP signature
Bug#1020875: z80asm: reproducible-builds: build path embedded in /usr/bin/z80asm
Thanks! I didn't get around to this. I probably won't get around to uploading it myself either, so feel free to skip the delayed queue, or else it'll get in in 10 days. On Thu, Oct 06, 2022 at 09:16:23AM -0700, Chris Lamb wrote: > tags 1020875 + pending patch > tags 939775 + pending patch > thanks > > I've uploaded z80asm 1.8-1.1 to DELAYED/10: > > z80asm (1.8-1.1) unstable; urgency=medium > . > * Non-maintainer upload. > * Apply a patch by Vagrant Cascadian to make the build reproducible. The > build path was being embedded in /usr/bin/z80asm. (Closes: #1020875) > * Apply patch from Helmut Grohne to make as z80asm cross build correctly. > It > was failing because it ran its own testsuite despite the value of > DEB_BUILD_OPTIONS=nocheck; the upstream build system ran them as part of > the "build" target and offers no specific test target. (Closes: #939775) > > The full debdiff is attached. > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- > diffstat for z80asm_1.8-1 z80asm_1.8-1.1 > > Makefile|1 - > z80asm-1.8/debian/changelog | 12 > z80asm-1.8/debian/rules |8 > 3 files changed, 20 insertions(+), 1 deletion(-) > > diff -u z80asm-1.8/debian/changelog z80asm-1.8/debian/changelog > --- z80asm-1.8/debian/changelog > +++ z80asm-1.8/debian/changelog > @@ -1,3 +1,15 @@ > +z80asm (1.8-1.1) unstable; urgency=medium > + > + * Non-maintainer upload. > + * Apply a patch by Vagrant Cascadian to make the build reproducible. The > +build path was being embedded in /usr/bin/z80asm. (Closes: #1020875) > + * Apply patch from Helmut Grohne to make as z80asm cross build correctly. > It > +was failing because it ran its own testsuite despite the value of > +DEB_BUILD_OPTIONS=nocheck; the upstream build system ran them as part of > +the "build" target and offers no specific test target. (Closes: #939775) > + > + -- Chris Lamb Thu, 06 Oct 2022 09:09:08 -0700 > + > z80asm (1.8-1) unstable; urgency=low > >* New upstream release. Fixes defw bug. (Closes: #519098) > diff -u z80asm-1.8/debian/rules z80asm-1.8/debian/rules > --- z80asm-1.8/debian/rules > +++ z80asm-1.8/debian/rules > @@ -1,3 +1,11 @@ > #!/usr/bin/make -f > %: > dh $@ > + > +override_dh_auto_build: > + dh_auto_build -- CFLAGS="$(shell dpkg-buildflags --get CFLAGS)" > + > +override_dh_auto_test: > +ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) > + $(MAKE) -C tests > +endif > --- z80asm-1.8.orig/Makefile > +++ z80asm-1.8/Makefile > @@ -25,7 +25,6 @@ > > z80asm: z80asm.o expressions.o Makefile gnulib/getopt.o gnulib/getopt1.o > $(CC) $(LDFLAGS) $(filter %.o,$^) -o $@ > - $(MAKE) -C tests || rm $@ > > %.o:%.c z80asm.h gnulib/getopt.h Makefile > $(CC) $(CFLAGS) -c $< -o $@ -DVERSION=\"$(shell cat VERSION)\" signature.asc Description: PGP signature
Bug#1010148: openmsx: patch for ftbfs on riscv64
Thanks for the patch. I'm on vacation at the moment. I'll upload it after next week, unless the new release is out sooner, in which case I'll upload that which apparently also fixes this problem. On Mon, Apr 25, 2022 at 07:07:02PM +0800, Bo YU wrote: > Package: openmsx > Version: 17.0-2 > Followup-For: Bug #1010148 > Control: tags -1 patch > > Dear Maintainer, > > sorry, I don't know why can attach patch if `repotbug --mutt`? > send patch again. > Last-Update: 2022-04-25 > > --- openmsx-17.0.orig/build/detectsys.py > +++ openmsx-17.0/build/detectsys.py > @@ -53,6 +53,8 @@ def detectCPU(): > return 'sheb' if cpu.endswith('eb') else 'sh' > elif cpu == 'avr32': > return 'avr32' > + elif cpu == 'riscv64': > + return 'riscv64' > elif cpu == '': > # Python couldn't figure it out. > os = system().lower() signature.asc Description: PGP signature
Bug#955551: Is this still broken?
Hi, On Debian's buildd this does not appear to be a problem (anymore?); all of ppc64, ppc64el and s390x are successfully built. So it appears this bug has been fixed by now. Can it be closed? Thanks, Bas Wijnen signature.asc Description: PGP signature
Bug#984273: Fixed upstream
Control: tags -1 +fixed-upstream Hi, Thanks for the report. This bug has been fixed in the new release, 17.0, which I'll upload after Bullseye is released. Thanks, Bas signature.asc Description: PGP signature
Bug#937203: Fixed upstream
This has been fixed upstream. It will automatically migrate with the next release. If this takes too long, I may release a git snapshot. Feel free to ping me if you believe this should be done.
Bug#834472: vmmlib: Patch for address #834472 , #897845
Hi, Thanks for the help! I don't have time to test it now, but the patch looks good. Feel free to NMU without delay. Thanks, Bas On Wed, Oct 31, 2018 at 12:24:29AM +0800, Ying-Chun Liu (PaulLiu) wrote: > Hi all, > > I'll also do NMU in 10 days if nobody denies it. > > debdiff as attachment > > Yours, > Paul > > > -- > PaulLiu (劉穎駿) > E-mail: Ying-Chun Liu (PaulLiu) > diff -Nru vmmlib-1.0/debian/changelog vmmlib-1.0/debian/changelog > --- vmmlib-1.0/debian/changelog 2012-04-29 07:22:43.0 +0800 > +++ vmmlib-1.0/debian/changelog 2018-10-31 00:10:19.0 +0800 > @@ -1,3 +1,11 @@ > +vmmlib (1.0-2.1) unstable; urgency=low > + > + * Non-maintainer upload. > + * Add debian/patches/fix_ftbfs_gcc8.patch > +- Fix FTBFS on gcc8 (Closes: #897845) (Closes: #834472) > + > + -- Ying-Chun Liu (PaulLiu) Wed, 31 Oct 2018 00:10:19 > +0800 > + > vmmlib (1.0-2) unstable; urgency=low > >* Add dependency to build test suite. (Closes: #663949) > diff -Nru vmmlib-1.0/debian/compat vmmlib-1.0/debian/compat > --- vmmlib-1.0/debian/compat 2011-11-26 17:22:16.0 +0800 > +++ vmmlib-1.0/debian/compat 2018-10-29 16:05:44.0 +0800 > @@ -1 +1 @@ > -8 > +10 > diff -Nru vmmlib-1.0/debian/control vmmlib-1.0/debian/control > --- vmmlib-1.0/debian/control 2012-04-29 07:22:07.0 +0800 > +++ vmmlib-1.0/debian/control 2018-10-29 16:05:53.0 +0800 > @@ -2,7 +2,7 @@ > Section: libdevel > Priority: optional > Maintainer: Bas Wijnen > -Build-Depends: debhelper (>= 8), libblas-dev, liblapack-dev, libf2c2-dev > +Build-Depends: debhelper (>= 10), libblas-dev, liblapack-dev, libf2c2-dev > Standards-Version: 3.9.3 > > Package: libvmmlib-dev > diff -Nru vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch > vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch > --- vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch1970-01-01 > 08:00:00.0 +0800 > +++ vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch2018-10-29 > 19:46:59.0 +0800 > @@ -0,0 +1,142 @@ > +Description: Fix FTBFS on gcc-8 > + There are several build failed due to min/max/abs defined somewhere. > + We have to undef it to let it uses those from > +Author: Ying-Chun Liu (PaulLiu) > +Bug-Debian: https://bugs.debian.org/834472 > +Last-Update: 2018-10-25 > +Index: vmmlib-1.0/include/vmmlib/vector.hpp > +=== > +--- vmmlib-1.0.orig/include/vmmlib/vector.hpp > vmmlib-1.0/include/vmmlib/vector.hpp > +@@ -1,6 +1,10 @@ > + #ifndef __VMML__VECTOR__HPP__ > + #define __VMML__VECTOR__HPP__ > + > ++#undef min > ++#undef max > ++#undef abs > ++ > + #include > + #include > + #include > +Index: vmmlib-1.0/include/vmmlib/quaternion.hpp > +=== > +--- vmmlib-1.0.orig/include/vmmlib/quaternion.hpp > vmmlib-1.0/include/vmmlib/quaternion.hpp > +@@ -757,7 +757,7 @@ quaternion< T >::operator-=( const vecto > + x() -= xyz.x(); > + y() -= xyz.y(); > + z() -= xyz.z(); > +-return *this; > ++//return *this; > + } > + > + > +Index: vmmlib-1.0/tests/tensor3_test.cpp > +=== > +--- vmmlib-1.0.orig/tests/tensor3_test.cpp > vmmlib-1.0/tests/tensor3_test.cpp > +@@ -1,5 +1,9 @@ > + #include "tensor3_test.hpp" > + > ++#undef max > ++#undef min > ++#undef abs > ++ > + #include > + #include > + > +Index: vmmlib-1.0/tests/tucker3_tensor_test.cpp > +=== > +--- vmmlib-1.0.orig/tests/tucker3_tensor_test.cpp > vmmlib-1.0/tests/tucker3_tensor_test.cpp > +@@ -1,5 +1,9 @@ > + #include "tucker3_tensor_test.hpp" > + > ++#undef min > ++#undef max > ++#undef abs > ++ > + #include > + #include > + > +Index: vmmlib-1.0/tests/qtucker3_tensor_test.cpp > +=== > +--- vmmlib-1.0.orig/tests/qtucker3_tensor_test.cpp > vmmlib-1.0/tests/qtucker3_tensor_test.cpp > +@@ -1,4 +1,6 @@ > + #include "qtucker3_tensor_test.hpp" > ++#undef min > ++ > + #include > + #include > + > +Index: vmmlib-1.0/tests/tucker3_exporter_importer_test.cpp > +=== > +--- vmmlib-1.0.orig/tests/tucker3_exporter_importer_test.cpp > vmmlib-1.0/tests/tucker3_exporter_importer_test.cpp > +@@ -1,4 +1,5 @@ > + #include "tucker3_exporter_importer_test.hpp" > ++#undef min > + #include > + #include > + #include > +Index: vmmlib-1.0/tests/cp3_tensor_test.cpp > +=== > +--- vmmlib-1.0.orig/tests/cp3_tensor_test.cpp > vmmlib-1.0/tests/cp3_tensor_test.cpp > +@@ -1,4 +1,5 @@ > + #include "cp3_tensor_test.hpp" > ++#undef min > + #include > + #include > + #include > +Index: vmmlib-1.0/tests/t3_hosvd_test.cpp >
Bug#894770: alternative workaround
Control: severity -1 important On Mon, Apr 30, 2018 at 05:34:02AM +0100, b...@hotsite.to wrote: > Just install the package arduino-mk Arduino-mk depends on arduino-core, which is provided by src:arduino. Due to the severity of this bug, all of that is about to be removed from testing. The justification that it renders the package unusable is obviously incorrect: the arduino-core part is still usable and also the gui can be used for developing, just not for testing. So even though this bug is important and needs to be fixed, it should not trigger a removal from testing. I'm lowering the severity for that reason. (I'm not the maintainer of Arduino, but I am the maintainer of arduino-mighty-1284p, which depends on arduino-core and would also be removed from testing.) Thanks, Bas signature.asc Description: PGP signature
Bug#889043: openmsx uses deprecated Tcl 8.5
Hi Sergei, Thanks for the report! On Thu, Feb 01, 2018 at 03:19:51PM +0300, Sergei Golovan wrote: > Since Tcl 8.5 has reached its end-of-life it is to be removed from Debian. So > please, switch the openmsx package to a modern Tcl version. That seems like a simple change. I take it Tcl does not have compatibility problems between versions? Or is there anything I need to test to see if things work properly? There is another change I want to upload anyway, so I'll include this with it. Thanks for the patch though. Thanks, Bas signature.asc Description: PGP signature
Bug#856139: [pkg-go] Bug#856139: certspotter: long description advertises commercial service
On Sun, Aug 06, 2017 at 02:15:17PM +0200, Vincent Bernat wrote: > ❦ 4 août 2017 20:03 +0200, Jonas Smedegaard: > > No, at worst this is misuse of Debian ressources for commercial gain - > > i.e. using long description field for advertising a non-free service. > > We have all kind of software advertising non-free services. Search for > "Google" or "Amazon". The comparison is even unfair as the service > advertised here is available as free software (not the case for most > services from Amazon and Google we advertise). If other packages are worse, that means they should be fixed, not that this should be allowed. > Example: [s3cmd] How is this not in contrib? This software is useless without the non-free service (which is also software, and it is not in main) from Amazon. Policy even mentions as an example for things in contrib: wrapper packages or other sorts of free accessories for non-free programs. That's exactly what this is. I didn't know that this was in main, and I expect most others to not know either. But I don't think they should be. I wouldn't expect this to be controversial, but it seems that it is, given that you suggest they obviously belong in main? To be clear: the sort of software (of this type) I expect in main is like mumble: it connects to a server, and you can connect to a commercially hosted server if you want to, but you can also run your own server, because it's free software. If the mumble server would not be free, and the only way to use the client was to connect to a commercial server, mumble should not be in main. As I wrote, I expected there to be consensus on this. Am I incorrect about that? Thanks, Bas signature.asc Description: PGP signature
Bug#856139: certspotter: long description advertises commercial service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Aug 05, 2017 at 09:38:45AM -0400, Paul Wise wrote: > > No, at worst this is misuse of Debian resources for commercial gain - > > i.e. using long description field for advertising a non-free service. > > I got the impression that Faidon is not involved with SSLMate so this > and the relevant DMUP clause does not seem to apply in this case. While perhaps not strictly against the letter of any of our rules, that doesn't make it any less an advertisement for a non-free service and that certainly is against the spirit. Similarly to not adding a Recommends: from a package in main to one in non-free, we should not recommend non-free services either IMO. I don't think that is controversial? I would make an exception for source files from upstream. If they want to advertise a non-free service, they can do that. For Debian, IMO we should remove such advertisements as part of packaging the software. That means it should not be in the binary package at all. > In this case, the advertisement is also present on the upstream github > page, via the README, which is also in the Debian package, so removing > it from the Debian package description will not remove the > advertisement entirely. Personally I'd prefer to not have it present > in any of the locations, but leaving it in the README in Debian and > upstream seems like a reasonable compromise. Agreed; I would remove it from the program itself or its upstream-written manpage if it would have been there (and of course it should definitely not be in a manpage created by a maintainer), and while removing it from the source (or its documentation) would be nice, I think it's acceptable to leave it there. Then again, it's similar to having non-free software in a release tarball, and we do repackage the source for that. So perhaps that would be the preferred way to handle it. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJZhr4gAAoJEJzRfVgHwHE6jTwQAJGgJL0vKRlcGj70YhjoDDrR /pQiDALVRq0wiQqx+9MNy0px2OeA89TgTtfvm6fh+ibSI+9cC/+FO8GruqGPrxjK NKgyUVUvVNqvSupIzEpbnLQE1QVzi31dvYVzir+lLjJB8sN4oUbNOtTjUWlO4rhT XH8ixzLADqT3VWC30TPUoE8UJ+Nf82eHF67h/4sEwrZWMZgfVfqPR3qTAF0AZsnS ezOtkHl8a3E/QlxOGeMZJ/g2zLVlcRnXU7svEAWdhuSZUT7D9t9I3m5KGwwE1ZLj Kzmlly59DdhyWkqsvWdpifo97avQXlIna4MJeGZW9U8JRdw0V0taWxv1oZ1auprA Cm3hWi/X8DTtvUwOVqEW4aarvvC26dk1uyIz7Z+qHqKF5amir7HxfG81cGNiryyz bBjp6MJAYnnfUeYnn1ZM4qlnJFPNqYSUgoZ/S0uLtOwZGTjaBQsqwewPWKr5pON9 hlG+at1u6wcxTfYJ3guzhB04bp4cISL5Ze3WZwXH3nmTPJi5Rnd7dXaQvkwdzziJ DVcGjZqb3G1LQKABpWmwCxGEXiEgfjki/DmlSDaonX0SUN1lvtfsQ9COcp7kczU1 gb+jcJCR3uerLHvNnmKT8RowQe7j4AHpFGDJuPKid1B+fdYqpNO8/yqE7kScpI97 82ed9JaRCIbFYfXoL+YT =YnvG -END PGP SIGNATURE-