Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)

[Dr. Bas Wijnen]

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)

[Dr. Bas Wijnen]

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)

[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
>  
>  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

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

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?

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

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

[Dr. Bas Wijnen]

-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-