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

[Bas Wijnen]

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)

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

[Bas Wijnen]

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)

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

Bug#1042995: Provide functional graphical systemd session

[Bas Wijnen]

Package: autopkgtest
Version: 5.28
Severity: wishlist
X-Debbugs-Cc: wij...@debian.org

Hi,

I've written package tests for openmsx-catapult. That's a graphical program,
which I'm testing using dogtail. Dogtail needs an X11 environment with
accessibility enabled. To enable accessibility, the systemd session must be set
up correctly. Simply running xvfb-run is not good enough.

While I can't say exactly what is needed, because I haven't managed to make it
work so far, I do know that it doesn't seem to be something that should be
implemented in every package that provides a graphical interface. Instead, I
think it would make sense to have a Restriction in autopkgtest, similar to
needs-root, which ensures that the testbed has a functional graphical
environment, usable for programs such as dogtail.

Thanks,
Bas

-- System Information:
Debian Release: 12.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 autopkgtest depends on:
ii  apt-utils   2.6.1
ii  libdpkg-perl1.21.22
ii  procps  2:4.0.2-3
ii  python3 3.11.2-1+b1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.31-1.2

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
pn  lxc  
pn  lxd  
ii  ovmf 2022.11-6
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.5
ii  qemu-efi-aarch64 2022.11-6
ii  qemu-efi-arm 2022.11-6
pn  qemu-system  
ii  qemu-utils   1:7.2+dfsg-7+deb12u1
ii  schroot  1.6.13-3+b2
ii  util-linux   2.38.1-5+b1
ii  vmdb20.27+really.0.26-1
pn  zerofree 

-- no debconf information

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#1029942: ITP: python-lua -- library for using Lua scripts from Python

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 
X-Debbugs-Cc: debian-de...@lists.debian.org, wij...@debian.org

* Package name: python-lua
  Version : 0.4
  Upstream Contact: Bas Wijnen 
* URL : https://github.com/wijnen/python-lua
* License : AGPL3+
  Programming Lang: Python
  Description : library for using Lua scripts from Python

This package has been in Debian before. It was removed in 2017.

It has now been updated to use Lua 5.4, and is fully functional again.

The long description is:
 This module provides an interface for using Lua scripts from Python.
 From Python, it allows complete access to all Lua variables and function. From
 Lua, it allows access to Python variables and functions that were passed to it
 by Python.
 .
 By default, Lua contains several insecure features, such as access to the
 host's file system. This module disables all such features by default. They
 are only enabled if the user passes the corresponding parameters when
 instantiating the Lua class.

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#1029001: Homepage in control file is incorrect

[Bas Wijnen]

Source: storymaps
Version: 1.0+dfsg-3.1
Severity: minor
X-Debbugs-Cc: wij...@debian.org

Hi,

The control file lists the homepage as http://seanh.github.com/storymaps/,
which gives a 404 error. Instead, the link should be
https://github.com/seanh/storymaps

Thanks,
Bas

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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

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#1010013: ITP: python-websocketd -- Python module for creating a http server which uses WebSockets

[Bas Wijnen]

On Fri, Apr 22, 2022 at 05:10:24PM +0200, Paul Gevers wrote:
> I assume it's quite different from the nearly identical named
> python-websockets, which we already have.

Yes, it is. They serve a similar purpuse, of course: using WebSockets in Python
programs. But the interface is very different. I'm not familiar with
python-websockets, so I can talk about what python-websocketd does that it
doesn't seem to do.

Python-websocketd attempts to provide RPC functionality, making it work like
the remote object is local. So you need to provide an object to the constructor
(if you want calls to be made by the remote end). Then the remote end can call
member functions of that object and receive the returned value. It can do so
while blocking, or asynchronously. For security (by avoiding accidentally
exposing functionality), data properties and member functions starting with an
underscore cannot be accessed remotely.

Thanks,
Bas


signature.asc
Description: PGP signature

Bug#1010013: ITP: python-websocketd -- Python module for creating a http server which uses WebSockets

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 
X-Debbugs-Cc: debian-de...@lists.debian.org, wij...@debian.org

* Package name: python-websocketd
  Version : 0.2
  Upstream Author : Bas Wijnen 
* URL : https://github.com/wijnen/python-websocketd
* License : AGPL3+
  Programming Lang: Python
  Description : Python module for creating a http server or client which 
uses WebSockets

This module uses the network module to create a server, and implements http(s)
and WebSockets over those connections.  With only 6 lines of code you have a
working system.  You only have to add what you want your server to do.
.
It also provides a client socket, which can be used to communicate with such a
server.

I use this module for many of my networked programs. It requires python-network
(#1010012) and python-fhs (#1010010).

Bug#1010012: ITP: python-network -- Python module for easy networking

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 
X-Debbugs-Cc: debian-de...@lists.debian.org, wij...@debian.org

* Package name: python-network
  Version : 0.2
  Upstream Author : Bas Wijnen 
* URL : https://github.com/wijnen/python-network
* License : AGPL3+
  Programming Lang: Python
  Description : Python module for easy networking

Implementing networking in C is a pain. Unfortunately, much of that pain is
copied to Python. This module instead tries to follow the "batteries included"
approach, like the rest of Python. With this module, networking is a piece of
cake. It can use tcp sockets and unix domain sockets and supports avahi and ssl
connections without hassle.
.
This module provides a Socket class and a Server class.  The Server creates
Sockets when accepting connections; Sockets can be created by the user to
initiate a connection.  All of this is symmetrical: once the connection is
established, the client and server use the same interface.
.
For providing RPC functionality in a language independent way, see
python3-websocketd.

I use this module for many of my programs, usually in combination with
python-websocketd, for which I'll file an ITP after this. It requires
python-fhs, for which I just filed #1010010.

Bug#1010010: ITP: python-fhs -- Python module for using the FHS and XDG basedir paths.

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 
X-Debbugs-Cc: debian-de...@lists.debian.org, wij...@debian.org

* Package name: python-fhs
  Version : 1.0
  Upstream Author : Bas Wijnen 
* URL : https://github.com/wijnen/python-fhs
* License : AGPL3+
  Programming Lang: Python
  Description : Python module for using the FHS and XDG basedir paths.

The FHS and XDG basedir specification defines locations for several files.
This module provides functions for accessing those files without requiring the
program to search the filesystem itself.
It provides a convenient way to use configuration from files, with commandline
override functionality.

I use this for most of my Python programs. It is also depended on by
python-network and python-websocketd, which I will file an ITP for after this.

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#930723: ITP: arduino-sanguino -- atmega644 files for use with Arduino

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: 3-D printer team <3dprinter-gene...@alioth-lists.debian.net>

* Package name: arduino-sanguino
  Version : 1.0.0
  Upstream Author : Kristian Sloth Lauszus 
* URL : http://lauszus.github.io/Sanguino/
* License : GPL-3+
  Programming Lang: C++
  Description : Platform files for Arduino to run on ATmega644

This package contains files for compiling programs for the ATmega644
microcontroller.

This is useful for people who want to use the Arduino programming environment
with the atmega644 microcontroller as the target hardware.

I will maintain this within the 3-D printer team.

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_expor

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#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

Hi,

Thanks both for getting this moving again!  I was distracted, so didn't reply,
sorry about that.  I agree that the packages are in pretty good shape, and any
problems that they still have can be dealt with after they have moved into
unstable.

If I'm to sponsor the package, I would suggest becoming a DM soon, so you don't
need to wait for me.  As I'm sure you noticed, I tend to be MIA at times.  In
such cases, also please send me a ping if I'm taking long.

On Thu, Sep 28, 2017 at 09:18:28AM +0200, Petter Reinholdtsen wrote:
> OK, so lets start with libArcus, then.  Should we coordinate on IRC? I
> joined #debian-3dprinting to help out.  If you got the time, I suspect
> we can get it uploaded into NEW today.

Great!  Thanks for your help.
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-

Bug#706656: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On Wed, May 03, 2017 at 08:57:54AM +0200, Gregor Riepl wrote:
> I just found a few more packages to build:
> https://github.com/Ultimaker/cura-build/tree/master/projects
> 
> fdm_materials seems relatively important, I packaged it and added it as a
> "Recommends" dependency to Cura. Cura will work without the definitions, but
> having them makes it much more useful.

Sounds good.

> Here: https://anonscm.debian.org/cgit/3dprinter/packages/fdm-materials.git/
> Any opinions? Should I name the package differently?

It looks good to me.  The only thing I'm not sure about is "fdm" in the name;
in scientific articles, I've learned to use "fff" (fused filament fabrication),
because "fdm" is trademarked AFAIK.  But it's certainly legal to use it in this
way, and since they've put it in the name, I would just keep it.

> I also added python3-zeroconf to Recommends:, this allows Cura to autodiscover
> networked UM3 printers.

Yes, that sounds useful.

> Cura-Doodle3D and Cura-Postprocessing are still missing, but I think those
> aren't crucial for the moment. I'll add them later.

Agreed.  First priority is to get Cura into Debian.

Thanks!
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIbBAEBAgAGBQJZCsMoAAoJEJzRfVgHwHE6KaUP+O1jn0tb+SK24sjQuK4XPZOF
hd+uPD5g5HM3CJOkZgyfBNDksj+aOa80GMS6YFO90KhjailwByMHr4bsHv/ro+LE
R1O1KDtLZZPg6JR2pc+Lwd99iwiWAhkw8WXqM+OF49wIzCO2GUNzYCtD/MwjK+L2
5CCE32CRGljijLRkgaI+NUuLm6ElklBrMT41ZrCDukB8NVP2SeYuW3tb5ax9bhXz
9igAHRZjZnS9xBJ034p2yyJmBWDbcpCrD2Rk6gWj/H/KeFzaffFfssLTqvZSI6QE
Jsrl1Q6KOAHHnuFfWlLUGmecExciZlJb3rmvvGmv05PUpz8grDvwp7w/AEvap45l
vS7i/T26Pcc8i3q6WTuaGY0FIonHe3ZrOpVuKcTw3kTHSueIZ+ClsN018InIx9a1
sTk4+dnW5jujMJ2x+PMH7MUKJ/HDhAg+vp/8rQEjYurfVY+1fY+vMVNkIQEOGDxe
ikgpL8LIvnJOJycoQenHyLujvN1TU2ck5butNEWFPLvYQgmY+fQvfjSOkAk3dOCB
rJ+ioYmt5F0w75mQs5t91eiodwK7aqW0ojRBXOAlutF0YNBkHXOVOwMH66kIDXY0
i8JwjL66XxmTLzhKerFWraAESZImy6c4PfRecr1sD5wLBo4XeORLmOPA/ObgvYxt
E5fkqx5vB2yYjqa38G8=
=srKj
-END PGP SIGNATURE-

Bug#706656: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Apr 04, 2017 at 11:36:37PM +0200, Gregor Riepl wrote:
> > Of course it is still useful to have your packaging (the debian directory) 
> > under version control as well, and using names for those releases also
> > makes sense.  If you want to name them debian-* that's fine, although given
> > that they only contain the debian directory, it doesn't seem like it would
> > confuse anyone anyway.
> 
> Well, this is the best way to do it when using git-buildpackage.
> If you have other suggestions, I'm all ears. :)

I agree this is the best way; my point was that you should not have a
repository on github with a copy of the source, and the watch file should point
to Ultimaker's github.  Having a repository with the packaging is good.  You
can also host that in our team repository on Alioth.  You are a member with
commit access.

> If at all possible, I'd like to stick to cmake modules and not use anything
> external like pkg-config.
> Or maybe there's a cmake module for pulling in information from .pc files?

It seems like there is:
https://cmake.org/cmake/help/v3.0/module/FindPkgConfig.html

> >> Cura's clipper consists of two files and has no external dependencies. I
> >> don't think repackaging it is worth the effort. Should a
> >> security-critical bug be discovered, it's not going to be too hard to
> >> convince the Cura developers to patch CuraEngine.
> > 
> > When I packaged the previous version of Cura (of which only CuraEngine made
> > it into Debian), I thought it was worth the effort, so luckily for you I
> > already packaged it. :)
> 
> Ok... If it doesn't require too many modifications in the build system.

It shouldn't.  Worst case, you can remove the bundled files and replace them
with symlinks as part of the build.  But using pkg-config is better; if
anything changes, that will change with it and it will continue to work.

> > I tried the earlier version from you, which was also unusable for me
> > because it didn't support delta printers.  I downloaded their new release
> > (2.4), which works fine for me.
> 
> It did - if you built your own printer definition with a custom keepout area
> like I did. ;)

Ah yes, I heard someone talk about that, and was told that it worked, but
getting 2.4 was the easier fix for me. :)

Thanks again,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJY5JFPAAoJEJzRfVgHwHE6+tcP/Rsyb//VpCxA+qp7m9arLvlH
G5BbdKqalyIc6b0y9X+A7UhumlKTFKPgwtLoqzQAR/GNsIcZykA8aQDWIXOajezS
yF3pYin/iB1EOTbKqtBX8qtbVtmI/nCEpKjrHj3ATv/eQ98ojK4Zlxyc7uV9mysg
niqw+SNhOr/4xvtLP6+3OPTfRHDH8W0EceXb2dUlxr5qeZVt5hu6SII0G1chJuCH
B1G4SjhaWeAmp6WRJd2We6zsdFvFXivRZ0rqebHAeTUzRCeyN9EI35hX9Ddl8IFL
40JFDJ7JLVr0HxfuVRbzuVoE17b77BCIorH2dsFnbQNgABE2CdcyDNIJ0UUwrcIX
gTcWTbthoIaW1vPKsZ6D1EevC/jAEJeJlv108wKHn3LDllcIeiBil1crZJAPj7lw
86XX0egUb1YeTxoLuauUO2Dg6eeHqr0TYWjpGfHroIMNdhLvfev8OpY5KeEt13/V
jxaPxuoFnh61/5xE3kbhC2Gw2+cnhm/RC6dROBpIfrz13bI+C12yJNQqfH1gB4Hn
3aVwcrUdGn3Vxg6XNFUlOCDOiyqoU2foYAlW1S3eO/lB5BAOCgXkrXourU57zi9H
ChGM4vhIS3omvsXWFYhp++wFQ8ACqTAvjRCuJLdxSz+8nfnxRIpsNbrGmzne6NcC
o/TVYc7LfL5x/NrkKW7w
=iHHt
-END PGP SIGNATURE-

Bug#706656: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On Mon, Mar 27, 2017 at 09:04:21AM +0200, Gregor Riepl wrote:
> > It looks like this has been forgotten?  I would like to get Cura into 
> > Debian,
> > so if there's anything I can do to help, let me know.
> 
> I'm sorry for the lack of action on my part, progress was stalled since some
> of the criticised points are a bit difficult to fix, and I've been too busy to
> invest much time into the them.

No problem, thanks for working on it!

> I did cut down on them a bit, but the packages are still not done yet.

Cool.  I'm sure we'll get there. :)

> > This is quite confusing, and I would prefer to make it right in Debian.  
> > And of
> > course try to convince upstream to make it right as well.  I'm not sure if 
> > it
> > generates junk; it might.  You should run piuparts to see if ldconfig 
> > creates a
> > symlink that is not cleaned up on package removal.
> 
> I reported the issue upstream, but haven't received a conclusive repsonse:
> https://github.com/Ultimaker/libArcus/issues/52

That looks good.  I hope they will respond.  It is bad for users if Debian's
and upstream's SONAMEs are incompatible; if they install something from us and
from online, it will break things.

> One of my suggested options would require changing upstream versioning
> altogether, the other would assimilate the Debian package version to what they
> are already using. And awhienstra said they would be changing Arcus versioning
> anyway.
> 
> So I'm not sure what to do.

The important part in terms of compatibility is the SONAME.  So the version of
the package doesn't really matter, but the files and symlinks in /usr/lib
should be properly named, and if possible, the SONAME should be identical to
what upstream uses.

> >> Also, CuraEngine is a core component of Cura, and while I assume it can be
> >> used standalone, it's usually not meant to be executed from the command
> >> line.
> > 
> >> But I can take a look and provide a simple man page, if that's desired.
> > 
> > No, you don't need to do that.  As you say, it's not meant to be used 
> > directly.
> > That means two things: it doesn't need a manpage, and it must not be in the
> > (default) executable path.  So install it under /usr/lib/cura/ or
> > /usr/lib/cura-engine/ and make sure the cura package calls it from there.
> > 
> > This means you do need to change the cura source, I suppose, but in this 
> > case
> > that's part of integrating the program with Debian, so it is "strictly
> > necessary".
> 
> I'm a bit reluctant to do this, as it will introduce additional maintenance
> overhead. But if this is the 'proper' way to go, I'll look into it.

Well, the other option is to say that users can use it directly.  This is a
reasonable thing to say; I'm actually planning to set up some automated slicing
system which uses only the engine, not the gui.  So in that case, it should be
in the executable path, and it should also have a manpage.  For programs like
this, most of that manpage can be the contents of the --help output.

As for the capitals in the filename: I don't think there's a rule against it.
Most programs don't have capitals in them, so you could ask upstream to
consider changing it (but you can also not bother them), but it's not a big
deal, and having the same name as upstream is more important than it being
lowercase.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJY2N/gAAoJEJzRfVgHwHE6fl8P/1EabLSF7TUxKvv/jafwwHs0
hTTAjmqy2qgsA/dFN3X2YIMKmX14cxf5fXd3XZ0ASYAWPSKA7hLcTwN4hH8aM69Y
8fB7EYAq2O0COZ7txPRKp4nWXxX8Rn2zoaFpnXEKgjgRNIcZjtl4sT4JoNR2MFu/
T8Hv/8MjVLB5IdoKCX0eaWhE2DlT3Cd+o4n4q1x65vFhbt9f61SYto+kHCRfc7qA
nq4k8O3fxPdEpZkh89P/5ra8TTQhxvvStNsZHUNaT3TXVS5WIMOZA28RzDvP4Y77
ISyQ81eLOmdGZT8VoGHqbwH1Pj3iW9eddOSymR+mi1m1IzNB7jmBHQdLff3HbzPT
SI1BotEO8krT8okKqMEjK46zbabjhh6tcvSWPV9olylCM8zyRns9WYdtVMsxhiij
FMZqTCMpKfV3cBMbwyxqLXfB/ArQyDT4eFgKGGrqhOoIvBHlConYjWA2+q+rKOHi
zBXH5gL6WCbdjIiGpvgQKvA5z+Hx3eCJh9pXVK7lAH+5Ylpqfl1qO5yLvjAnqO9N
gFjhk+xjSrh4+7PnYHm6W8nHti/jWQW9FVLtfS1nmfHmBoMPR9ac46CROA29JB7y
TNi/qpTv2fRImhhRP+NxhlBiD1Wy8PSTxhm6PMzTjebmwpKIRzjrukVvQtpVo4WA
cJQiM/pLA+TSrwqJxyu1
=NPau
-END PGP SIGNATURE-

Bug#706656: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

It looks like this has been forgotten?  I would like to get Cura into Debian,
so if there's anything I can do to help, let me know.

I also have some comments on the comments:

On Mon, Dec 19, 2016 at 10:51:52PM +0100, Gregor Riepl wrote:
> > * There seems to be a line in the changelog that is too long, it'd be
> >   nice to split it into two so it fits into the "80 character limit".
> 
> Ok, I thought this wasn't so important, so I ignored the lint warning.

To properly handle a lintian warning one of three things can be done:
- - Fix the code so it doesn't trigger the warning anymore.  This should be done
  if lintian is correct.
- - File a bug report against lintian.  This should be done if lintian is wrong,
  and this is not an exceptional case.
- - Add an override to the package.  This should be done if lintian is wrong, 
but
  it is unreasonable to expect lintian to be right in this case.

Leaving bugs in a package because it takes too much work to fix them is
acceptable (nobody can force you to do the work), but for a new package it
makes sense to aim for perfection, so making it initially lintian-clean is
recommended.

A pet peeve of me (which is not applicable here, but I'll take this opportunity
to complain about it anyway) is people who add lintian overrides because they
don't want to fix a bug and are bothered by the warning.  That is
counter-productive, and IMO violates our promise not to hide our problems.  If
you don't want to fix a bug, just say it.  Don't pretend that it is not a bug.
But enough of this; you didn't even do this. :)

> Who still uses a 80-character terminal in this day and age anyway? :)

Not many I suppose, but if we all follow this rule, it may make it easier for
programs to display the information is a good way.  In a case like this, even
if I wouldn't be able to come up with a reason for the rule, I'd fix it anyway
because it's so easy to do.

> > * Normally, the binary packages providing shared libraries are named
> >   as "libfooX" where foo would be the name of library and X the
> >   "major-version" [3]. In your case this would mean that the binary
> >   package that provides libArcus.so.3 should be named "libarcus3"
> >   instead of just "libarcus". However I don't quite get what's going
> >   on with this library's versioning. This packages provides
> >   "libArcus.so.1.1.0" and a link to it called "libArcus.so.3", is
> >   there a reason for this? To my understanding the latter should be
> >   called "libArcus.so.1" and therefore the binary package would end up
> >   being "libarcus1". Nevertheless, I'm no expert and it seems I'm
> >   missing something here.
> 
> Yes, I noticed the warnings as well.
> 
> However, upstream seems to prefer naming and versioning as they are now, so
> I didn't want to change them.
> As far as I can tell, this isn't going to be a problem, as there aren't any
> other packages besides Cura that use libArcus anyway.

This is quite confusing, and I would prefer to make it right in Debian.  And of
course try to convince upstream to make it right as well.  I'm not sure if it
generates junk; it might.  You should run piuparts to see if ldconfig creates a
symlink that is not cleaned up on package removal.

> >debian/rules
> >
> >
> > * Lintian reports the tags "hardening-no-fortify-functions" and
> >   "hardening-no-bindnow". There's an ongoing effort to "update as many
> >   packages as possible to use security hardening build flags". You
> >   might want to try to deal with it, sometimes it is as "simple" as
> >   adding "export DEB_BUILD_MAINT_OPTIONS = hardening=+all".
> 
> Ok, I'll try that.

Even simpler is to set the debhelper compat level to at least 10.  It will
default to enable all hardening.  (I didn't check the current level, but if it
is 10 and there's no hardening, it must have been explicitly disabled somehow.)

> >CuraEngine
> >==
> >
> > * It would be nice to include a manpage explaining what the command
> >   CuraEngine does and the command-line options it accepts. Also it
> >   might be necessary to rename it to "curaengine" for the sake of tab
> >   completion and such, but I'm not sure about this right now.
> 
> This will definitely cause problems with Cura, as it expects the program to
> be named "CuraEngine" and I'd prefer not to modify the upstream sources
> unless it's strictly necessary.
> 
> Also, CuraEngine is a core component of Cura, and while I assume it can be
> used standalone, it's usually not meant to be executed from the command
> line.
> 
> But I can take a look and provide a simple man page, if that's desired.

No, you don't need to do that.  As you say, it's not meant to be used directly.
That means two things: it doesn't need a manpage, and it must not be in the
(default) executable path.  So install it under /usr/lib/cura/ or
/usr/lib/cura-engine/ and make sure the cura package calls it from there.

This means you do need to 

Bug#854853: RM: vmmlib -- ROM; RC buggy library without reverse depends

[Bas Wijnen]

Package: ftp.debian.org
Severity: normal

I packaged this library in preparation of packaging slic3r.  However, they got 
rid of this dependency, so I have no reason to keep this packaged.  There are 
no other reverse depends, so I don't want to spend my time on fixing this 
package, and instead prefer it to be removed.

Thanks,
Bas

Bug#854852: RM: libshevek -- ROM; Obsolete and broken library without reverse depends

[Bas Wijnen]

Package: ftp.debian.org
Severity: normal

I am upstream for this library; I packaged it as a preparation for packaging
programs that need it, but that never happened, so there are no reverse
depends.  It is unmaintained now, and has an RC bug.  Instead of fixing it, the
package should be removed.

Thanks,
Bas

Bug#845547: link-flags-first patch causes build failure

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Thanks for reporting this.

On Thu, Nov 24, 2016 at 01:51:58PM +, Iain Lane wrote:
> It's wrong - libraries should come after the objects that reference
> them.

Yes, it looks like it is wrong.  However, with the current build system this
cannot be done right.  Linker flags should be in front, libraries should be in
the back.  The names for the variables are normally LDFLAGS and LIBADD;
openmsx-catapult's build system however does not support a LIBADD variable.

It looks like I didn't enable a verbose build, so I can't see the commandline
that it produces on the buildd.  In a local build, by removing the @ sign in
front of the linker line, I see it does:

g++ -Wl,-z,relro -L/usr/lib/x86_64-linux-gnu -pthread   -lwx_gtk2u_xrc-3.0 
-lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 
-lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0  -lxml2  -s -o 
derived/x86_64-linux-opt/bin/catapult 
derived/x86_64-linux-opt/obj/CatapultPage.o 
derived/x86_64-linux-opt/obj/wxCatapultApp.o 
derived/x86_64-linux-opt/obj/wxCatapultFrm.o 
derived/x86_64-linux-opt/obj/CatapultConfigDlg.o 
derived/x86_64-linux-opt/obj/ConfigurationData.o 
derived/x86_64-linux-opt/obj/PipeReadThread.o 
derived/x86_64-linux-opt/obj/CatapultXMLParser.o 
derived/x86_64-linux-opt/obj/SessionPage.o 
derived/x86_64-linux-opt/obj/InputPage.o 
derived/x86_64-linux-opt/obj/StatusPage.o 
derived/x86_64-linux-opt/obj/VideoControlPage.o 
derived/x86_64-linux-opt/obj/AudioControlPage.o 
derived/x86_64-linux-opt/obj/MiscControlPage.o 
derived/x86_64-linux-opt/obj/openMSXController.o 
derived/x86_64-linux-opt/obj/FullScreenDlg.o 
derived/x86_64-linux-opt/obj/ScreenShotDlg.o 
derived/x86_64-linux-opt/obj/Version.o 
derived/x86_64-linux-opt/obj/RomTypeDlg.o 
derived/x86_64-linux-opt/obj/IPSSelectionDlg.o 
derived/x86_64-linux-opt/obj/AboutDlg.o 
derived/x86_64-linux-opt/obj/CheckConfigsDlg.o 
derived/x86_64-linux-opt/obj/utils.o

So indeed, it contains not only flags, but also libraries.  I suppose Ubuntu's
compiler is set up with -Wl,--as-needed ; that would cause the order to be a
problem.  Using that flag is a good idea, so I think this should be fixed.

I'll contact upstream about it.  (Actually, I think they monitor this bug
tracker, but I'll talk to them anyway.)

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYNxfbAAoJEJzRfVgHwHE6nKgQAJ2CAd/c5bhY9/wXUWOtTyt+
bWIbkJNBwW4MygAvLTfXMe4RFByQYM4NLn8xoeOfhr76p7Txp+rBumu8aifEnf+H
SzE7XUYXQUuCreQWjasG3JwsP69mErEYEdLqrSvHmBuhfJEWs/MjeqMmHDqU46Qo
BDXyPeRekPRjFr+oxd9KlX0RWmvT5/OxnKS83pjUjPxzTAQSS2r4SOcairEKIKRs
dCKrArxPzqTXRUHKon9VYt+QjqxNiV1V6VQXEXbu7T35J2jF8pAMBRvihJHe0Dh1
5HeCZKUDsUErrsK75DBUBm9cKlB17akbG0mByflxwUt+jRu7oUhqTcI0nQqdQgyo
QnqHr5vb2CFuABDsJXE3DblqlmxwLhM4Vq/WL4bTmG0pNzBZ8mMIfqnDhjjrbMaw
MPL/1aQEpQSrN696hFlTSXzYnW7kPHgGFgVS3Bk2BnbFCSO9ETJjpZw5EWuHUcts
zw+BgtnTsTNDjLeRF8iRKHJE4z+WVBEofhg9XrQw70g6efQiYCH5Ey1EJefY8APi
5xfHxgTMts8agBPr3cqLFpuXW3RL+uq1JKKtVeIRXsUBBJ3+fee1kV7/BblWAnFH
6gesqYUSR1+/KRCi9VFk9DKDFWqqTZyBvwaK8QONvho1le+iN9i35z4AcGYoojvS
wY1TIJCJKTjeDNAv/Ebl
=q9cv
-END PGP SIGNATURE-

Bug#842211: ITP: eeshow -- Schematics renderer and viewer for KiCad

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Oct 27, 2016 at 02:08:11AM +0200, W. Martin Borgert wrote:
> Justification for packaging: Eeplot fills a gap: So far I was not able
> to produce a searchable PDF with KiCad, because it always made plotted
> lines from text. Eeplot does it right!

That sounds good!  Is there any reason it isn't merged in upstream KiCad?
Would it make sense to suggest this to them?

(I'm not suggesting that you shouldn't package this; just suggesting an
additional action.)

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYEZqAAAoJEJzRfVgHwHE69gsP/1Dmw396jd1hWc2S3Rwg7VBr
KPSv/xIhxpEUPKnB8AKBx10JDsVx6cN3kNGLQQMcYHziccfv6jCNUufzDkN8x+pK
1yvDYEcGiLN/Pdutmwh4Ev4K6ztKQesU+zJKUWjBZhnLnW7Rf7nmWXclbJPSjvka
pKOfBpx/W+uiNe0D4cZfCPsrqV0O5PpnbmNnLRMl3xFhoe9l4O0qa9ENX1cBwKfM
tCwudjpQLN28CjsqgnHAVndE3aQiGWKEJF5C31Jo2W2Zy+K/B7QArKO4H7gjR1lT
cdqkglNYInNrvd77NYx+JQp0xBGfmnmLXO67PXjM6djL+vBvMnp6ASAp4BB4r7oI
0+FryOrP/CQlgkpiZt+rlUlYdZqAmrshU1V7xU4o7xVdhdAXFZazXCrpAFL6iN6/
8ql5mLt0wHElubVksobmChKVv+SqCAYZl4s4z9lpAiCJNGDAfklRe27e7RXG8JAp
+VtnPCO882l7+zxNXuwY+O3k4iy+Lpj6jVSVFqtWov6RGcKUk+UWRi4WzLRMl/RS
ImwAyXHlMw/fhfo1/+VlVw6nyN7wk/y4RqEsDYHET0g50vOmVrHa89ohINrB3X3q
a8s6WonSBMRyJdMSuNkv7gI+XRwrBXMRfrXRq/ikSP97aQKLAZtMkwnQ9sdwIW22
hqTNu1mIhlyGuCuSft0F
=x8hB
-END PGP SIGNATURE-

Bug#706656: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gregor,

On Thu, Sep 22, 2016 at 01:02:26PM +0200, Gregor Riepl wrote:
> > I can help you with that.  If you choose to maintain it in the 3-D printer
> > team, others in the team can also help you out with that.
> 
> Very good, how do I sign up? :)

You'll want to subscribe to the mailing list.  If you tell me your username on
alioth (make one if you don't have one yet), I'll add you as a team member.
You will probably want to read the wiki on our packaging procedures (seems
approximately what you do now, I think).

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX4/CRAAoJEJzRfVgHwHE6t0kP/0Z+V6s/qkeBIzf4UTakQPg4
YxrgyyAuCXzx8M83iqCX4EgsLuxkx3iR0JpK/i0n4phXtiCOdr35KMjRslc/r4uy
yeWbrirGAGtEB2e2L+snZYHM0BY6+gZ1V309Wiu90J3hhL9KrspYkMaXDV1+Hdq8
zMdHqpJcNbx+HQOTesQkZN/sDBcLq/ce9OoQEdocrjptU75eMFyLxMTBSWCxmxGM
QKb3pa+ok7YmCYg16Or2l0A7i5gRdCD0+JWb/yqaqF0q5gWCqvBVUbW9fTKHt5oz
vgUUMy8IuGZocBYYIDBbreh8kN31dlR/Zt0JXk0BOjXHhidh0Ofz/UsyMp0Z4VCQ
o3rWmVHT8C+oee5v/2MTTHJsbKsPqI6KoI+anczRZ9aUWiEevRi8fiGX+n1p6oF8
WymckA/aky3MWQ0k1vBzuXN7i2kpETRFB9Ug3Uau6aukpettUMIz64QmtP3kTgOb
WWlwPaeBH+dXzbhIZVLbyme48agmauaH8IJkmCboa06EbugcTNm309jB8Kp+datL
V6fn9Rbq3OOQ6OXLVDaQ+YHWtsGepBZgNGC/GJPe13HrzqLhNp+evcY6kBBy243d
yoqQ3HKcv+rkzc/4bYzCGAKJs+CdPKzp9qegwEwIJnUEK9wRSoj/A/XcJuBgBEyB
06jwZ6ma6I1g6VnHH76l
=TTS/
-END PGP SIGNATURE-

Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gregor,

Thanks for taking this on!  I've been meaning to do that for quite some time,
but didn't get to it so far.

Would you be interested in maintaining it inside the 3-D printer team?

Last time I tried to upload Cura (that was before Uranium, so a lot probably
changed), there were quite a few non-free files in the source.  What I still
needed to do was remove them (none of them were required for building the
package).  Did you check if they are still there, and remove them if so?

I didn't look at the package yet, but already have some feedback to what you
write.  I also CCd the 3-D printer team, so others know this is happening.

On Thu, Sep 22, 2016 at 12:57:27AM +0200, Gregor Riepl wrote:
> - All code is released under Affero GPLv3. I believe this is not one of the
> preferred Debian package licenses, but it was deemed compatible with the DFSG
> previously.

Debian doesn't really have preferred licenses.  It is certainly compatible with
the DFSG, some people in Debian hate it and others like it (like me; I use it
for most of my own code).

By the way, is it AGPL3 or AGPL3+?  That is, did they specify "or any later
version"?  If not, that's something to ask if that was intentional.  The
license is acceptable for Debian regardless though.

> - libArcus is built into multiple packages: a shared library, development
> files/headers, and a python3 library. The python library is named
> python3-libarcus to reflect the relationship/dependency with libarcus itself.

Sounds good.

> - The CuraEngine package was named cura-engine2 to avoid conflicts with old
> Cura, which used a very different and incompatible versioning scheme. A
> "Breaks: cura-engine" was added, because both executables install under the
> same name.

I was going to file a request to remove the old package entirely.  It is broken
and there is no reason to fix it; it needs to be replaced with the new version.
Since the old version is much larger than the new one, you can use an epoch
(1:2.1.3) to force this to be a higher version.

With the same name for the package, there is no need for a Breaks:.

> - The debian branch is currently tied to the 2.1.3 release, I will try to keep
> it in sync with upstream releases.

Good idea.

> - Building the packages pollutes the source tree. I have not found a way to
> address this, any hints are appreciated.

Building in the source tree is not a problem in itself, but "debian/rules
clean" should restore or remove all the generated and/or changed files.  That
is, the tree should be identical after "debian/rules clean" and "debuild &&
debian/rules clean".

> Please test it and give me feedback, I will apply corrections and improvements
> as needed.

I hope to try it out soon and let you know.

> If the packages are accepted into Debian, I would like to request sponsorship
> from a Debian maintainer, as I do not have commit access.

I can help you with that.  If you choose to maintain it in the 3-D printer
team, others in the team can also help you out with that.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX43N7AAoJEJzRfVgHwHE6XuoP/3YVYJUYtkv8nYK4UqM/hO8O
Hu98a3QqBB7cvj+FNsP3YnMBvIdSQ3CBTIY2WHIOkjemFT3xw4hVPZvtX1Mk0bvM
ofH9i/bVl72F7nKKKmOne81sxb5fiaVyhu5SjfhsCCjfvDZ1RE9gG4ofMgTZ4evb
tkPyyEi1BxWb/wZuUoyRx5EDNUS+kjBLmY77EU20PULFdH8rFqZ/IXOprllDtWnq
/spp/n13A1sKK1oueAsLUJwU42zBrppqMWQBvv+sL7QgPemJOBTZsqbx+bBUw9/g
HucUg0ZUnT29Qvrt73M0BHp6D0NAphQCGH64QpqOx/gCGeQ8q5Zgb583q1OfvlIG
RnvGQSy2iK/ggTeQZ0HNf5Z8/da3Z+wcYRfEZLJdO/Z3k/D5sok6lzyPAtg7xVMz
eC31FEUDP7ktVs4eyOQe/CypkIt/N+EXMmAxmyL/fAwLxo4Ayv4f0zOc2GPiJe8q
o6ztd4Z7VGqEfzGG4P+FF7xT7dy62WtwCH5YevDji4BcE1OzOFl2Ur4NFeV7QK3u
N8EzDZkn5NWjyp6Y4ORpoPEx3iEMiQz+/CHIlTgSQk2/Eh93vt7B58A0pri62jSf
5MCmFr6YtYJ+ofyk4uzOIdnGQwJeDxh7feTEzjgqR8KWwZPf76EQC03v+0Bpk0G8
kRU+xIrW6piXulNuXOeq
=8kBV
-END PGP SIGNATURE-

Bug#817681: NMU for stx2any

[Bas Wijnen]

Control: tags 817681 + patch
Control: tags 817681 + pending

Dear maintainer,

In order to avoid removal of my packages from testing, I've prepared an NMU for
stx2any (versioned as 1.56-2.1) and uploaded it to DELAYED/7. Please feel free
to tell me if I should delay it longer.

Thanks,
Bas
diff -u stx2any-1.56/debian/control stx2any-1.56/debian/control
--- stx2any-1.56/debian/control
+++ stx2any-1.56/debian/control
@@ -3,12 +3,12 @@
 Priority: extra
 Maintainer: Panu Kalliokoski <ate...@sange.fi>
 Build-Depends-Indep: w3m, m4
-Build-Depends: debhelper (>= 4)
+Build-Depends: debhelper (>= 9)
 Standards-Version: 3.7.2
 
 Package: stx2any
 Architecture: all
-Depends: m4
+Depends: m4, ${misc:Depends}
 Recommends: w3m, tidy, python (>= 2.1)
 Description: Converter from structured plain text to other formats
  stx2any is a converter from structured text (Stx), which is plain text
diff -u stx2any-1.56/debian/changelog stx2any-1.56/debian/changelog
--- stx2any-1.56/debian/changelog
+++ stx2any-1.56/debian/changelog
@@ -1,3 +1,10 @@
+stx2any (1.56-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use debhelper compat level 9.  (closes: #817681)
+
+ -- Bas Wijnen <wij...@debian.org>  Mon, 20 Jun 2016 03:28:52 -0400
+
 stx2any (1.56-2) unstable; urgency=low
 
   * Updated standards-version
diff -u stx2any-1.56/debian/compat stx2any-1.56/debian/compat
--- stx2any-1.56/debian/compat
+++ stx2any-1.56/debian/compat
@@ -1 +1 @@
-4
+9

Bug#826333: Saving new map not arch-independent

[Bas Wijnen]

Package: freedink
Version: 108.4-1
Severity: important

See http://www.dinknetwork.com/forum.cgi?MID=195069#195357 :

> In src/freedinkedit.c, lines 595 and 596, the code uses sizeof(struct
> small_map), but that struct is not defined in a way to keep its size the same
> on all architectures.
> 
> Either that should be done by changing the "int"s into "int32_t"s in its
> definition (and adding "__attribute__((packed))"; it may work without it, but
> is appropriate for this situation), or (easier but worse for maintenance) it
> should be replaced by the number, as in save_map in src/dinkvar.c: 31280
> (line 1044, which includes a comment warning about this exact problem; see
> what I mean by "worse for maintenance"?)

When using the proper solution, that line in save_map should also be changed to
use sizeof(struct small_map).

For context, the problem is described earlier on that page:

http://www.dinknetwork.com/forum.cgi?MID=195069#195091 :

> When I add one square, the map file grows to 437.9 KB. Then at 10 screens it
> becomes 750.7 KB, then 1.3 MB, then 2.1MB, then 3.4, 5.6, 9.3, 15.3, 25.2,
> 41.6, 68.5, 112.8, etc

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: mipsel, armhf, i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages freedink depends on:
ii  freedink-dfarc   3.12-1+b1
ii  freedink-engine  108.4-1

freedink recommends no packages.

freedink suggests no packages.

-- no debconf information

Bug#826324: Array out of bounds in loop

[Bas Wijnen]

Package: freedink
Version: 108.4-1
Severity: normal

While compiling the package from the Debian source, I saw a warning about
undefined behavior, and it is indeed a bug.

In src/dinkc.c, MAX_CALLBACKS is defined as 100, and callback is defined as

static struct call_back callback[MAX_CALLBACKS];

There is a comment on it that says:
/* TODO: Used 1->100 in the game, should it be MAX_CALLBACKS+1 ? */

Most of the code uses k < MAX_CALLBACKS to detect the end, so it would work
(but it would also be one short of what the original game expects; I have not 
checked if the original is writing out of bounds).

However, the warning is about line 843, which says k <= MAX_CALLBACKS.

This is wrong, and there are two possible solutions.

1. Change <= into <.  I think this is wrong, because the game expects 
callback[100] to be valid.
2. So instead, the array should be defined as MAX_CALLBACKS + 1 and all the 
other limit checks should be changed into <=.

Thanks,
Bas

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: mipsel, armhf, i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages freedink depends on:
ii  freedink-dfarc   3.12-1+b1
ii  freedink-engine  108.4-1

freedink recommends no packages.

freedink suggests no packages.

-- no debconf information

Bug#822650: Build environment details

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Martin,

I can indeed reproduce it here.  The problem seems to be that the new libstdc++
is more strict in the includes in requires.  I've added two and it builds
again.  I'll upload a new package soon.  Thanks for the report!

For the impatient: both src/RTScheduler.cc and src/video/ZMBVEncoder.cc need:
#include 

Thanks,
Bas

On Tue, Apr 26, 2016 at 01:02:14PM -0700, Martin Michlmayr wrote:
> Hi Bas,
> 
> * Bas Wijnen <wij...@debian.org> [2016-04-26 19:52]:
> > Thanks for the report.  Can you give more information on the build
> > environment you used?  What processor architecture, compiler
> > version, versions of libraries that were used (especially
> > libstdc++)?
> 
> It's just a re-build of the package in a current Debian unstable
> chroot (using sbuild).
> 
> Seems like libstdc++6 is 6.0.1-2 in unstable now.
> 
> I've to catch a flight soon but I can answer more questions later.
> But you should see the failure in an up-to-date unstable chroot.
> -- 
> Martin Michlmayr
> Linux for HPE Helion, Hewlett Packard Enterprise
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXJSG3AAoJEJzRfVgHwHE6cdUP/0mDAJfsVrXCwz98/VdFFg4Y
JGBcEBO6qfZOnCGZtiZoUfHGaV4Wk/LcAy3hZpte+/GnRG1wcVotjohjazVy+64s
IMaucXUUW2IScFKJOtbfAHHtmoWDFTeu7I1B5urkoTvXF2MX1P/t4t1avsz+yjHr
OrBsd/BOcl5b1AW2vx+0VHeI6GNf5yry5SkOa5J4j4CCZOTSabTSPUf/yM6h1Ocy
ONGPr9q5BnQiJpfoqnKyXMBTdPzsmSsg66NaE0mHwxvJ3+4A7DQug1wnJGUnH3y+
Li0Dj2SU/RMi7z/dTiYVSRdHRJL0bf034hGovlCkubUbdb6fcyrtM7o4s2vdeW+G
G6G3xsbuEfqa3BLbf9zo+bipBnZlJwRMcKryDX/TR6XDZmYnlyuVaBRWmocDBQKV
j9YCMQ0b3Fzoyucjkszg2QYp+X/NJan9TytvM0NrU8haRZjFObhzK3SsSQrdVyMk
DFIKXoFO0uGaA3iCJdScEcePA1K4FcvLEsVz5jk+nbAd2OlyPDKAU2oBSTrZ2BRr
I4bb6QbnsxYR1GVGVxQQ8V7S8A3oqgzh6JKywlHd8hx6BEBYhBNUnudlbvTSqZkx
w0STLPtPvyhvv6BcXUjDwlY1iFRcpgreIOGXr1TsyC3A4cMPGQjt5s+6xDBVFxEh
VF9L2yt0Th9T2BB+fQ3J
=K+tJ
-END PGP SIGNATURE-

Bug#822650: Build environment details

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Martin,

Thanks for the report.  Can you give more information on the build environment
you used?  What processor architecture, compiler version, versions of libraries
that were used (especially libstdc++)?

The report seems to be from a buildd, also because you're mentioning sbuild,
but I don't see a failed build with this message on buildd.debian.org/openmsx/
so that confuses me a little.

Some more information would be appreciated.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXH8bgAAoJEJzRfVgHwHE6nWwP/30uNNY0jxKXo8kPlyijVx1+
K+5ONfWHnnzjuqLpjHdGiFtbRE/YEwTVv+u5IBiA1c/Lkeot5H5WHmn3gO5CNtEo
aV7aqMQhNcz8WDn8xjb8ir/pTqhtc4dCCvxlz91ub2notE80a75O2TXipODxdjYT
PSk1+xmtIPJWlU4ctvoyV9E/dFiZYQsix7xDqrbfFx+vVYBuwqXIPj1nDbuLemjW
GReOMbze8wXJWEYsfloiLXsrH9gY0foGWPHMc/UPdHQ/mVVbsFOXsTdnzAMZFdsB
ORerw6/vhki38jCnT936UxhusGfq03+Zi+xlJNTvvCgzvENQa4vEz9HQFW095ejL
IcSGKa6oi2EY+Tnoc4Clxzk8bnjc7TlQ/YRWTQzcp+boluGtjmZ6UIh+Y4nhZCMj
VJW4rtaYBEIsst3WYfXqjD7IEwWhpAnO9NOCTco9D0s/uPILhVMTdbFIV2JNp8Kk
O3yGQlL/CMkDThVJO1osyHroIj7uUDM7BBfYZg+Ymr1/dSBhHzeclyylvdr5iH/E
rjq7JrL4kvTZhWchufmKidsGxIUWcdUW8O7tw1fVtFnPXKo8dbAIBDCevqDFhu+K
05uQpdvUU6+XppMW2MwDBnW6RbWfTCDE7jNxethWPJMbZO1e8y2ny8cDpcN2SJcq
7w+VgxdY/cGivQu2Hz88
=18/h
-END PGP SIGNATURE-

Bug#818787: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Mar 22, 2016 at 05:04:50PM +0100, Santiago Vila wrote:
> So the number of affected packages if the default HAVE_DOT is changed
> to "no" would be quite low.
> 
> If, instead, doxygen is changed to depend on graphviz, there would be
> nothing to report at all.

I think that it is reasonable to use HAVE_DOT as the default (and add it to
Depends in doxygen).  The upside is that generated documentation is better; the
downside is that builder machines need an extra package installed.  Builders
shouldn't be so low on resources that that is an issue for them.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW8XZVAAoJEJzRfVgHwHE6/WYP/AwmgDodFIJqVpr7yA1ETWCB
t0dK+UyEtwpCUcnR9BMUM4K50tMn19EOzEktuogBxCWLfJWyMg8DnAa6cXke9kgQ
lynbVl2T0nDIrSyGnSqx1Kqzy+K4FG6w6Hh/9qjKN3yCnTkNqo5ISlW0+pkRh2Ln
VYHD9WG2Xy0Heu5cruyxX+Bx7ximzfTKNkH3duWD7ixEa1GQS3qaVd0ybSAAxb0R
4YoWK+2bY9n1ExTpU1qtKBxfwfJp30NS144I9TUjnKrR0b684kx75fv+TAI60B4j
uBJtsBQ0YtyWAx+0BGl1uHiszG0PvXsvtmX07aLFUvTNe0jm+n0f8NbxK2wZ0+IR
6IMolkaQMy/tApBWXKKeGPDhF760iaERE/lK3Cfb/cEaS64i7h35loJg8itP87O1
SXee2vVkbByTHtMhM0KxwAAmXLYaLyhrEJWQQyFfstIbBT3yNpvo4r/V+F0kwxM+
s6QFBcZuuJ4MD44bm0Z3duRi9DhIid/oHwOw8akELAtPsKqkoFCzNMMeOMgXMysC
J3UtShQ8iT39gMcJIZq8XSr8O2r3ohAVDfJAt53KRjnLIddZayUKgTwNzD3EMD2w
jmUK0kg2thBlZbu+C1ElXjRTTcTJVmVjqpiyLt9dKYV4l74p7SAgU2wXpEbHuMtw
8DddW4ejVpMWWbBFw90W
=QEB7
-END PGP SIGNATURE-

Bug#818900: [Lua Policy] integrate debian's lua modules into Debian's Luarocks

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 21, 2016 at 02:37:44PM +, lumin wrote:
> When I'm dealing with one of my ITP's I found that this is
> a noticeable problem to Debian's lua packages. And I think
> this may require some changes to our lua policy, or the dh-lua
> scripts.

What you describe should be fixed.  There is a problem with how your scripts
work, though: if some packages are installed before luarocks, they will not be
indexed. Not unless luarocks scans for installed packages on installation
anyway.  If it can do that, it might make more sense to just trigger that
procedure when a new lua module is installed as well.

Making that part of dh-lua seems like the way to go.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW8A3zAAoJEJzRfVgHwHE6Qu8QAIglXrTQ5g3fuMIfAMoUz+Z/
qmtOu18LBZ+c20D1GgXRSz5AC+v9/9qLrEwYxM5smmOOaW7nEtNDfBOBY2Zme4Mm
NcTe1kqzaR/QOQ6zCRANzTD5ZcLsk88DSRxXby0cOBBXrPr+QtDruDESre3Wmu67
BW24kAD79kAp+W/gLxN2IIvRPMkOWF2/Q8ElxujD6Hm1qLanpkIvkJwqoQmrRnrL
eN/EG+LbOOwoJ+sXeH/SXE/Cox6XrECahb2PQQPlxRN3KElMnu+JspV76eOAF53r
sn7hsPl7TfNHHC63ciWOiMv5JfXGGikl3/UMfJSCiqQB29iE3H7/xLkK/euEI0wL
cVUEMeVC6AsgldAGlufiqIgQgXK4pcms+sOt6/AlnwkWL6JtoQuf3cp0dCFtGMtu
0AUcre3I/9DG7lrkHFcI1GITt//kXsDajodhqIfgzK+rfmctfNb79fe3Indb/1OI
t0u7AompBTqTA+adojbjvRgj2XXmcgk/hcUGzTlD6Rfwkbv3dHE4EicUOdM/XL2g
jhSbNmrfnpAWg9Mf5rcGyB9uFjiKIz2pcI7zfl/B9B12zWsgpt4qq8l0Ktl0apcs
OwlQ6Ocp5m/N7vq3x2Ml7i2Rbo6JsinVeQJ9Q4zA+1V0uozR5s2yMYbL92X8AcWp
YDmDAUpOfKl91w6h17+F
=GHup
-END PGP SIGNATURE-

Bug#818787: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 21, 2016 at 11:26:16AM +0100, Santiago Vila wrote:
> > Yes, so that's a bug in those programs, not in doxygen.  It would be 
> > "fixed" by
> > adding graphviz as a Depends to doxygen, but that would be incorrect.
> 
> Please note that it is really doxygen who calls dot while those
> programs are being built, not really those programs. And doxygen calls
> dot because the HAVE_DOT variable is set to yes by doxygen, indicating
> that the dot command is available.

No, it is a configuration option which is set by the calling program.  It
defaults to yes, and for that reason it makes sense that there should be a
Recommends relation.  But the caller is not required to keep the default, so if
it does, it is calling dot through doxygen.

> Do you agree, at least, that it is not doxygen business to claim
> that the dot command is available without a Depends?

I just reread policy, and changed my mind on this.

Policy says: The Depends field should be used if the depended-on package is
required for the depending package to provide a significant amount of
functionality.  The Recommends field should list packages that would be found
together with this one in all but unusual installations.

I wouldn't consider the graphs a "significant amount of functionality", but
that is subjective.  I'd leave it to the package maintainer to decide whether
that is the case.  Given that they chose to make HAVE_DOT the default, it seems
that they do, so then a Depends would be in order.

On the other hand, if they decide that it isn't, then the proper way to use
doxygen with HAVE_DOT enabled (explicitly or as the default) is to depend on
graphviz.

So I agree that if HAVE_DOT defaults to yes, it should be a Depends relation.

> Since we are all Cc:ing the bug address: This bug report is not to ask
> doxygen to depend on graphviz, that would be only one of the two possible
> outcomes.

Agreed.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW8AViAAoJEJzRfVgHwHE6nVAP/Rz/av7mSDWdE2ZbLuhHi53h
rLhES9CKE3YGIY7rXIyrKDIr3o2XiKYQtO4yLEhyBzxRPjMdxta2hnr/xUGyzlaW
icR+/ugj9agt8oN11As/kTdr1HZVxjgyaGWAlbaNu6xrFFoK0EZ8atKmroPXtL6R
jjfVJBDWpssX+G5oI4xWX0toVRCp6r9HYMuJIei33qDoSzyVekx0GUXaG/zSE5Pe
tpKHR+swiYbM6d9s0MB7TyjTDDdN83XX9LnBEwXOtEn6FVeFJ1eBl2VgTXNF1wRu
q01jIQFmdIgrpJey6GImfwA1uqrCg8QNqThvOA7//NY0iBXIb37jLNsi5ir90Ot5
LYakDtJtwpi6bq+AZo+THQ4AKChQX28PCuZHGAVbaDycbM0fhbfriJ6pqAQZ5Ut/
dZhjrP6FaPZ/AxowS14lv+tl5dreP9ZnaQE6yqNvKztPNp8AkQPerne0EPYlNr4I
OFw4/CzOyMjaT7U7Hb0xjzJw5CHsZodjPkdTysgNzBfHsNLKsIzKiL29HtwA7bIR
QNiuP9ANAgPIL/XYidiSpTVwrjj3kKKQ7/niAAwVRq4aPJBACKxYeT7Zy3a9BDDk
mnmU4Ahfnu6Q6RB/wYKxChs/CZgadcGrWWuRUfELP/HEfHIig6PWLR5nFAuTBG9r
YAgQtIkupO2lRRVOBqBM
=5Z8f
-END PGP SIGNATURE-

Bug#818787: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Mar 20, 2016 at 08:07:55PM +0100, Adam Borowski wrote:
> On Sun, Mar 20, 2016 at 06:51:23PM +0000, Bas Wijnen wrote:
> > That also means that programs calling dot will need graphviz in their
> > Build-Depends, no matter what the default is.
> 
> As is, a number of them do call dot without the build-dependency.

Yes, so that's a bug in those programs, not in doxygen.  It would be "fixed" by
adding graphviz as a Depends to doxygen, but that would be incorrect.

> > > The disappoining moral for this is that nobody looks at their build 
> > > logs...
> > 
> > I don't think that's disappointing at all!  It means we have built a system
> > that will let us know when something is wrong.
> 
> That would be the case if doxygen propagated the error, which it does not.

And that _is_ a bug in doxygen, IMO.  If it cannot produce the requested
output, it should abort with an error.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW74DXAAoJEJzRfVgHwHE6jBIP/RbYo/q85gRUI5YIyEwAETF0
RLpIWDvWFvJRhg9TGfVA3VfeAmLrsOG59V6cwuszObY1I1VX1NVpJi1RoUTiZ9O2
d7l3boQ8YRb8ll3e49LLsfHoIWw6Tp30KjbrrvsOWjH/18NDZkEK89uXFzK+/U8/
kDMADNsFvpo6/5MzSp59LSn7+YvKKuOOSypkPR2K1DzYhCL8lPno3lq8lCX6uAz/
oXjwIuFMR1KNJx/pxL9DeM+bP+9qwe0xQlL48C7kuGzvyT0ZF2gofETtlHvAbrQe
Mg3y7EbBKU6hNLi7hs9KqI8G9h+9FuyI5jeyNv0ixQQrtbDWlY8j2LBOQbwBGnNO
PeSQ0e+HmcRQgPCqBcysGxmCfTpJmfS+lAC5Q3ip62sVHIQzot/GnQBUBVZLUi2W
JGBF+JJirQ33cIw8v67Uguy4GO3/ba/I+NZFKug4poPvskmuVhMJHB0gU5Nr3mL0
Sn3dC54mzPtQk6Eq8oace9hZl39v3dHhWG/Oce/dL8sKhwkIUhc19LGk/mc0aHCQ
FC2bTVLMeCM3ZjCso1piXA10WeD5JFK2hg4B4sQCtbePQLfWXTsLsKSkNdEWqpU3
NeEeMtVaQwyMV0WRQD5JKSoClpTSsQf7cF+c+U3IKVOhkZJpwh8TKUQASo9f6Ywe
Rj66EyyM2s72+7qVxS9Z
=fTpp
-END PGP SIGNATURE-

Bug#818787: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think you are mistaken about a few things.

On Sun, Mar 20, 2016 at 06:04:55PM +0100, Santiago Vila wrote:
> The maintainer points out that the default value for HAVE_DOT is NO,
> so he's reluctant to add the build-dependency.

If the program can be used without it, it should not be a Depends.  That's what
Recommends are for.  Default values have nothing to do with it; Depends are for
things that will make the program unusable if they aren't present, Recommends
are for things that should almost always be installed with the program.

That also means that programs calling dot will need graphviz in their
Build-Depends, no matter what the default is.

> But this is inconsistent with having graphviz in the Suggests line for
> doxygen.

I agree that if it is the default, it should be Recommends, not Suggests.  This
doesn't change anything for the problem you're describing, however.

> The disappoining moral for this is that nobody looks at their build logs...

I don't think that's disappointing at all!  It means we have built a system
that will let us know when something is wrong.  That means we don't need to
poll for errors, because they will be pushed to us.  (I think porters are still
doing this manually at least some of the time; I think FTBFS bugs should be
reported automatically.)

In other words, my solution to this bug would be to make doxygen exit with an
error code when calling dot fails.  Then make will fail, it's an FTBFS, it gets
fixed, and everyone is happy.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW7vEqAAoJEJzRfVgHwHE6Gm4QAKAhBvdYk+2kTZ6SKTjgH/B0
4OIBO8nSOJe+O5yTB3AordZq2zZS1afM0oWB3JiVfa6l6Ka9dfC8f9TOlvW5xGnm
pj0OO7b7jrH5oK5XToqj3DvDphNKpNwWnHKbeBWlJY779SVBa50kdwnbtg77wa5k
ZBl1NWLFlFeRgjbG6BQpn1l50NyRLMzTumLFtF+rpZACAwoiH+bkJVDlu83lfM72
/B4WLl9G7wxnhwhtfs2PcvRaYF8EzGuNDizu2PbwCp31CKUszF4+0q9JiqHtTwmV
VIFxB31fSU/RpmEIxI086wStd/Rax+Cn8HfAyTY6/tIOVBCeHYnNajWZkVEcNsoj
srsaGpPEGJouGr/MLqQIk5n6LLsiERq4aha5WpmccmgkNCxTIUXZlU62J6y5DzlT
lDkG5NXkEuf1qsk9bUJQEAbvdCKfbX6mtlbibxtGlSpeZ6LwfsQ+M9MoX300kH84
UYHMovo6M9CHXLdxt9AJOVBJTbERXbKVysnrov2pVlZSZiPFu7M/haz6Um13Vsku
AlIpYRYpfTRiNZ/dg1Tf0AtnMkSIqhy1441Jj+Egpe9EXAs9GfWaYNOa1yZYm1d8
1Wcbh0NdzakVDNmTWuPg47bGt7IOGUcgM74DQuRLCWxcaOOnErs0nI7+3x3kZ+5/
77few9WmaB+ZHhDWb+Vv
=AU0O
-END PGP SIGNATURE-

Bug#813923: Error message is unclear

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: dbconfig-common
Version: 2.0.2
Severity: minor

Hi,

During an upgrade, I saw the message:

MySQL database support detected, but apparently missing Depends on 
dbconfig-mysql packages. Please report this issue to the package maintainer..

There are two things wrong with this.  First, it has 2 periods.  But more
importantly, it doesn't tell me which maintainer I should be contacting.  I
reporting this here after finding which package sent this message using
codesearch.

Thanks,
Bas

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: mipsel, armhf, i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dbconfig-common depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  ucf3.0033

dbconfig-common recommends no packages.

Versions of packages dbconfig-common suggests:
ii  dbconfig-mysql  2.0.2

- -- debconf information:
  dbconfig-common/db/app-user:
  dbconfig-common/dbconfig-remove: true
  dbconfig-common/upgrade-backup: true
  dbconfig-common/mysql/admin-user:
  dbconfig-common/remember-admin-pass: false
  dbconfig-common/remote/newhost:
  dbconfig-common/pgsql/changeconf: false
  dbconfig-common/missing-db-package-error: abort
  dbconfig-common/remote/port:
  dbconfig-common/upgrade-error: abort
  dbconfig-common/pgsql/method: TCP/IP
  dbconfig-common/pgsql/revertconf: false
  dbconfig-common/pgsql/admin-user: postgres
  dbconfig-common/database-type:
  dbconfig-common/db/basepath:
  dbconfig-common/internal/reconfiguring: false
  dbconfig-common/dbconfig-install: true
  dbconfig-common/dbconfig-reinstall: false
  dbconfig-common/remove-error: abort
  dbconfig-common/purge: false
  dbconfig-common/mysql/method: Unix socket
  dbconfig-common/passwords-do-not-match:
  dbconfig-common/pgsql/manualconf:
  dbconfig-common/internal/skip-preseed: false
  dbconfig-common/remote-questions-default: false
  dbconfig-common/pgsql/authmethod-admin: ident
  dbconfig-common/db/dbname:
  dbconfig-common/pgsql/no-user-choose-other-method:
  dbconfig-common/pgsql/no-empty-passwords:
  dbconfig-common/dbconfig-upgrade: true
  dbconfig-common/pgsql/authmethod-user: password
  dbconfig-common/remote/host:
  dbconfig-common/install-error: abort
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWtivsAAoJEJzRfVgHwHE6qk0P/1HZB0+BmTCCQr8WrYdzy5Rf
Ihn5VqleOSCHwwI0AhPP6wDT4AY5zSwh9oeTfD/YmLKKa2iZgxngOXHG3AA0rAS3
X8Z7Ek/1SXsxw5o8YwaPFwfxMDKxofHNgOBPzKeK1BEevNr7bL3bMc4cmQFlDnoj
peLOeiMprCL52FS99aClW7CfZ+DrCtylvZ6NlqJa93aqRrxRLAEYGJvqmTSgabIg
DJXQeveNgLjgEedO2t9vXabaNslTCKFSG5Ye1QWGLQEDTwDaCkxWofO/RIepT62v
lpaPhBZD3m1t9uLsWKgMVRSx0GHMOcpkG3jfw3OXbR1etKcINXE4aXRYCom2Fe4R
rqRUmkmepu5rKPqeD39ikNMJPOrGpZXFn4kPh69p7+4dSeFf+L/o/hbm4h+1Di7J
4FadQZc7wLm6XMzFrQc5eZRQnmvCpbkAzZoHXGxoBDS+Wu/75taBd5Drnv49hHe6
ZbEa56D6Tu3ZKLmM4deeX77i4a87njodsPPiPYBHV9d40xq/boetI4U++xWuW2N/
d4aDJOvoiYcZjRQ+NAcpCS8CtVYgMGBZvSZ92YTX6j/n0RnLGyllkEby6OWruToc
nnGqh8hC44DcsI6SwqAQYqSzFbKf/BwiSEGDIszxHO0yFCZ3LOfbcID356kKRGHT
4i0O093vw4m7i4smdOZB
=oPiG
-END PGP SIGNATURE-

Bug#809960: openmsx: FTBFS with libpng16

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi, maintainer here.

On Wed, Jan 06, 2016 at 08:21:44PM +0100, Tobias Frost wrote:
> PS: beside that pngtool, there are also a few B-Ds that needs to be
> rebuilt against libpng16 ... 
> 
> So, I guess, if it builds at your place we can stay cool and wait until
> the transition starts. The fix with the new BD is easy then...

So should I do anything right now, or should I wait for the transition to
start?

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWjaofAAoJEJzRfVgHwHE6lXQQAJrZmY8iYizLME3tCreRl+pH
PLR8C0cYjG2jDLTgxffEuRSQafOCuPJbNMXMzUBngcmDfj2TNHFuC8CRED8a2T2b
4tRRCHD8MggzTaB+rpfzbkvBu8XXEiMq10PWSQgCnyRa3hLExAYb1Nnbsgc4Fr0A
ekK/so+Ze1v5L6fld+OHvHTaHab+4ZEa3gh5vWDhuJwLb3Y/Xb/z6ELA8P15KDq4
/d9NSRaKm+s8QeBrsXwX6q1TQdfOZ/jvNiVu0UyMhq7MoYiIFQ9mQ5cQXms4fICv
685XADFMs3BIktZBnMDrvY0r5yTVTQYCNhhDsNa9tQp32lOFmgjdiOpv2gfuAbeh
oGLQzkFBhMuBJI+OGoTMTNbGg9DBD3nsKIEkODVRj1VMjTPgTSthAOmih7tHvWaL
wtGRw0LrbvXBzeWjhgSLGWVxme6QykBBqeeOLwAjVwb5h9F9VMz13Vu2nZ0W1GVI
31dWQexH+3CUORFDKa2+c+ACrrgLGprXZ96DtytSquB5GxJ6dNOcFhxb39izbrvo
vgWtCeJW8ranHr7+MrgOaLM8wXQx1/g0bZWG9puUyiHIefU75lM3Vy0kDGbQq8mP
ifYRKbD0fx4xhU/OrHYToY/DW2BTdSMspL9K4ZP+PwLUGzodeqWmpiaLu5G4fbbe
k67B62z3VR5IuSBhFaZI
=moxV
-END PGP SIGNATURE-

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote:
> Philippe Cerfon:
> > On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER  
> > wrote:
> >> Discussing infrastructure changes like what you're proposing (which I
> >> have no advice about) should usually be done through our mailing
> >> lists,
> > Which one would be the appropriate list?

debian-project, or hopefully debian-devel.  -project for talking about the
idea, -devel for discussing an implementation.  Having an implementation ready
hugely improves chances of it being done.  But of course probing the community
to see if there are any protests (as you are doing now) is a good idea.

> Your second item has been brought up before with different
> focus/rationale/purpose.  At least I remember there being an interest in
> splitting "non-free" into "non-free/firmware" vs. various other non-free
> sub components.
> 
> Mind you, its primary goal was not to address "source vs. no-source",
> but it is the closest related idea I could think of.  Sadly, I don't
> have a reference ready to backup my memory.

Yes; I think the conclusion of that discussion was two things:
1. Different people want different splits.  Using something like debtags may be
   more useful, so users can block their own tag selection.
2. The firmware category is special in that pretty much everyone needs it, so
   we may want to make that its own section the old way.  This allows people to
   use their hardware without enabling any (other) non-free sections and
   without worrying about debtags filters (once implemented).

Note that it was just my impression that there was consensus on this; I may be
mistaken.

Note also that nothing has happened (AFAIK) since that discussion.  Someone
implementing things would be very welcome as far as I'm concerned.

> On your first item, I would have to agree with Christian.  It is not
> actionable and much less by Debian.  At best we could stop packaging
> such software or disabling such features, but both have their disadvantages:
> 
>  * Even if we stop shipping them, people will still download them.
>Except your average user will probably be worse off because most of
>them do not verify their downloads.

I agree that not shipping things (that we are allowed to ship) is a bad idea
most of the time (except if it's because nobody considers it a priority; giving
upstream an incentive to release their software under a free license is good).
The exception is software that actively hurts the user (malware, spyware).
Which we can only block if we know about it, of course.

>  * If we disable the functionality, we would "cripple" the software to
>many people.  If this annoys people, we will end up in a situation
>where people will advise /against/ using the Debian package because
>it is "crippled", which leads to the situation above.  Or we could
>get badly unpopular with upstream (see the "Debian vs. Ruby" issue
>from a couple of years ago).

This is a valid concern, but it shouldn't always be the deciding factor.  Many
people (including me) use Debian because it easily allows installing a 100%
free system with a huge choice of packages.  If the choice is "move a thing to
non-free, or keep it in main and disable the functionality", those people will
lose the software completely if it's moved to non-free.

Disabling functionality is work, and when it's done, it's done for this group.
It leads to "crippled" packages and the complaints you mention, but the
alternative is moving it to non-free, which leads to the software missing from
Debian main entirely.  Either option may be better, depending on the situation.
Perhaps it's best to do both, like unrar does (AFAIK): package a "crippled"
version in main, and the original version in non-free.  But this is even more
work, and the maintainer has to decide if it's worth their time.

Personally, I don't care much for non-free, so I would choose between disabling
the functionality and not packaging the software at all.  But that doesn't mean
everyone has to work that way; if others want to spend their time on non-free
packages, I'm not stopping them.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWijfHAAoJEJzRfVgHwHE6J7gP/izcwZPCJ9YvtpDf9FNtDKmA
7Vop3e1wZD2h7G93FY/YvQkufkFQhW9KJp3cIZ2UkCDq6EBt5Of6xtoDEtSWmedV
Hi4djop7nIXJxFnzB2/5wMYVLa+DIeRUUhtR8/HkQu2/GCbf1SIbOH3ZjH2SW0Kj
BozkqzyQQkFv7t/GK9y34goW6l4oc0CF+vINlRV+iV886C0166Kim1rOBWM8Ctfq
JrP9JcfwVBFIVzznK2+6E4/0bCLT1AeRORyfpwIW/QI0+3wmjoECdmA2PRrtTxgD
vy1ZNEfAY+BxYIo4XJsSQpE4VTgtYMmnYDuP4IWx9NUlYKVA3jWwjdn4FSim5fRl
BqWk9tdY4zmM62WGkqLexwSgeyx2Ozh+zh9Cf4TIVRK5OXmUK3E2VUCA9CvE87pw
Dayw3F7ZJX0N5Tpal55DDcBEVHOFFmLgfqHHy80HEM1rgQnwbQE9Z0CrRckhDjIK
jQkCaZynCSknB/5iG7eL1U4UiLySmrxNYqCbuU7T5gEY6SABghwCdcFyCwtRttXC
Q/4H5bXDw7E/PszsSvaUDe39NsDS9xBDbpgSZ/OhylkhimhwUhtixWaNBCDzC9Tw
SLgQaW8TYrAClRzKM+JRBSJM8hTX1R3+CsnS1wVy3em6BRohFO/I8uq+kZZ5007S

Bug#794311: KiCad 4.0 rc1

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On Sun, Oct 25, 2015 at 08:16:46PM +0100, Georges Khaznadar wrote:
> - I was touched by the issue which you already mentioned : building the
>   core of Kicad depends on "calling home" to sourceforge, to get the
>   release 1.54.0 of Boost libraries.

No, that is not what I mentioned.  The git repository I used was using Debian's
packaged boost, which is correct.  What I wrote about was that the default
module library configuration is filled with github references, which means that
it will connect to github when CvPCB is started.  The libraries are installed
in /usr/share, which is good, but they should also be used by default.  Github
module libraries should not be enabled by default.

I noticed some files related to avhttp that were created during the build,
which suggested that there was some downloading going on there as well.
Downloading things from the internet during package build is also not allowed,
so I hope you are correct that this doesn't happen.

>   I quilt-patched the file CMakeModules/download_boost.cmake to make it
>   work quite like the script download_avhttp.cmake in the same
>   directory: instead of downloading Boost's archive from Internet, a
>   local copy is used. I shall include this copy into the debian source
>   package, by adding one operation more in the script get-kicad.sh

No, this is not good.  To avoid code duplication, we should use the version
that is packaged by Debian, not something that is shipped in our own source
package.  The source I was compiling complained that not using the bundled
boost was not guaranteed to work, but it does work fine.

> Another possibly annoying task would be to check whether the Boost
> package from upstream must be stripped down a little to make it
> DFSG-compliant, without touching files which are unseful for Kicad's
> build.

You can skip that; the package should not use their bundled version anyway, so
it is not a problem if it's not DFSG free.  Since you're repackaging the
tarball anyway, you can just remove the bundled boost.

> Another task, probably lighter if I can do it wisely, is to constrain
> Kicad to comply with the FHS, that is, put architecture-independant data files
> in /usr/share, architecture-dependent stuff in /usr/lib, and user-level
> commands in /usr/bin.

That would be nice, but I think it's not a priority.  At the moment, KiCAD is
uninstallable in unstable.  If there is a package that works, IMO it should be
uploaded as soon as possible.  Making things nice can be done in a later
upload.

To be clear: the module library path and (if it happens) build-time downloading
of sources must be fixed before uploading.  File paths can be fixed later.

> I read that you found hardcoded data locations in Kicad's core source.
> Do you estimate that changing the hardcoded paths will be a long task?

I searched for where they were, but couldn't find them so far.  Once the source
location is found, changing them to a different path should be trivial.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWLS9IAAoJEJzRfVgHwHE6v6UP/jVvJvaGuEjYv60amURUDqRG
EWtH65SAvteD9rgOsNuP4QYX1qQ3V7Ncr/FYHvRozZeaP52gjxbTU4gbv/RNCyVi
3auYXhgLU4WBorgzSq5ke8fSjYXR2k39n+J26sEeHP5KWhismef78GOit08z1wpN
HButeh6oiHbkYXli13yBs8BskiXbg1KU/WLwfwVpGvWEWGXcCYU/Nu/tCK+JTIIo
lW6K26ofnVJ5oZuDVdde7W80ptLRyVmaEc4n4vY8rfoQaZhpaiv8/LddDCinPKii
VxzAPUVZNaBN4Vn5pml3zRIMFYQ6vngam5ngEW6bqToPMxRaA0YI++JD4z17N7wO
yF5K2/Khyh7kymyC2u+epMKYRK3btH1bowW7dd1R7xSncSvdv+2jJS1wx66Eul6Y
CP1sTPMx2/SsYLAFAVun7Iw+E0PvADkymd2Cu+bvlioY3vINzKX1vxaUbyhAZkMI
7HIPbtAn/6LcdIfRNZnS/3lc/DcFUNQjUlKtp0ITZG526FJjCpoGAvPHCRiftcH1
hkSLDldUt6MjghmeTPQv+LYnB46s6FEtZRdJQM++f8YCIIyxGC9yuQ/kShS7N1Wc
jtZXcU71raTqqCglOaJqa+tLjIyWZ7H3bsKtnwb7XQjSmOYKleDHnw0oHbFmRryY
iLEp1wupYL1EU0IOlzXw
=oTym
-END PGP SIGNATURE-

Bug#794311: KiCad 4.0 rc1

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Oct 22, 2015 at 04:10:58PM +0200, Nick Østergaard wrote:
> 2015-10-21 19:39 GMT+02:00 Bas Wijnen <wij...@debian.org>:
> > The default library path mentions lots of things on github (but it doesn't 
> > seem
> > to look there, which is good).  It doesn't include the files from 
> > kicad-common
> > in /usr/share.  Adding them manually works well, but it would be nicer if 
> > they
> > were enabled by default.
> >
> > When running cvpcb from eeschema, eeschema hangs and nothing happens.
> 
> Is your  footprint library table full of github refferenced libraries?
> If so a delay of a hand full of seconds is expected, depending on your
> connectivity. Be aware the github plugin does not seem to work if
> behind a proxy. :(

You are right.  Or at least it works after removing them.  So it seems it does
look there.  Github has been really slow lately, and my internet connection is
pretty slow anyway, so even though I waited longer than a few seconds, it makes
sense that I should have waited several minutes.

In any case, the Debian package should not come with those github libraries
enabled by default.  That would be considered "phoning home", and it is not
allowed.  Having an option for the user to easily add them would be acceptable,
but I'm not sure if we want that; if the package is regularly updated, getting
the libraries from Debian's servers should not be a problem for most people
(and the ones who do want the github sources can still add them manually).

> > I had a program set up for generating .net and .cmp files as well, so I
> > wouldn't need to use eeschema or cvpcb.  However, pcbnew doesn't recognize 
> > the
> > footprints I'm requesting, so perhaps my .cmp file is broken.  I have no 
> > way to
> > check what is wrong though, because cvpcb doesn't work.

Ah, I see .cmp files are no longer used.  I changed my program to add the
information to the .net file and now it works again.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWKUedAAoJEJzRfVgHwHE6qN0P/iuri1mrEgFeokn8WMy8/cNr
9ru7RUXWw4KOABemYUVc3uCHAtusUHmAZXquAQFqbnVPzL38A9t36M0bv8DPXW2H
9h4yNZa0Ns8ByHqAJfXVLm1t8pTYI1AURSY9ntRrt0Ry/jUOsKkTbWQzGHXNTvn2
lrk/t6D0waiT1EbcUm+zxLm1erWloKm4wgidXeEkr8a8DZcTZExaNuMrFncGfBIl
ryZONUblLMmHdPnssqpzsm6L8WBL68iyi4Oxsn92i95/mIEF3XheFnu+M/mJ2wVb
MMYQHgOz3lH6EYal1ez8DmR+01pg2nz1dHrUTL2Rsc/6mpMZy2cVaDnXVA43gUvn
vcvbnRWAOEyhBtAJHYwmZecz+waMWwhYE9g5gPgE3GnYpVVFBrekgWLkoM64/DtT
GopSKArvR/bcj1AIuhRW7JtHmPj5LS3wvMGnqJ98fTx5p/7yq/eEGrNpStIYAQCh
6PrLwun0yD+tTh5cHLHlSxRQ9T1Qe0Hr/BDeDIHvZW222Lv8t2GGo8AqyCV5PyJM
7L1wpDES4M3RuKdxHmSO+EZfSe6Nt90KeTBfDICmjvw7HCplMaoIhCe+J6C6Zt8m
HvKGbISYTSG5soNdglh6X1m7G1+YJqpjvC6/gihu+BzCIg//PvyLJsf/gN+N5lrw
la82XWjhYWRxJjJKa8I8
=FueY
-END PGP SIGNATURE-

Bug#794311: KiCad 4.0 rc1

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I had some trouble building it, because cmake refused to build in-source.  So I
changed it to build out of source.  The package installs fine, but so far I see
some problems:

The default library path mentions lots of things on github (but it doesn't seem
to look there, which is good).  It doesn't include the files from kicad-common
in /usr/share.  Adding them manually works well, but it would be nicer if they
were enabled by default.

When running cvpcb from eeschema, eeschema hangs and nothing happens.  cvpcb
doesn't seem to be a standalong program anymore, so I couldn't try running it
from the commandline.  Running _cvpcb_kiface just gives a segmentation fault,
but that may be expected behavior.

I had a program set up for generating .net and .cmp files as well, so I
wouldn't need to use eeschema or cvpcb.  However, pcbnew doesn't recognize the
footprints I'm requesting, so perhaps my .cmp file is broken.  I have no way to
check what is wrong though, because cvpcb doesn't work.

I'll send a pull request for the out of source building soon.  If you have any
ideas for how to fix the problems I described, please tell me.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWJ83oAAoJEJzRfVgHwHE6S4wP/Az1A2qfcOmjyheWja0yeSou
oVXIPfEApDjfQDhsTNR4Tfsn0Fm1Y5MTgbb6YjDHI5K29ylAUk4c5wXnuEcBmaPb
CDfGBcr4n1fEstFNKUTyhnXpjMHplglhexQkb0dOkBswgYNXBFNBKtKhv2epA7Z7
xNQMm3uaatdWZhEvrgXnLw/t2nOWm5DqeEqDNotctNHRfDG9XUBjitT1AUwGC/FE
lrsj0al/mBIIoLQvXY13+n1/7TTZkRcrBtAPapGJdeCOdZq7M7ipcRjb1CYvjQ0n
CwtlXDDUcV9yg2jHIcGU/hfQfDWBJjJbRMRhYAbRwRStG5NQBQx6RH191YyI+3yG
jrZ+SzUaaJwW14DNEMLAblw6PK3bABuat3Gjl4lErfHxXExmp3lkjItazsjDPRFj
t4JJt7T3KUG2HI0o2paLeKbMIcrUfYN8RgWHFIFGzUc76IwJtZOyup1TFa9KVi4H
lY4l8zCrxB/PuPHfooLHJf2pN7DCqa+m3QKl1rPscjtewCkCVoocSzr1o6gsasBf
D2424Y+zVPzO0w2PemyFisvVPwrY1lzSkfWbqO1bheMJJjbMK9p9CiaRcYtdaMml
N3d3jgbCvtA+lzUxmh92iPxoSX36yMlrDU5movWS4Otmv60LUlhaGfMu1VaImXP9
LbVUtpLbq39Jd3ARWG4Z
=sO6i
-END PGP SIGNATURE-

Bug#794311: KiCad 4.0 rc1

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Oct 11, 2015 at 03:30:40PM +0200, Gregor Riepl wrote:
> > Yes, both.  Report upstream and patch it in Debian until they fix it.
> > /usr/bin should only contain executables, nothing else.
> 
> I reported the problem upstream, but it looks like it will be addressed
> post-release as it's not a critical issue.

I agree.  But it should be fixed in Debian regardless.

> Fixing it with a Debian patch will require some insight into the KiCad plugin
> loading code, which I do not have (yet). If someone could point me in the
> right direction (i.e. which sources/makefiles to patch), that would be very
> helpful.

I am not familiar with the code yet, so I'm not sure if it'll help much, but
I'll take a look.

> > Python programs look in the directory of their executable for private 
> > modules.
> > I've seen packages solve that by installing them to /usr/share/packagename/ 
> > and
> > making a symlink from /usr/bin to there.  That works because Python will
> > dereference the symlink when checking in which directory the executable is.
> > KiCAD probably doesn't do this, so in that case that approach doesn't work.
> 
> You're still referring to the plugin locations, yes?

I'm talking about making the main executable a symlink into /usr/lib/kicad/, so
that it will hopefully use that location as the default for its plugins.  It
works for Python programs, but it's unlikely to work in this case.

> There are a bunch of example Python scripts shipped with KiCad, which are
> currently installed into /usr/share/doc/kicad/scripts and not symlinked to
> /usr/bin. I don't think it would make much sense to do so, as they're more of
> an exemplary nature.

Yes, I'm suggesting to put less things in /usr/bin, not more. ;-)

> kicad-common previously contained all the libraries (symbols, modules and 3D
> packages), icons, file type associations, examples, i18n, scripts and 
> templates.
> 
> i18n and all the libraries live in their own repositories now, and they are
> updated independently from the main KiCad code base. So, stuffing the
> libraries into kicad-common package will tag them with the main KiCad package
> version, which does not accurately reflect their actual revisions.

Yes, if they have their own release schedule, they should be in a different
source package.

> If you would like to help, you can check my packaging scripts at the github
> link I posted previously.

I'll have a look.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWGs+EAAoJEJzRfVgHwHE6jhAQAJd0Uz3I4DDE4MZXAKeo0dbc
n5YqonFbFzy8VBgQnEGwbvCeLIeknSsXMZUSXcli+aDr9+2c8C6ugVEyW5waU1kA
CLEqRP3C22VElS2lruoCNnyLS6FVsrYONBvPu83YaZhrI8kF3WF2MYcuhTDnmpuz
rZ2JKTYNBp+GHPWx6jwk+NY44V/eyKqvoMD1Rds5oUbIhF4TT6YPYFFL0GRs0Sl9
q9IcebMd0qPFdu5I7a1dSpFT11tmSCi8d1R0BQiIX8govKYun4L9DFxfdg0qHi0l
zN0MSwscw20+pqfQvu0oQWAYlhpL1nvVus0JqmRzIJHjUAyeFPfO1m8H2KvPY9E6
HQt4ZQQsbXcclsLX8RA1T23ZAVGPZfYFLuRlnw954lbzBnWt1DvyPR3jiz+E6IOi
dQiKFgfMsQLNu+oN1eWZvMtCTlFh/aHfmsUVMJSRusb3u7f8EAdQu5OJf7Snlvxk
p1toHqtCazhekUjQSOzaciioJgj6+UWZNcEGHwxWkf1NpgzPHxY7FT4e1H1XQiOF
T6NhdzgCJQnsh/4d6/FcnDvln41J4cl729uWeuHTy9/cPeBbgYtUTZEu6i43JaS3
V07ORaCD6xrdwn1Kv9qbPxS5fk5dCdt1tqY75MHv+m6IBoHQOxBgRZpOaUYyskF5
uUhCxZNO7KB1i2hBH9ag
=MK9+
-END PGP SIGNATURE-

Bug#794311: KiCad 4.0 rc1

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

On Fri, Sep 18, 2015 at 04:20:15PM +0100, matt.notting...@zen.co.uk wrote:
> Going by the current blockages due to the GCC5 transition, even if you
> had it packaged now, it wouldn't be available!

Yes, I recently updated my system and had to remove KiCAD to get the update
through.  Now it's uninstallable.  If there's anything I can do to speed up the
process of getting the new package in, let me know.

Probably no longer relevant, but here are answers to some questions:

On Wed, Sep 16, 2015 at 04:25:31PM +0200, Gregor Riepl wrote:
> - UI plugins (_cvpcb.kiface, _eeschema.kiface, _gerbview.kifacem
> _pcb_calculator.kiface, _pcbnew.kifacem _pl_editor.kiface) are currently
> installed to /usr/bin. Should I report this upstream and request they be
> installed to /usr/lib/kicad instead? Or write a patch specifically for Debian?
> They are dynamically loaded libraries and not executables, so in my opinion,
> they should definitely not live in /usr/bin.

Yes, both.  Report upstream and patch it in Debian until they fix it.  /usr/bin
should only contain executables, nothing else.

Python programs look in the directory of their executable for private modules.
I've seen packages solve that by installing them to /usr/share/packagename/ and
making a symlink from /usr/bin to there.  That works because Python will
dereference the symlink when checking in which directory the executable is.
KiCAD probably doesn't do this, so in that case that approach doesn't work.

> - Would it be better to pass -DCMAKE_INSTALL_PREFIX=/usr to cmake, so all
> built binaries use /usr/* for their data paths by default?

I am not familiar with cmake, but most likely, yes.

> - Should the libraries be moved to a new package, like kicad-libraries instead
> of kicad-common? They have become quite large, and the Github repository seems
> to be updated regularly. This also begs the question if such a package should
> be built separately from kicad.

I don't know about this.  What is the purpose of kicad-common?  You mean there
should be a new source package, so they can be updated without triggering a
KiCAD rebuild on the buildds?  That sounds reasonable.

> - The KiCAD developers have designated their new stable release as 4.0. Debian
> currently uses a date+revision version scheme. Should the Debian versioning be
> changed to reflect this? What is the proper way to do so? 4.0+bzr is what
> I currently use. Good/bad idea?

If you're packaging the upstream release, you should use the version without
revision.  If they are preparing for the release, so you are packaging a
checkout of code that will be released at some point as 4.0, you should use
4.0~revision (which can be called whatever you want, as long as it is
monotonically increasing).  Using ~ instead of + has the effect that it sorts
before "4.0", so when that is released it will be the newest version.

If you're packaging a checkout which is based on the released version, you
should use + (or at least not ~), because then your version should be greater
than "4.0".

I thought their code was on github?  Using "bzr" sounds strange in that case;
"git" would make more sense.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWGUQ2AAoJEJzRfVgHwHE6dSAP/1aPWixrLWaBZxE9N2GhOlG8
BFLBMbpP+IA65Y1MIKT9OnElfHi7bthmRhW3qCKMJiq8ypN/0qCzLtXdo69FW1IH
tajMozgER1eVZNKw4+i9vVUOzmqagpyAVzEfOIRVfrx/B4fqmIg66gMOfrPrdN1a
3R7sX0s9rev6WbV2QRsGJGxkUpx7lSnUMRrEXXkvw+XcTQtsKggn5RNEVxUteQsQ
ndM0ZYX8QFbGmr8pfK5lgAEv6dvAIEbfGbBm8Csoa8Z1oVZv4wEBxBdDeKL7hbjs
08N2BifPiotMzoD7hvIpkFmLODj62X/iYO648YJP41QQ2Hmg/JlVuEFIOUwhYt/N
eelzmhEEFK/4NK/d7+x6yYjtqUrBhGGYa+O9kDsZHwbq3RwDMPi2FYfLOkqNFlB2
rEtfRDOlBhhwNDtVl5eyPMI+flppCUjQsk51X2UHvlXtMYYJij7p+dA5rbNiY+L9
KmHVDOH1c7kEO0qHrQ4rGj2LEHSRrHDHleapoQbhGkzhHgsRTyytN617sjA5sZpF
hDS2AuNWL6oYsu5tvqRIjstwjBnlzoxmIiLhoMxK8Rmjc2t6d4h5rw+9WOov+2Qj
1rKcsKdzb2hxfW8yaF1yfA3slBybfoWwFLhqEJg9370yMB0fI9fT+CBF+pbfvLh4
Vqw3OImoXdbnKVckJ+wq
=2J3Y
-END PGP SIGNATURE-

Bug#786028: python-lua: diff for NMU version 0.3-1.1

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks!

On Sat, Sep 05, 2015 at 05:00:15PM +0500, Andrey Rahmatullin wrote:
> Control: tags 786028 + patch
> Control: tags 786028 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for python-lua (versioned as 0.3-1.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> 
> -- 
> WBR, wRAR

> diff -Nru python-lua-0.3/debian/changelog python-lua-0.3/debian/changelog
> --- python-lua-0.3/debian/changelog   2012-08-31 21:22:35.0 +0600
> +++ python-lua-0.3/debian/changelog   2015-09-05 16:58:09.0 +0500
> @@ -1,3 +1,10 @@
> +python-lua (0.3-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Replace python-support with dh-python in Build-Depends (Closes: #786028).
> +
> + -- Andrey Rahmatullin <w...@debian.org>  Sat, 05 Sep 2015 16:58:08 +0500
> +
>  python-lua (0.3-1) unstable; urgency=low
>  
>* New release with some fixes.
> diff -Nru python-lua-0.3/debian/control python-lua-0.3/debian/control
> --- python-lua-0.3/debian/control 2012-08-29 21:29:12.0 +0600
> +++ python-lua-0.3/debian/control 2015-09-05 16:57:37.0 +0500
> @@ -2,7 +2,7 @@
>  Section: python
>  Priority: optional
>  Maintainer: Bas Wijnen <wij...@debian.org>
> -Build-Depends: debhelper (>= 8), python, python-support, ruby-ronn
> +Build-Depends: debhelper (>= 8), python, dh-python, ruby-ronn
>  Standards-Version: 3.9.3
>  
>  Package: python-lua



-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV8aD9AAoJEJzRfVgHwHE6K/0QAJ/qw1HBmiUi6r8glKRUaEWI
e3lvH6iOJK82iUf8wf14lN3HSp9lL/MaqQlF2Ed34D4dpPd60OwcrXQd0VMTbs7/
VsqOfu1ov/Vd1gDVnRSSspa+NCYIWRfKlqMG0inbAGh26NDHy71I6AESyQM8fih5
IorSTPvfGtHo4A1+UlTry/ELx7d3tIKgfpLBup8273sqPN0OlSJ8WLKxR5OmsjIl
lDaVFfzokEXGjjC5UGy2lzMiuMGiAiV0YEr7MSNtNQ1EKK0rTDmLTTdUClwDCtha
IkdIho69gsT+/A6GzFIjbRyDOXWda0sqD1dyGEuzYvcZJerT++4bzGLa/+nwz/Rn
ZbutrvKnGQgee7kOLmB4x8Dp7mUlkjeim1qCBm9eRLH0UZsVaZwJU/NAWGHqfLae
1e5xsHDHgwg1rkOzBCZI1kCDwpUG1b8wMlpjbT1T5DgHgCaTJRGZDGLGEdbpqt8g
Fh8KUsMT608mBVxbYqEg6Nj4OHkQuN273I8VV2PAs1dp5weS8pn1kFsnCX4jpEGt
lLPjv9RF/OyVwZ9G44AfueLNxVsrA2XP+6Vq9UH4mwW3I8voCVl4XyTuuWR+Pvyp
XnkXQkw+1NU14NkJupE4RCOtXnw/ObcaR9BAA+Ru0Z5jY/CwCCxZyicdOBedM6ye
p61V9joFOlMFPscNu6Si
=hOum
-END PGP SIGNATURE-

Bug#795334: [pkg-gnupg-maint] Bug#795334: If --local-user matches the default key, it should be used

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On Thu, Aug 13, 2015 at 04:45:29PM -0400, Daniel Kahn Gillmor wrote:
> In the meantime, you have a possible (clunky) workaround: you can remove
> your old key from your keyring and then re-add it.  this will change the
> order of the keys in your keyring and will make your new key the first
> one found to match your User ID.

Ah, thanks for that tip!

> I've had some discussions with GnuPG upstream about adjusting the
> selection mechanisms for years [0].  I'm not sure when we'll be able to
> convince them to make this change, but i'll keep pushing. :/

Sounds good, thanks for your work,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJV5LrzAAoJEJzRfVgHwHE6qdwP/3pXNiK8lihUae+e3tXc6Iuh
dWUZeITved3cEoTdmuInpaTUPXMqist9V0cAAwfzt9NIBZVce6nzyXk7DrsxjK60
pDAbuNtqZNp1TAT4E/j3QvBXV7kvaI2UK462ampvkvEBwwGiAAjzjhuDtLUZrq4E
RpOE8vd3B8QSC4fXAY3FXuHpCF0hZiLgG/vIMzjfG1JlpFmdr7hTyW4Ws6u6mxuG
A/M0h+8B8VRoPSm/cti2o5KB64KjZzOEDNXNT/+VOWHOMgL5BKrPdg6NS40xB2Z/
kE9whYBfTmSnDD2FkUdDoeblo6ssjh1TsMZlsWR+JdUt4hceRVu9uabwW09kIqJ9
bzI9lJhitE39KuUgdTF1leLu8H9dfXqGyvs03K5MD3VBSgim9em6rvVgdHVtUx75
PM7ZwOUoYon/QmPNSj5ygYP+PXKF1I/sgdoq+9+UFqkzvhIxfqtD4WYdTSUhBTKj
QvfmecvOY1nmibqpFyQidWuZ8+HgxqiRCSYxMbmVPautiTk6GWlXL6XPwsHqNRjC
Ip0VMID4uNRqwRqQR2U63ZYgnAmcPHqsV+eH5ZfYZ2KU04l83a/Fl3ov6je9MJ5N
Yh3kDJH4Vw9zSG/R/22mGTowYc5eCOqfmuahaIAY2oOPkkPLFtm3O7o75C9vz6SR
Ys2lbQBXim0nezon54//
=MEby
-END PGP SIGNATURE-

Bug#795334: If --local-user matches the default key, it should be used

[Bas Wijnen]

Package: gnupg
Version: 1.4.19-3
Severity: minor
Tags: upstream

I have an old key which is not revoked, and a new one that I use for signing
everything.  I have set the new key as default in gnupg.conf.  When I call gpg
--local-user=my name (or more specifically, when debsign calls it that way),
it selects the old key instead of the new one (I'm guessing it just selects the
first key that matches the name).  It is counterintuitive that it chooses the
wrong key after I set the default properly.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: mipsel, armhf, i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii  gpgv  1.4.19-3
ii  libbz2-1.01.0.6-8
ii  libc6 2.19-19
ii  libreadline6  6.3-8+b3
ii  libusb-0.1-4  2:0.1.12-27
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
pn  gnupg-curl none
ii  libldap-2.4-2  2.4.41+dfsg-1

Versions of packages gnupg suggests:
pn  gnupg-doc none
ii  imagemagick   8:6.8.9.9-5
ii  libpcsclite1  1.8.14-1
pn  parcimonienone

-- no debconf information

Bug#750918: Fixed in last upload

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 11, 2015 at 06:24:42AM +0100, Olly Betts wrote:
 The wx BD has reverted to libwxgtk2.8-dev in 0.11.0-1:

How did that happen?  I thought I removed every trace of the old library from
my system...

I'll make sure I do that now.  I think a binNMU would fix this bug, right?

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVy5uuAAoJEJzRfVgHwHE6Wt0P/1EJB5AAE9KGjgWj6/fKOX/6
x90KQjkPeP8KAU5gCW/NnQvRW5MmJd8Km4ezOr8dckt2uuUZ+1sdUD8Uuz7Odnht
uk2g7T2KjCZDD9brVcdTWxWzKeK2QHZdsfBbWKSHdeqRgGNV0UkV3HaT6qsouTgS
KyIKaPPprkWXPxPN2xw99GRqTRd6IGoZiWSffLTyADGr5arFNmoW5OnzedAwMpdc
nZyKmRdfQRpVeJP/9xC9csE7w3ZOWI6oNpxQushpV50E09FDISzvB86Zbd/+nDYI
K/s/c/6E5+oYTXHV6fUCLghy1yw+Oy4rzGnmfQpWadse916yaF9xBj5LZXlXS80c
+hksDABCQbcNFRWJP8WKx1FmSPCRQ6fGYKENGxrikg5j8HnAZxFTBauTvadXtGhK
8ZXHPaPOTTym60Zeax794VxqK0S9558aDSyanv+Aa6+63peJgKn3f1bohURZeKYD
05UwzHtjmKdmulaC28dc1M+gCTPISK6X/EKnq2Oro2M/ZPQIwPiWlCnzcxilYgup
NRBA+Y3dkZic9BBtt3E3YfjCv/5OOQHhw5f6ndOrjSzzQYUkJCbuf/XbOJ5bZzIh
mcFB9KcFX2TZwoLzEm0kIXjllTnFR33wQ8BFI7lEeEBHG54vn2TV9eAD0+EQYnNk
sSlwkVNFUBG6GBBzk2V9
=PE7N
-END PGP SIGNATURE-

Bug#745034: Time to fix this in Debian?

[Bas Wijnen]

Hi,

the fix has been committed to upstream's VCS, but that was almost a year
ago and they still haven't made a new release.  I've just sent a
reminder, so perhaps that will happen soon.

However, I would very much like to see this change in Debian as soon as
possible, so will you please consider adding a Debian patch, which you
can then remove after upstream releases again?  If you prefer me to do
an NMU for it, I'm happy to do that as well.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780972: Support override files

[Bas Wijnen]

Package: mini-dinstall
Version: 0.6.30
Severity: wishlist
Tags: patch

apt-ftparchive complains about every package in the archive if no override file
is present.  An override file can be given either as a systemwide setting in
/etc, or on the commandline.  Because there is no reason to require root access
for mini-dinstall users, it would be nice if it was possible to pass the
override file on the commandline.

Attached is a patch which adds an override setting to the configuration file
of mini-dinstall, and it passes its value to apt-ftparchive.  When passing this
option and creating an override and override.src file, this removes the
warnings on my system.  The patch does not include documentation for this
option.

Thanks,
Bas

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: mipsel, armhf, i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mini-dinstall depends on:
ii  apt-utils   1.0.9.7
ii  python  2.7.9-1
ii  python-apt  0.9.3.11
pn  python:any  none

Versions of packages mini-dinstall recommends:
ii  gpgv  1.4.18-7

Versions of packages mini-dinstall suggests:
ii  debian-keyring  2015.03.04

-- no debconf information
diff -urp mini-dinstall-0.6.30.orig/debian/changelog mini-dinstall-0.6.30+nmu1/debian/changelog
--- mini-dinstall-0.6.30.orig/debian/changelog	2014-08-25 22:51:08.0 -0400
+++ mini-dinstall-0.6.30+nmu1/debian/changelog	2015-03-22 13:16:31.901672410 -0400
@@ -1,3 +1,10 @@
+mini-dinstall (0.6.30+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Pass override files to ftp-aptarchive
+
+ -- Bas Wijnen wij...@debian.org  Sun, 22 Mar 2015 13:15:51 -0400
+
 mini-dinstall (0.6.30) unstable; urgency=low
 
   * [885f9fc] lintian: fix vcs-field-not-canonical
diff -urp mini-dinstall-0.6.30.orig/mini-dinstall mini-dinstall-0.6.30+nmu1/mini-dinstall
--- mini-dinstall-0.6.30.orig/mini-dinstall	2014-08-25 22:51:08.0 -0400
+++ mini-dinstall-0.6.30+nmu1/mini-dinstall	2015-03-22 13:08:40.357710669 -0400
@@ -245,6 +245,11 @@ else:
 if configp.has_option('DEFAULT', 'incoming_permissions'):
 incoming_permissions = int(configp.get('DEFAULT', 'incoming_permissions'), 8)
 
+if configp.has_option('DEFAULT', 'override'):
+override = [configp.get('DEFAULT', 'override')]
+else:
+override = []
+
 do_mkdir(toplevel_directory)
 dinstall_subdir = os.path.join(toplevel_directory, dinstall_subdir)
 do_mkdir(dinstall_subdir)
@@ -1125,9 +1130,9 @@ class ArchiveDirIndexer(threading.Thread
 
 def _make_indexfile(self, dir, type, name):
 if nodb_mode:
-cmdline = ['apt-ftparchive', type, dir]
+cmdline = ['apt-ftparchive', type, dir] + override
 else:
-cmdline = ['apt-ftparchive', type, dir, '--db', '%s.db' %dir]
+cmdline = ['apt-ftparchive', type, dir] + override + ['--db', '%s.db' %dir]
 
 self._logger.debug(Running:  + string.join(cmdline, ' '))
 if no_act:


signature.asc
Description: Digital signature

Bug#768176: Bug#765319: marked as done (missing license in debian/copyright)

[Bas Wijnen]

Hi,

Strictly speaking this doesn't count as before cristmas, but I've just
uploaded the new package to testing-proposed-updates.

Thanks,
Bas

On Thu, Dec 25, 2014 at 06:36:05PM +, Debian Bug Tracking System wrote:
 Your message dated Thu, 25 Dec 2014 18:33:34 +
 with message-id e1y4de6-00066u...@franck.debian.org
 and subject line Bug#765319: fixed in pioneers 14.1-3
 has caused the Debian Bug report #765319,
 regarding missing license in debian/copyright
 to be marked as done.
 
 This means that you claim that the problem has been dealt with.
 If this is not the case it is now your responsibility to reopen the
 Bug report if necessary, and/or fix the problem forthwith.
 
 (NB: If you are a system administrator and have no idea what this
 message is talking about, this may indicate a serious mail system
 misconfiguration somewhere. Please contact ow...@bugs.debian.org
 immediately.)
 
 
 -- 
 765319: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765319
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems

 Date: Tue, 14 Oct 2014 09:08:16 +0200 (CEST)
 From: Thorsten Alteholz alteh...@debian.org
 To: sub...@bugs.debian.org
 Subject: missing license in debian/copyright
 User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
 
 Package: pioneers
 Version: 15.2-1
 Severity: serious
 User: alteh...@debian.org
 Usertags: ftp
 X-Debbugs-CC: ftpmas...@ftp-master.debian.org
 thanks
 
 Dear Maintainer,
 
 please add the missing license of:
  editor/gtk/pioneers-editor.svg
  client/gtk/data/pioneers.svg
  server/gtk/pioneers-server.svg
 debian/copyright.
 
 client/gtk/data/style-ai.svg is licensed under CC-BY-SA 2.5 which is
 not DFSG-free, so please remove it.
 
 Thanks!
   Thorsten

 Date: Thu, 25 Dec 2014 18:33:34 +
 From: Bas Wijnen wij...@debian.org
 To: 765319-cl...@bugs.debian.org
 Subject: Bug#765319: fixed in pioneers 14.1-3
 
 Source: pioneers
 Source-Version: 14.1-3
 
 We believe that the bug you reported is fixed in the latest version of
 pioneers, which is due to be installed in the Debian FTP archive.
 
 A summary of the changes between this version and the previous one is
 attached.
 
 Thank you for reporting the bug, which will now be closed.  If you
 have further comments please address them to 765...@bugs.debian.org,
 and the maintainer will reopen the bug report if appropriate.
 
 Debian distribution maintenance software
 pp.
 Bas Wijnen wij...@debian.org (supplier of updated pioneers package)
 
 (This message was generated automatically at their request; if you
 believe that there is a problem with it please contact the archive
 administrators by mailing ftpmas...@ftp-master.debian.org)
 
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Format: 1.8
 Date: Thu, 25 Dec 2014 09:51:13 -0500
 Source: pioneers
 Binary: pioneers pioneers-console pioneers-meta-server pioneers-data 
 pioneers-console-data
 Architecture: source amd64 all
 Version: 14.1-3
 Distribution: testing
 Urgency: medium
 Maintainer: Roland Clobus rclo...@rclobus.nl
 Changed-By: Bas Wijnen wij...@debian.org
 Description:
  pioneers   - Settlers of Catan board game
  pioneers-console - Settlers of Catan board game - console parts
  pioneers-console-data - Settlers of Catan board game - data files for 
 console parts
  pioneers-data - Settlers of Catan board game - data files
  pioneers-meta-server - Settlers of Catan board game - meta-server
 Closes: 765319
 Changes:
  pioneers (14.1-3) testing; urgency=medium
  .
[ Roland Clobus ]
* Updated copyright which clarifies the license for the images.
  (closes: #765319)
* Applied license patch from the upstream repository.
* Updated translations, as mentioned in #768176.
 Checksums-Sha1:
  5d83094bf04f77ff92f9c0e83a059cb92dfcebad 2388 pioneers_14.1-3.dsc
  d4659dd2aaa0f232cc7c86ee8edc654e4724534d 92100 pioneers_14.1-3.debian.tar.xz
  e12500bb336c259acb77d3c334b77ba3fe84e932 288742 pioneers_14.1-3_amd64.deb
  ba1035e076e774af13d2412d351270abf0bedd27 173388 
 pioneers-console_14.1-3_amd64.deb
  4504d109527e36da0b71ddcaf914ae3e60d7e782 116344 
 pioneers-meta-server_14.1-3_amd64.deb
  74457347f8aa6cf72988f0eff75c5899510d8692 2699606 pioneers-data_14.1-3_all.deb
  37b06ee45c69a4b932d69f12de6eaa94004dca40 218448 
 pioneers-console-data_14.1-3_all.deb
 Checksums-Sha256:
  e092cc376808561f97606774db1919f059e0788e2cbf30b393a0e4846b6fc8f6 2388 
 pioneers_14.1-3.dsc
  82352af88de49acfe7a84d6340a343009846999a993ba9d2cc9e03d5b9471428 92100 
 pioneers_14.1-3.debian.tar.xz
  0a4f9488f8e68c23569752beb873ae75f190fcf76858290b3b34412e5f19856c 288742 
 pioneers_14.1-3_amd64.deb
  ba677c86af311e269b19c87ae31cfdc41c8c346b01539518aff78ca44980755b 173388 
 pioneers-console_14.1-3_amd64.deb
  708fd5a892b78889b921a2b34e5bd455f953d6959805648e15e7a2036d0fd22c 116344 
 pioneers-meta-server_14.1-3_amd64.deb
  cc5c809d047c4cd3c0d9525f0e50a9d57fe88e8a761c559054e39f5e20891e51 2699606 
 pioneers-data_14.1-3_all.deb

Bug#768176: unblock: pioneers/15.3-1

[Bas Wijnen]

On Fri, Nov 21, 2014 at 06:48:41PM +0100, Niels Thykier wrote:
 Hi Bas,
 
 Any news on preparing a targeted fix for t-p-u?

There are some new and updated translations available since 14.2 was
released as well.  Is it ok to include them in 14.3, or should I leave
them out?

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#768176: unblock: pioneers/15.3-1

[Bas Wijnen]

Hi Niels,

thanks for the ping.  I had hoped to have it done a while ago, but I was
delayed.  I'll do it Soon(tm).

Thanks,
Bas

On Fri, Nov 21, 2014 at 06:48:41PM +0100, Niels Thykier wrote:
 On 2014-11-06 17:01, Jonathan Wiltshire wrote:
  On 2014-11-06 09:45, Bas Wijnen wrote:
  [...]
  
  No, not at that size. Sorry; I realise you're acting with the best
  possible motives, but a full major new upstream is just too invasive at
  this stage.
  
  I'd appreciate a targeted fix for t-p-u though.
  
  Thanks,
  
  
 
 Hi Bas,
 
 Any news on preparing a targeted fix for t-p-u?
 
 ~Niels
 
 


signature.asc
Description: Digital signature

Bug#768176: unblock: pioneers/15.3-1

[Bas Wijnen]

On Wed, Nov 05, 2014 at 10:37:27PM +, Jonathan Wiltshire wrote:
 The debdiff you attached would be fine in principle, but unfortunately the
 version in Jessie is 14.1-2, not 15.2-1.

Oh, right.  I had expected 15.2-1 to migrate before the freeze.

 With
 
  271 files changed, 52206 insertions(+), 33080 deletions(-)

Yes, from 14 to 15 was a big change, including a transition from gtk-2
to gtk-3.  For this reason, I made sure to upload it in time to migrate,
but I didn't expect an RC bug to be filed at the last moment.[1] :-(
Isn't this a reason to allow the migration anyway?  Version 14 really is
quite old already.

 I'd rather have a targetted fix for the documentation bug through tpu
 please. Downgrading the bug is also an option, though I feel slightly
 uncomfortable shipping a package with a license inaccuracy.

Yes, I agree that it's better to have it fixed.  But I want to ask you
to reconsider if 15.2-2 can't enter testing.  After all, I could
reasonably have downgraded the bug before the freeze, which would have
allowed it in.  I didn't do this, because it was about to get fixed
anyway, and I didn't realize that the effect of not doing this would be
that Jessie might release with 14.1.

Thanks,
Bas

[1] Not that I'm blaming anyone; it's good that the bug was filed, but
the timing is unfortunate.


signature.asc
Description: Digital signature

Bug#768176: unblock: pioneers/15.3-1

[Bas Wijnen]

://purl.org/dc/dcmitype/StillImage; /
-  dc:title/dc:title
-  dc:creator
-cc:Agent
-  dc:titleJakub Steiner/dc:title
-/cc:Agent
-  /dc:creator
-  cc:license
-   rdf:resource=http://creativecommons.org/licenses/by-sa/2.5/; /
-  dc:subject
-rdf:Bag
-  rdf:liworkstation/rdf:li
-  rdf:lidesktop/rdf:li
-  rdf:licomputer/rdf:li
-/rdf:Bag
-  /dc:subject
-  dc:sourcehttp://jimmac.musichall.cz/dc:source
-dc:descriptionThe is computer.svg from the Gorilla theme. The contents is modified by Roland Clobus, to make use of the chromakey feature in Pioneers./dc:description/cc:Work
-
-  cc:License
-   rdf:about=http://creativecommons.org/licenses/by-sa/2.5/;cc:permits
- rdf:resource=http://web.resource.org/cc/Reproduction; /cc:permits
- rdf:resource=http://web.resource.org/cc/Distribution; /cc:requires
- rdf:resource=http://web.resource.org/cc/Notice; /cc:requires
- rdf:resource=http://web.resource.org/cc/Attribution; /cc:permits
- rdf:resource=http://web.resource.org/cc/DerivativeWorks; /cc:requires
- rdf:resource=http://web.resource.org/cc/ShareAlike; //cc:License/rdf:RDF
-/metadata
+   id=metadata22510rdf:RDFcc:Work
+   rdf:about=dc:formatimage/svg+xml/dc:formatdc:type
+ rdf:resource=http://purl.org/dc/dcmitype/StillImage; /cc:license
+ rdf:resource=http://creativecommons.org/licenses/by-sa/4.0/; /dc:title /dc:creatorcc:Agentdc:titleRoland Clobus/dc:title/cc:Agent/dc:creatordc:descriptionIcon for the computer player in Pioneers./dc:descriptiondc:contributorcc:Agentdc:titleThe computer is taken from the image 'computer.svg' from the GNOME icon theme 'Gorilla' (https://download.gnome.org/teams/art.gnome.org/themes/icon/ICON-Gorilla.tar.bz2) which is created by Jakub Steiner and relicensed to CC-BY-SA 4.0./dc:title/cc:Agent/dc:contributor/cc:Workcc:License
+   rdf:about=http://creativecommons.org/licenses/by-sa/4.0/;cc:permits
+ rdf:resource=http://creativecommons.org/ns#Reproduction; /cc:permits
+ rdf:resource=http://creativecommons.org/ns#Distribution; /cc:requires
+ rdf:resource=http://creativecommons.org/ns#Notice; /cc:requires
+ rdf:resource=http://creativecommons.org/ns#Attribution; /cc:permits
+ rdf:resource=http://creativecommons.org/ns#DerivativeWorks; /cc:requires
+ rdf:resource=http://creativecommons.org/ns#ShareAlike; //cc:License/rdf:RDF/metadata
 defs
id=defs22508radialGradient
  id=aigrd18
@@ -1495,4 +1472,4 @@
 /g
 
 	
-/svg
\ No newline at end of file
+/svg
diff -urp pioneers-15.2/configure.ac pioneers-15.3/configure.ac
--- pioneers-15.2/configure.ac	2014-05-11 07:12:26.0 -0400
+++ pioneers-15.3/configure.ac	2014-07-07 13:07:35.0 -0400
@@ -20,7 +20,7 @@
 # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 
 AC_PREREQ([2.68])
-AC_INIT([pioneers],[15.2],[pio-deve...@lists.sourceforge.net])
+AC_INIT([pioneers],[15.3],[pio-deve...@lists.sourceforge.net])
 AC_CONFIG_AUX_DIR([.])
 AM_INIT_AUTOMAKE
 AC_CONFIG_SRCDIR([client])
diff -urp pioneers-15.2/debian/changelog pioneers-15.3/debian/changelog
--- pioneers-15.2/debian/changelog	2014-10-13 11:17:04.0 -0400
+++ pioneers-15.3/debian/changelog	2014-10-26 10:30:45.0 -0400
@@ -1,3 +1,12 @@
+pioneers (15.3-1) unstable; urgency=medium
+
+  * New upstream release.
+  * Updated copyright which clarifies the license for the images.
+(closes: #765319)
+  * Applied 'wrap-and-sort' to all debian/* files.
+
+ -- Roland Clobus rclo...@rclobus.nl  Sun, 26 Oct 2014 15:30:00 +0100
+
 pioneers (15.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -urp pioneers-15.2/debian/control pioneers-15.3/debian/control
--- pioneers-15.2/debian/control	2014-10-13 10:22:16.0 -0400
+++ pioneers-15.3/debian/control	2014-10-26 09:40:35.0 -0400
@@ -3,7 +3,23 @@ Section: games
 Priority: optional
 Maintainer: Roland Clobus rclo...@rclobus.nl
 Uploaders: Bas Wijnen wij...@debian.org, Steve Langasek vor...@debian.org
-Build-Depends: debhelper (= 9), libgnome2-dev, scrollkeeper, gnome-common, librsvg2-bin, netpbm, libgtk-3-dev, automake, autoconf, po-debconf, intltool, libtool, libavahi-glib-dev, libavahi-client-dev, gob2, libnotify-dev, xfonts-scalable
+Build-Depends: autoconf,
+   automake,
+   debhelper (= 9),
+   gnome-common,
+   gob2,
+   intltool,
+   libavahi-client-dev,
+   libavahi-glib-dev,
+   libgnome2-dev,
+   libgtk-3-dev,
+   libnotify-dev,
+   librsvg2-bin,
+   libtool,
+   netpbm,
+   po-debconf,
+   scrollkeeper,
+   xfonts-scalable
 Standards-Version: 3.9.6
 Homepage: http://pio.sourceforge.net/
 Vcs-Svn: svn://svn.code.sf.net/p/pio/code/trunk/pioneers
@@ -11,8 +27,12 @@ Vcs-Browser: https

Bug#311188: debconf as a registry

[Bas Wijnen]

 with a line similar to
##DEBHELPER##.  This has the benefit of solving the problem, without
causing the problem of adding lots of duplicate code to the soures.

If blends use pre-seeding, d-i will need some way to make sure that the
blend package (which does the pre-seeding, I would imagine) is
configured before all others.

But Jonas has a point: when using this approach, it means that You
don't really have a Debian Edu system when installing it on a Debian
system (but you do when selecting it during systme install).

If they instead would edit configuration files using public interfaces,
the script libraries will need to be available on the system so the
update-* scripts are as easy as possible to write.

I would personally prefer the pre-seeding option, but regardless it may
be a good idea to use this opportunity to make writing update-* scripts
a trivial excercise.


= Code =

Oh yes, and I have some code ready for feedback.  I haven't written the
script libraries yet (and I want others to write some of them), but I
have written the debhelper module for using them.  I have set up a
mini-dinstall repository where you can get the binary and source
packages:
deb [arch=all,amd64] http://wijnen.dtdns.net/archive unstable main
deb-src http://wijnen.dtdns.net/archive unstable main
(Please ignore problems with the keys; I'm still getting it to work
right.)

The code is derived from dh-autoreconf and it is the first ever perl
program I wrote.  So please don't insult me, but also don't hold back
when you see things that need to be improved. :-)

Thanks,
Bas

On Tue, Nov 26, 2013 at 06:16:19PM -0800, Russ Allbery wrote:
 Bas Wijnen wij...@debian.org writes:
 
  What this means, is that every package which asks debconf questions (and
  stores the answers in a configuration file) will need to:
 
  1. Parse the configuration file, if it exists, and set the values as
  defaults before asking the questions. (in the config script)
  2. Update the values in the configuration file. (in the postinst script)
 
  Currently, many packages only do 2, and that is wrong.
 
 And those packages are all buggy, and whenever you encounter one, please
 do file a bug and get that package fixed.  I've fixed this bug in various
 packages over time, including some of my own.
 
 I agree with Joey that a package's own maintainer scripts should be
 responsible for parsing the package's configuration files.  There are too
 many possible cases that will come up over time, such as a need to migrate
 one value to another, and the package should be an expert in its own
 configuration syntax.
 
 It's the package's responsibility to read debconf-based data back from the
 persistent store and treat that as a maintainer override.  Policy is quite
 explicit about this.
 
 -- 
 Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/
 
 
 -- 
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/874n6ywpvw@windlord.stanford.edu
 


signature.asc
Description: Digital signature

Bug#311188: debconf as a registry

[Bas Wijnen]

On Fri, Oct 17, 2014 at 12:37:27PM +0800, Thomas Goirand wrote:
 On 10/17/2014 04:34 AM, Bas Wijnen wrote:
  So debconf needs to read configuration files, but it doesn't know how to
  parse them.  So it does the only thing it can: it uses its cache.  Which
  means that each and every package that uses debconf must make sure that
  they read the configuration files and update debconf's cache _before_
  running debconf.  And most of them don't do that.
 
 Could you name a few package for which this is the case? Has bugs been
 opened for them?

I have not reported any bugs, because there is no solution that I
consider acceptable yet.  Any package with a config script that does not
include db_set and that writes the result of db_get to a config file (in
postinst) is broken.  But, as I found, strictly speaking they are not
always violating policy.

Getting random packages from apt-cache rdepends debconf shows:

- several packages that use debconf for questions that are only about
  actions that don't need to be (and aren't) stored in config files.
- cxref uses ucf in postinst.  This doesn't violate policy, but does (in
  case of local changes) give the wrong default in the debconf question,
  and an annoying do you want to overwrite local changes? after
  answering the question.  If the default would have been correct, there
  would have been no need for that.
- esmtp starts by asking if you want to overwrite your config and
  refuses to be configured by debconf if you don't.  Also
  policy-compliant, but very unfriendly to users.
- dict does it right.  This costs it more than 20 lines of code in the
  config script.
- dvi2ps does something I don't understand...  It asks questions but
  never runs db_get.  Presumably it pre-seeds some other package?
- ibam depends on debconf but doesn't seem to ask any questions; it
  doesn't even have a config or postinst script.
- gpm does it right, in surprisingly few lines.
- grr does it wrong.

This tiny investigation shows that most of the packages that handle
configuration files are either doing it in a way that is not
user-friendly, or that uses significant code in the config script.  Both
of those cases would benefit from taking that code out of the source (if
it was there) and replacing it with an include statement.

  The above problems are solved by my plan to create a static script
  library, which is included in config scripts at package build time.
  This library would define functions for parsing common config file
  formats, and can be included in config scripts with a line similar to
  ##DEBHELPER##.  This has the benefit of solving the problem, without
  causing the problem of adding lots of duplicate code to the soures.
 
 Then such a library *must* be marked as essential, and installed by
 default, otherwise it would break the install workflow.

No; it's a _static_ library.  It is included in the config script at
package build time.  This means every binary package using it will have
a copy of the code in its maintainerscript.  But the source packages do
not.  A change in the library requires a rebuild of all the packages for
the change to take effect.  That's not ideal, but better than marking it
as essential, or making it part of debconf (which would also work, but
requires Joey Hess to accept it, and so far he refuses to even
acknowledge that there is a problem; even if he would, I find making it
a separate package a more elegant solution).

  Oh yes, and I have some code ready for feedback.  I haven't written the
  script libraries yet (and I want others to write some of them), but I
  have written the debhelper module for using them.  I have set up a
  mini-dinstall repository where you can get the binary and source
  packages:
  deb [arch=all,amd64] http://wijnen.dtdns.net/archive unstable main
  deb-src http://wijnen.dtdns.net/archive unstable main
  (Please ignore problems with the keys; I'm still getting it to work
  right.)
  
  The code is derived from dh-autoreconf and it is the first ever perl
  program I wrote.  So please don't insult me, but also don't hold back
  when you see things that need to be improved. :-)
 
 Ok, you have a repository. But which package should we look into?

Oops, sorry and thanks for the reminder.  It's dh-parseconfig:
http://wijnen.dtdns.net/archive/unstable/{all,source}/dh-parseconfig*

 As for parsing files, I don't think using perl is a great idea.

The perl script only pastes the file into the config script.  The actual
parsing is done by a script in the language that config is written in.
That means there must be an implementation for every language (/bin/sh
being the most important) and every common file type (ini and csv
probably being the most important).

Note that none of those parsing libraries have been written yet.  I'll
probably take some code from pioneers as a starting point.

I intend most libraries to be included in the dh-parseconfig source, but
it is set up in a way that allows other packages

Bug#758116: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)

[Bas Wijnen]

Hi,

On Wed, Oct 15, 2014 at 09:31:36AM +0200, Andreas Tille wrote:
 You belong to a majority if I might conclude from my experience.  I have
 no idea whether I should feel responsible for this but I'm fighting on
 several fronts like the extensive documentation[1] and countless
 talks[2] as well as trying to push newcomers into the topic by
 sponsering their packages[3].

Yes, I noticed.  Thanks for all that work!

 For the moment the way to install Blends is to use the plain Debian
 installer and afterwards install a bunch of metapackages.

Ah, and that's what you want to change now.  That sounds like a very
good idea.

 The lack of a missing installer for all other Blends is a frequently
 criticised problem and I personally think this should be fixed by the
 integration into the official boot cds since this fits to the nature
 of Blends which are a subset of Debian.

Yes, I agree.  For the documentation, I think the main thing that is
missing is how to start and stop; important for every documentation.
Stopping isn't really relevant in this case (but it doesn't hurt to
mention that the metapackage can be uninstalled).  But To use a Blend,
you need to install its metapackage would have clarified it for me.
Once it is possible, it would be very nice if there is an option to do
this during system install could be added to that.

   - Blends are a way to advertise Debian in specific fields of interest
 I personally started from a point where I wanted to reach a status,
 that if somebody wonders what distribution to use for biology and
 medical care the natural answer should be Use Debian  We could
 easily reach this goal for other fields of interest if all our
 dedicated experts we had in Debian would work on this direction in
 their own field.

On occasion, I've needed a single-use system; something that boots up
into an application and that shuts down when that application exits.
(Having the full power of Debian in the background is a nice feature,
but mostly unused.)  For example, for dancing rehearsal I want the
instructors to be able to switch their computer on and have the sound
program start up without any interaction.  It isn't hard to set this up,
but if I want to tell other dancing instructors how to do this, it
requires more steps than I would like.  I've tried making custom live
CDs, with a special package that does these things.

Would this use case also be a reason for creating a personal blend?  Or
even an official one?  What would be the easiest way for people to
install a non-official blend?  Should I create my own installer?  Should
the installer be changed to allow entering a URL (for an external apt
source) before it presents the list of available blends?  (I think this
might be a good idea, but it shouldn't be in there by default; only when
the user selects back on the blend selection menu.  Or perhaps there
can be a button in that menu for opening the dialog, but if it's for
adding any apt repository, the blends dialog is not the right place for
it.)

 There might be additional apt sources but it is not only about apt
 sources.  For instance (as far as I'm informed) all packages in Debian
 Edu are inside Debian and there was just a need to change some
 configuration change of some *other* packages which conflicts with
 Debian policy (I'm pretty sure Jonas will respond in detail to this mail
 - so I save my time here B-)).

So it installs a package which changes configuration of other packages
when it is installed?  That sounds very ugly...  Isn't there a better
way to preconfigure a system?

 I hope I added some more points to this summary.

Yes, thank you.

  Examples of the target audience would be useful.
 
 H.  I had thought / hoped that this is documented in[5].

It is, but I think it's too much text and too far away.  It's good that
it's there, but I think it would be good to have on the first page
people are pointed to (which one is that anyway?  The one in the wiki?)
a one-line explanation that is understandable.  The definition of Pure
Blend on https://wiki.debian.org/DebianPureBlends is a subset of
Debian that is configured to support a particular target group
out-of-the-box.  That does not give me enough information to know if I
should be interested enough to read any further.

Oh, and I have another question; this seems very similar to tasks; how
is it different?

 Enhancements / patches(source is in package source of blends source
 package) are always welcome.

I might write a patch, but knowing myself I probably don't get around to
actually do that.

  I admit I didn't spend a lot of
  time trying to find answers to these questions, but I think it shouldn't
  require a large time investment.
 
 Do you think I should add these answers to the Wiki page with the
 relevant links?

Yes, that would be good.  But it should be as short as possible; less
text is better.  However, currently it is not enough text, I think,
which is of course worse.

 

Bug#694157: Kerkerkruip

[Bas Wijnen]

(CCing the bug to get this discussion linked in it.)

Hi,

Good job identifying those problems Nils!  Also, they are all minor, so
I'm guessing it should be relatively easy to get this package in shape
for Debian.

On Tue, Oct 07, 2014 at 12:28:08PM +0800, Paul Wise wrote:
 Indeed. Manual page is optional I would think.

Policy 12.1: Each program, utility, and function should have an
associated manual page included in the same package, so in that sense
it would not be optional.  On the other hand, not having one wouldn't be
an RC-bug (because it says should, not must).  So you can make a
package without one, but you should make sure it gets one eventually.

But while we're at it, I'll just vent my opinion: no manual page is
better than an empty one.  If you write a manual page that contains
nothing more than Hello, this is a manual page because policy says
there should be one, then you're not helping our users.  The program is
still not documented using a manpage, and the lintian bug for it is
appropriate.  Such manual pages are an example of hiding bugs instead of
fixing them, and we shouldn't be doing that.  (SC #3)

On Tue, Oct 07, 2014 at 05:47:42PM +0200, Nils Dagsson Moskopp wrote:
  if [ -f /usr/games/gargoyle ]; then
  GAR=/usr/games/gargoyle
  else
  GAR=/usr/games/gargoyle-free
  fi
 
 I am not sure, but I think in Debian this would be handled by the
 alternatives https://wiki.debian.org/DebianAlternatives. Is this
 correct or should a Debian package just default to gargoyle-free?

Yes.  If the free version works well, we prefer using that, and we don't
reference the non-free version at all.  If it wouldn't work well, we'd
use the non-free version and that means this package would need to be in
contrib (but that doesn't seem to be the case here).

 First, why the symlinking? It seems to me that the symlink will stay if
 the package is uninstalled and leave a broken symlink in the user's home
 directory.

It is quite normal for programs to create configuration in the home when
they are run, and that will remain after uninstalling (but that will
usually be a copy, not a link).  That isn't a problem.  You are correct
that it might be nicer to do it differently (using the system location
as default if the user location doesn't exist), but that is not
required.

But if config file handling is going to be changed anyway, please
consider using the xdg basedir standard, putting them in ~/.config/.
That will help cleaning the dotfile-mess in ~. :-)  (By the way, xdg
basedir also defines that the system path must be used as a fallback,
just like Nils wants.)

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#754757: timeout during g++

[Bas Wijnen]

On Thu, Sep 25, 2014 at 09:50:10PM +1000, Aníbal Monsalve Salazar wrote:
 Please see Dejan's patch at the end of message #25 of bug #754757:
 
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754757#25

Thanks for the reply.  I've seen that patch, but it turns optimization
off.  As I wrote, I think that is undesirable.  Do you mean to say that
the mips team does not want to have this package compiled with
optimization?  That seems like a bad idea to me, but if that's what you
want, I'll do it.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#754757: timeout during g++

[Bas Wijnen]

Hello Mips-porters,

My package, openmsx, failed to build on mips due to a compiler timeout.
(#754757) Looking at the earlier successful buildd logs, it has always taken
quite long to build.  In the bug it was reported that compilation does succeed
if it is not interrupted, so the compiler doesn't hang.  It can be worked
around by disabling optimization, but my guess is that if even the buildds are
so slow, mips users will need all the optimization they can get.

What do you suggest I do?  My preference would be to get the timeout value
increased, so that it will build as is.  Is that an option?

Thank you,
Bas Wijnen

Ps: Please Cc me on replies, I'm not subscribed.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#759250: [3dprinter-general] Bug#759250: arduino-mighty-1284p: FTBFS - inttypes.h: No such file or directory

[Bas Wijnen]

On Tue, Sep 09, 2014 at 07:06:42PM +0100, Marcos Marado wrote:
 This can be solved by adding avr-libc to the Build-Depends.

Great, thanks for that!  I'll upload that fix in a moment.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#754757: openmsx: FTBFS on mips: timeout during g++

[Bas Wijnen]

Control: notfound -1 0.10.1-2

Hi,

Thanks for the report.  I'm not sure what the problem was, but the new
version (which is identical except for the wxwidgets dependency) built
fine.  I'm guessing it was an issue with the buildd.

I'm closing this bug, because the package is now built by the buildd and
present in unstable.

Thanks,
Bas

On Mon, Jul 14, 2014 at 02:28:48AM +0200, Cyril Brulebois wrote:
 Source: openmsx
 Version: 0.10.1-1
 Severity: serious
 Justification: FTBFS
 
 Hi,
 
 your package no longer builds on mips:
 | Compiling video/scalers/HQ2xScaler.cc...
 | g++ \
 |  -MP -MMD -MF derived/mips-linux-debian/dep/video/scalers/HQ2xScaler.d \
 | -o derived/mips-linux-debian/obj/video/scalers/HQ2xScaler.o  -g 
 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O3-pipe 
 -std=gnu++0x -Wall -Wextra -Wundef -Wunused-macros 
 -Wno-missing-field-initializers -Wzero-as-null-pointer-constant -Isrc 
 -Isrc/cassette -Isrc/commands -Isrc/config -Isrc/console -Isrc/cpu 
 -Isrc/debugger -Isrc/events -Isrc/fdc -Isrc/file -Isrc/ide -Isrc/input 
 -Isrc/laserdisc -Isrc/memory -Isrc/security -Isrc/serial -Isrc/settings 
 -Isrc/sound -Isrc/thread -Isrc/utils -Isrc/video -Isrc/video/ld 
 -Isrc/video/scalers -Isrc/video/v9990 -Iderived/mips-linux-debian/config 
 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL 
 -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/freetype2 -I/usr/include/libpng12 
 -I/usr/include/tcl8.5 -I/usr/include/libxml2 -c 
 src/video/scalers/HQ2xScaler.cc
 | E: Caught signal ‘Terminated’: terminating immediately
 | make[2]: *** [derived/mips-linux-debian/obj/video/scalers/HQ2xScaler.o] 
 Terminated
 | make: *** [build-arch] Terminated
 | make[1]: *** [override_dh_auto_build] Terminated
 
 Full build log:
   
 https://buildd.debian.org/status/fetch.php?pkg=openmsxarch=mipsver=0.10.1-1stamp=1405264499
 
 Mraw,
 KiBi.


signature.asc
Description: Digital signature

Bug#754757: openmsx: FTBFS on mips: timeout during g++

[Bas Wijnen]

Ok, I should read things better.

This bug was in openmsx, not openmsx-catapult.  Ignore my previous
reply.

However, as Manuel writes, I don't see anything mips-specific here.
Build killed with signal TERM after 300 minutes of inactivity sounds
like something is hanging, or otherwise the buildd is very slow (my
guess is inactivity means didn't finish yet).

The latter is an option: previous builds on mips took more than 3 hours
as well.  I wouldn't expect that to almost double with this version, but
is it possible that nothing was wrong and it simply didn't finish in the
300 minutes?  Don't other packages have problems with this limit?

Thanks,
Bas

On Mon, Jul 14, 2014 at 02:28:48AM +0200, Cyril Brulebois wrote:
 Source: openmsx
 Version: 0.10.1-1
 Severity: serious
 Justification: FTBFS
 
 Hi,
 
 your package no longer builds on mips:
 | Compiling video/scalers/HQ2xScaler.cc...
 | g++ \
 |  -MP -MMD -MF derived/mips-linux-debian/dep/video/scalers/HQ2xScaler.d \
 | -o derived/mips-linux-debian/obj/video/scalers/HQ2xScaler.o  -g 
 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O3-pipe 
 -std=gnu++0x -Wall -Wextra -Wundef -Wunused-macros 
 -Wno-missing-field-initializers -Wzero-as-null-pointer-constant -Isrc 
 -Isrc/cassette -Isrc/commands -Isrc/config -Isrc/console -Isrc/cpu 
 -Isrc/debugger -Isrc/events -Isrc/fdc -Isrc/file -Isrc/ide -Isrc/input 
 -Isrc/laserdisc -Isrc/memory -Isrc/security -Isrc/serial -Isrc/settings 
 -Isrc/sound -Isrc/thread -Isrc/utils -Isrc/video -Isrc/video/ld 
 -Isrc/video/scalers -Isrc/video/v9990 -Iderived/mips-linux-debian/config 
 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL 
 -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/freetype2 -I/usr/include/libpng12 
 -I/usr/include/tcl8.5 -I/usr/include/libxml2 -c 
 src/video/scalers/HQ2xScaler.cc
 | E: Caught signal ‘Terminated’: terminating immediately
 | make[2]: *** [derived/mips-linux-debian/obj/video/scalers/HQ2xScaler.o] 
 Terminated
 | make: *** [build-arch] Terminated
 | make[1]: *** [override_dh_auto_build] Terminated
 
 Full build log:
   
 https://buildd.debian.org/status/fetch.php?pkg=openmsxarch=mipsver=0.10.1-1stamp=1405264499
 
 Mraw,
 KiBi.


signature.asc
Description: Digital signature

Bug#750918: Fixed in last upload

[Bas Wijnen]

Yes, I'll upload a new version this week.

Thanks,
Bas

On Sun, Jul 27, 2014 at 03:01:25PM +0200, Manuel Bilderbeek wrote:
 Hi,
 
 On 22-07-14 02:43, Olly Betts wrote:
 On Thu, Jul 10, 2014 at 02:52:35AM +0200, Bas Wijnen wrote:
 I forgot to close this bug in the changelog of the last upload; the new
 upstream release fixes it.
 
 Although the new upstream release apparently adds wx3 support, you
 didn't update the build dependencies in debian/control, so you're still
 building against wxwidgets2.8.
 
 Can one of you fix this please? Would be a pity if it would get
 removed because of this small (but rather crucial ;-) mistake...
 
 -- 
 Grtjs, Manuel
 
 PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
 PPS: Visit my homepage at http://manuel.msxnet.org/


signature.asc
Description: Digital signature

Bug#754340: Unable to run fsck manually when instructed to do so

[Bas Wijnen]

On Sat, Jul 19, 2014 at 10:27:48PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Fri, Jul 18, 2014 at 06:18:28PM +0200, Bas Wijnen wrote:
  When booting into single user mode, things worked as expected.  I was
  unable to remount the fs read-only; the logs you requested are attached.
  (The mei_me messages have always been there, also with sysv init; I
  don't think they are related to the problem.)
 Running fsck on a filesystem mounted in rw mode is a bad idea.

I don't think that's happening.  The kernel commandline specifies ro,
and AFAIK fsck would refuse to run on a read-write filesystem.  The
problem seems to be that when it fails, several services are started,
one of which is mounting the fs read-write.

 So instead of trying to fix things to remount the fs ro, fsck should
 finish and succeed or fail *before* the filesystem is remounted rw.

Yes, that's a good point.  I'm not sure how it worked before; I haven't
had fsck fail a lot.  It might be that it used to spawn a shell on the
read-only fs; that would make sense, especially because the next
recommended action is to run fsck again.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#754340: Unable to run fsck manually when instructed to do so

[Bas Wijnen]

On Sat, Jul 12, 2014 at 12:59:04AM +0200, Michael Biebl wrote:
 Am 12.07.2014 00:34, schrieb Bas Wijnen:
  When fsck failed with this message before, I could do:
  mount / -o remount,ro
  fsck /
  
  Now, and I'm guessing this is a change on the part of systemd, that
  first command (remount read-only) fails with the message that the file
  system is busy.  Having no bootable computer and thus no internet, I was
  unable to figure out what was keeping it busy, and how I was supposed to
  stop it.  This is the information that I think should be part of the
  please run fsck manually-message, because that won't work without it.
 
 I think there is no general answer to that.
 There most likely simply was a process keeping your (root) fs busy.
 So I would have tried stopping one service after another.

I didn't start any processes.  The problem happened in fsck, at which
point no process should be allowed to write to the file system (except
fsck itself).  After failing, it gave me a rescue shell with which I
cannot remount the fs read-only.  I think whatever is keeping it busy
must have been started just before spawning that shell?  Or is it the
shell itself?

I'd be fine with stopping all services, but I'm not familiar with how to
do that either.  If this is the solution, please add that instruction to
the message.  But would services which prevent the disk from being
remounted read-only be started before fsck is finished?  The rescue
shell is part of fsck, I think(?), so nothing should have been started
after it failed.

 Do you have a /var/log/journal/ directory and is this on the root
 directory? Might be that journald kept your fs busy.

No, I don't have that.  However, I just noticed that it is on LVM,
currently running with one physical volume on one disk.  I don't think
that should prevent remounting it read-only though...

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#754340: Unable to run fsck manually when instructed to do so

[Bas Wijnen]

On Thu, Jul 10, 2014 at 06:40:47PM +0200, Michael Biebl wrote:
 Am 10.07.2014 05:03, schrieb Bas Wijnen:
 
  My suggested solution is to document the method for remounting the root
  filesystem read-only (or the method for getting help on the commands that do
  such things) in the error message that says fsck must be run manually, or
  perhaps whenever a shell is spawned so early during boot.  This is 
  essential to
  be able to rescue the system, and since it's changed compared to how it 
  worked
  for decades, you can't assume that everyone knows how to do it.
 
 Could you elaborate what you mean by that? What has changed with systemd
 in that regard?
 It's not like the situation is really different with sysvinit: If fsck
 fails to repair a file system automatically, you'll have to do it manually.

When fsck failed with this message before, I could do:
mount / -o remount,ro
fsck /

Now, and I'm guessing this is a change on the part of systemd, that
first command (remount read-only) fails with the message that the file
system is busy.  Having no bootable computer and thus no internet, I was
unable to figure out what was keeping it busy, and how I was supposed to
stop it.  This is the information that I think should be part of the
please run fsck manually-message, because that won't work without it.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#754340: Unable to run fsck manually when instructed to do so

[Bas Wijnen]

Package: systemd-sysv
Version: 204-14
Severity: critical
Justification: impossible to boot system

(The severity seems inflated, but it didn't fit any of the lower RC levels and
it should be RC IMO.  It is also pretty easy to fix, I hope, so I'd suggest
doing that instead of worrying about the proper severity.)

My system had some serious hard drive problems and because of that remounted my
root file system read-only.  Before investigating anything, I rebooted the
system to see if that would solve anything.

On reboot, fsck was run and it failed, telling me to run it manually.  Then it
provided me a shell.  So far so good.

However, fsck / failed because the filesystem was mounted read-write.  mount /
-o remount,ro failed because the filesystem was busy.  This being my only
computer at that moment, I did not have internet to look up how to do this in
systemd (which I'm guessing has a way to make remounting read-only work, but
I'm not familiar with it).

The only reason I was able to continue, was that after some trying it hit a bad
file and automatically remounted the filesystem read-only.  At that point, I
could run fsck and it would boot again, allowing me to proceed with diagnosing
the problem.

My suggested solution is to document the method for remounting the root
filesystem read-only (or the method for getting help on the commands that do
such things) in the error message that says fsck must be run manually, or
perhaps whenever a shell is spawned so early during boot.  This is essential to
be able to rescue the system, and since it's changed compared to how it worked
for decades, you can't assume that everyone knows how to do it.

This is even more important given systemd's dependency scheme which installs it
on machines where the owner isn't aware of it.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd-sysv depends on:
ii  systemd  204-14

systemd-sysv recommends no packages.

systemd-sysv suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#742704: ImplicitCad in Debian

[Bas Wijnen]

Hi,

On Sat, May 24, 2014 at 07:51:00AM -0700, Christopher Olah wrote:
 Presently, I no longer maintain ImplicitCAD. I've been pretty poor
 about handling this. I put it out temporarily to work on some other
 stuff and ended up getting pulled away. Now I work full time on
 machine learning research. I just don't have the cycles to keep
 another project in my head anymore. :/

Understandable; that's what it looked like.

 In any case, right now there's no upstream for ImplicitCAD. I've
 spoken to a few people who were interested in taking over maintenance,
 but they haven't ended up doing so.
 
 ImplicitCAD, unfortunately, has a bunch of rough corners. Mostly,
 these deal with the computational costs of rendering objects at high
 resolutions and rendering issues at low resolutions.
 
 If you're interested, I'll try and pull together remaining interest in
 ImplicitCAD and see if we can find a new maintainer. It'll need to
 wait until after the NIPS submission deadline, though.

Yes, if you could do that, that would be great!  There's no hurry, it's already
nice to know that something is happening.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#742704: ImplicitCad in Debian

[Bas Wijnen]

Hi,

Someone requested that ImplicitCad be included in Debian.  I'd be the one doing
that, and after checking it out, I must say I'm rather excited about it.  This
has (almost ;-) [1]) all the features that I've been missing in OpenScad.
However, there is a minor issue, which I hope you can help with:

I don't know Haskell.  This means I would make sure the package builds right
and that bug reports are handled (which means fixing the packaging or passing
them to you); Debian's Haskell team has offered to help with the Haskell part,
but they don't want to take over from you.

So what it means is that we need you to continue responding to bug reports and
fixing things when needed.  I really don't know how much work that is; I guess
you know better.

Normally I would just assume that you would do this, but it's been some time
since you last pushed any changes to github, so I'm slightly worried that you
may have abandoned the project.

Can you please let me know the status?

Thanks,
Bas

[1] The one feature which is not in either of them, as far as I could see, is
the 3-D variant of polygon offsetting: growing or shrinking an object.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747535: systemd-fsck?

[Bas Wijnen]

On Mon, May 12, 2014 at 11:54:43AM +0200, Josselin Mouette wrote:
 Systemd is the default init system for jessie, and it should be listed
 as the first alternative.

Can you please explain what is wrong with my reasoning?

A default is only relevant at the time the functionality is first installed.
After that, whatever was installed should stay until the user requests to
change it (or there is a technical reason that it can no longer be installed).
In the case of an init system, installation happens in d-i.

Also, this dependency isn't about an init system.  That's not the functionality
you're depending on.  If it would be, sysv init and upstart should be in the
list of alternatives as well, and the whole dependency could be dropped (since
an init system is Essential).

Instead, you're depending on a very limited part of systemd, and say I want
people to switch as soon as possible, so I don't have to care about bug
reports.  Therefore I sneak systemd on their system when they're not watching
and if they complain, I tell them 'you clicked the I Agree button, so it's your
own fault.'  Or that's what you seem to say anyway.  But I sincerely hope this
is not your attitude, and I welcome you to correct any misunderstanding.

 The fact that an alternative codepath exists for users with specific needs is
 nice for them, but it is not what we should focus our efforts on.

That is reasonable, but forcing anyone who doesn't carefully watch their system
to convert is not the sort of behaviour I expect or want from Debian.  One of
the reasons I like Debian so much is that I believe we, as developers, are
dedicated to allowing our users to do what they want, without forcing things on
them unless there's no other way.  Your responses put a big dent in that
belief.

 As far as GDM is concerned, any bug reported with systemd-shim installed will
 be ignored. The bug script should probably be updated to that effect, BTW.

Please don't do that.  If your priorities are elsewhere, that is obviously
acceptable.  But then tell this to the reporter.  Ignoring bugs is never a good
idea.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747535: systemd-fsck?

[Bas Wijnen]

On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
  In other words: what isn't handled properly?  What should happen, and what 
  does
  happen?
 
 Consider a system which has systemd installed, systemd-sysv *not* installed,
 and systemd used as PID 1 via init=/bin/systemd.  Since systemd-sysv is not
 already installed, systemd-shim | systemd-sysv will pull in systemd-shim
 instead, which will atttempt to supply services that conflict with systemd's.

Sounds like those packages should conflict with each other.  It isn't a reason
to uninstall anything.

More generally, the order of dependencies doesn't matter for what options the
user can choose.  If one of those options is buggy, it shouldn't be an option.

 we want to make sure that only the users who specifically *want* a
 non-default init run one,

I, as a user, did not expect to be moved over to systemd, and given the
discussions about it and the older TC decisions about network manager getting
its dependencies right (to stop forcing all of gnome onto the user's system),
it felt to me as something that was sneaked past me.  I don't want Debian to do
that.  I don't really care about what init system I use, but I do care that I
can trust my system.  When this happened, I was thinking what else are they
going to force onto my system when I'm not watching closely enough?  That's my
default attitude towards any install or upgrade on a proprietary system, and I
most certainly don't want to grow it for Debian users.

 It's easy enough for any user who *does* care to select a different set of
 installed packages.

It's not so much about caring which init system to use.  It's about being in
control over your own computer.  There are many packages that I use and while I
like them being upgraded to new versions, I don't like them to be replaced with
different programs.  Not unless I ask for it.

The exception is when the program I use is no longer supported.  When that
happens, I'll need something else, and using whatever is default on new
installs is a good choice in that case.  But again, as long as other init
systems are supported, I don't want to do anything to continue using them.  Not
even something easy.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747535: systemd pulled in automatically

[Bas Wijnen]

On Sun, May 11, 2014 at 08:20:33PM +0200, Svante Signell wrote:
 Can we please separate the bugs in this thread: This one is about
 dirnmgr not network-manager and gdm3 dragging in systemd as init
 default, #747535.

Speaking of that, I made a suggestion that AFAIK fixes the issue, which isn't
in the bug log yet.  So here it is again:

If the order of the dependencies of libpam-systemd is switched, so it becomes
systemd-shim | systemd-sysv, the result will be:
- If systemd is not installed, systemd-shim will be installed and the original
  init system will continue functioning.
- If systemd is installed, it will satisfy this dependency and systemd-shim
  will not be installed.

Sounds like exactly what I would expect when upgrading random other packages
such as Network Manager.  Systemd is not the next version of my init system,
and switching to it is a switch, not an upgrade.  It shouldn't happen
automatically as if it is an upgrade.  Especially because there is no technical
reason for it at all.

This dependency order is different from the regular order of dependencies,
where the recommended alternative is listed first.  There is a good reason for
this.  The recommended alternative is an init system, which replaces other init
systems.  For other packages, the main question is if this functionality is
not installed on the system yet, which package do we recommend to use for it?
But that question is not applicable here, because there always is an init
system installed.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744733: Confirmed and solved

[Bas Wijnen]

Hi,

On Sat, May 10, 2014 at 07:45:55PM -0400, Chris Knadle wrote:
 I only received notification of the +patch tag being added because your mail 
 went to 744733-submit...@bugs.debian.org, which doesn't email the maintainer. 
  
 If you'd like me to be able to pick up your messages to the BTS, please try 
 to 
 remember to mail me too.  ;-)

Oops, sorry!  I usually use that on bugs in my own packages, and then I don't
really care if the maintainer gets a copy. :-P

 Since I'm not able to reproduce the problem, I think the right thing to do 
 here is to report the issue upstream and have them look over the patch, then 
 add a patch to the package once I get confirmation.

Sounds good.

The code seems to try to not use Xlib at all, but it still uses it for key
symbol name lookup; that's where it actually crashes.  That function is also
marked deprecated in the Xlib code (I'm not familiar with Qt, so I wouldn't
know what that is).  Perhaps a better fix would be to use an alternative for
it; in that case I think no connection to X needs to be made at all (for the
keyboard shortcuts; there still is a connection for the window of course).  But
upstream will know more about that, and what they want.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#742704: [3dprinter-general] Bug#742704: RFP: implicitcad -- Powerful, Open-Source, Programmatic CAD

[Bas Wijnen]

Hi,

On Sun, Mar 30, 2014 at 02:21:39PM +0200, Carlo Stemberger wrote:
 2014-03-29 21:12 GMT+01:00 Joachim Breitner nome...@debian.org:
  How mature and commonly used is this project?
 
 I don't know, but it should be usable.

I wasn't aware of this until this request; the web page describes it as
a substitute for OpenSCAD, which is very usable, but with significant
drawbacks, almost all of which this program claims to solve.  A quick
test indicates that this program functions properly; I intend to start
using it instead of OpenSCAD.

  The Debian Haskell Group will be happy to help someone to maintain
  implicitcad, but there are plenty of non-Haskell-specific maintenance
  tasks, so someone else would have to step up as a maintainer.
 
 Good news: Bas Wijnen is interested in packaging this software.

Yes, but the bad news is that I've never even seen any Haskell code
before, so some help related to packaging of that is very welcome.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#742704: [3dprinter-general] Bug#742704: RFP: implicitcad -- Powerful, Open-Source, Programmatic CAD

[Bas Wijnen]

Hi,

On Sun, Mar 30, 2014 at 08:27:54PM +0200, Joachim Breitner wrote:
  Yes, but the bad news is that I've never even seen any Haskell code
  before, so some help related to packaging of that is very welcome.
 
 glad to hear that.
 
 It seems that implict also provides a Haskell API, to be used
 programmatically. This means that it will be involved in the Haskell ABI
 system and therefore should probably be maintained along the other
 Haskell packages.
 
 So I suggest it should be co-maintained by the DHG together with you: We
 make sure that it builds and that it is rebuilt when its dependencies
 change etc.; you are responsible for all the other maintenance duties
 (replying to bug reports, curating package description and manpages,
 letting us know if a new version should be uploaded etc.). How does that
 sound?

Yes, that sounds good.

 BTW, are you sure this is a healthy project? Last release was in January
 2013, last commit 10 years ago, recent bug reports are not replied to.
 These are typical signs of an abandoned project...

Yes, I noticed this as well.  I'll check to see if I can get contact
with upstream.  Normally I would take over if they don't respond, but
given that I don't know the language, I don't think that's a good idea
in this case.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#742704: [3dprinter-general] Bug#742704: RFP: implicitcad -- Powerful, Open-Source, Programmatic CAD

[Bas Wijnen]

Control: retitle -1 ITP: implicitcad -- Powerful, Open-Source, Programmatic CAD
Control: owner: -1 3dprinter-gene...@lists.alioth.debian.org

This looks awesome!  It looks like it fixes all the problems I've been
having with OpenSCAD.  I very much want this in Debian, but if anyone
wants to beat me to making a package, go for it. :-)

Thanks,
Bas

On Wed, Mar 26, 2014 at 03:06:12PM +0100, Carlo Stemberger wrote:
 Package: wnpp
 Severity: wishlist
 
 * Package name: implicitcad
   Version : 0.0.3
   Upstream Author : Christopher Olah ch...@colah.ca
 * URL : http://www.implicitcad.org/
 * License : GPL
   Programming Lang: Haskell
   Description : Powerful, Open-Source, Programmatic CAD
 
 ImplicitCAD is a programmatic CAD program, implemented in haskell. Unlike
 traditional CAD programs, programmatic CAD programs use text descriptions of
 objects, as in programming. Concepts like variables, control structures and
 abstraction are used, just as in programming. This provides a number of
 advantages:
 
 * Objects can abstracted and reused
 * Repetitive tasks can be automated
 * Objects can be designed parametrically
 * The usual tools for software development (like version control) can be used
 
 The traditional example of programmatic CAD is OpenSCAD.
 
 Generally, objects in programmatic CAD are built with Constructive Solid
 Geometry or CSG. Unions, intersections and differences of simpler shapes
 slowly build the object. ImplicitCAD supports all this and much more! For
 example, it provides rounded unions so that one can have smooth interfaces
 between objects.
 
 It also directly provides GCode generation, and has a parser for OpenSCAD to
 make it easier for people to transition.
 
 ___
 3dprinter-general mailing list
 3dprinter-gene...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/3dprinter-general


signature.asc
Description: Digital signature

Bug#718434: fixed in ca-certificates 20140223

[Bas Wijnen]

On Mon, Mar 24, 2014 at 03:16:51PM +0100, Christoph Anton Mitterer wrote:
 I just agreed to Ivan's opinion... right now many people say it's
 better to do crypto, even if it's anonymous and you have no idea who
 you're talking to... their reason is usually on of
 - the attacker may miss the point where the communication starts and
 therefore the point where he could do an MitM
 - even if the attacker does MitM, he would need more computing power
 (and therefore money) to decrypt everything.

No, the point is that an attacker is detectable.  Do you think the NSA
does MITM attacks on all connections?  I seriously thought that they
might.  So when I traveled from the US to the Netherlands, I took a copy
of the key of my machine in the Netherlands, as seen from my browser in
the US.  I compared that copy when I was in the Netherlands, and it
matched.

If the NSA starts doing this, someone will catch them.  That will be big
news and everyone will start checking their keys.  And if none of them
match, things will be fixed.  As long as they don't do it, checks like
the one I did will confirm that nothing is wrong.

Well, not exactly, of course.  It is still very likely that they are
trying to (and also that they succeeded to) put back doors into the
encryption protocols, or at least their implementations.

 But that's just the point...  When an attacker sits on the line
 between A and B,.. and they don't encrypt... than obviously he can
 read/tamper with everything.

Depending on what you mean by sitting on the line.  They can always
read, but to tamper they need to sit in the line, not just on it.
They have to make sure the original packets don't reach their
destination.  I take it that's what you mean.

(Note that this is a much smaller group of machines; for example, I can
read all traffic on the subnet of my block of houses, but I can't
effectively tamper with it.)

 If the attacker sits on the line between Alice and Bob (which he
 apparently does, since he was able to read the unencrypted stuff)... and
 if Alice and Bob don't verify their identities... then he can to MitM...
 just as you explained it above.

But if they start to doubt, they can check if they have been attacked,
by comparing their keys through an independent channel.  There will have
been a small window where their communication was intercepted, but
that's still much better than having everything always public.

 So I'd say... anonymous encryption does not really help that much...
 at least not against someone who constantly sits on the line and
 watches all traffic (which NSAfriends surely do) It gives rather a
 wrong sense of security.

Anonymous encryption is better than no encryption.  And it gives actual
security.  Certainly against people who are only listening (of which
there are many), and (with a small delay where you might send sensitive
data to the NSA) also against MITM attacks, because some people will
check some keys every now and then.  If any of them is found to be under
attack, more checks will be done; if many of those will fail, all hell
will break loose.

And the NSA is not stupid.  They know this.  So they aren't going to
try.  Instead, they are claiming that it doesn't really help anything
and it only gives a false sense of security, to convince people that
not encrypting is better than encrypting with unchecked keys.  Sure they
like it when the entire internet is unencrypted, it makes their work
easier.  It does not however provide any benefit to us or our users.

  A certificate authority does not provide the encryption keys.  It only
  puts signatures on them.  Without any CA, you can still encrypt if you
  have the target's public key.
 Well sure.. but what do you want to tell us? Of course you can.. but
 nobody usually manually trusts X.509 certs (i.e. non-CA-certs)

You're claiming that having an evil CA in the list means that my
communication is in danger of being eavesdropped.  I'm saying that this
is nonsense, because:

  An evil CA cannot read your traffic (unless they are in
  the path of your communication).

You are saying that the NSA has control over evil CAs, and also is in
the path of communication.  So they can eavesdrop.  Technically this is
true.  But there are two things to consider:

1. Due to the fact that they would be detected if they tried this on a
   large scale, they won't actually do this.
2. Your conclusion that because the NSA can eavesdrop, we should allow
   everyone else too (by not encrypting at all) is beyond ridiculous.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#718434: fixed in ca-certificates 20140223

[Bas Wijnen]

On Tue, Mar 25, 2014 at 11:23:02PM +0100, Christoph Anton Mitterer wrote:
 On Tue, 2014-03-25 at 18:58 +0100, Bas Wijnen wrote:
  No, the point is that an attacker is detectable.
 Why should he be?

Because I can store the certificate, go somewhere else, and check if my
stored version is identical to the version that I receive from there.

In that sense, self-signed certificates are actually more safe; they
produce a new warning when the certificate changes.


This is about let's encrypt every single connection on the web.  We're
talking about people like me.  I have a website with a CAcert
certificate.  I can check that my key as it is stored on my server (in
my house) is the same key that I get when I visit the site from the US
(if there's one place where the NSA should have no problem getting
access it's there).

 Well if one has to assume that they sit in the big internet exchange
 points... this already gives them a lot...

If they are in the building and can tap the wire, but not modify the
packets, then an encrypted link is unreadable for them.

  But if they start to doubt, they can check if they have been attacked,
  by comparing their keys through an independent channel.
 Well but that simply doesn't happen, does it?

I recently did it, I'm guessing I'm not the only one.

 So people must have your doubts by know, but nothing really changes.

I'm talking about posts on Slashdot from people saying I checked my
certificate from home and from the US, and they were different,
therefore 'someone is doing something naughty'.  I haven't seen any of
those.

  to convince people that not encrypting is better than encrypting
  with unchecked keys.
 Well that's not what I said... I rather say the later is simply not
 enough.

Fair enough, you didn't say it was better, but you did disagree with
it's better to do crypto, even if it's anonymous and you have no idea
who you're talking to.

... which leads to the conclusion that it's not better to do crypto in
that situation (which isn't the same as better not to, but close
enough, I would think).

 Well first... why is an attack only a problem if it's done at large
 scale?

Because the data we're talking about is approximately the definition of
uninteresting.  It's all the connections to people's private websites,
personal chat sessions, that sort of stuff.  The only way it is useful
for them, is when they gather huge amounts of it and filter it.

 If the NSA does this only for the Snowdens, Applebaums, etc. ... then
 this is enough for them...

In that case you can stop worrying.  The NSA has billions of dollars at
their disposal.  If they really want some information, they will get it.
There is no way we can prevent that, and we shouldn't waste our time on
trying.

Expect the NSA to always be able to read everything.  It may not always
be true, but who cares?  We don't have the power to stop them.

What remains, is a mostly unencrypted web.  We should fix that.  The NSA
isn't the only one who wants to listen, and even if we can't stop the
NSA, we can still stop most others.  The only way to do that, is by
making encryption easy and functional.  Dropping CAs from the list is
counterproductive.  Especially with CAcert, which I expect to be
disproportionally popular with Debian users.

 I'm not saying that CAcert is secure or trustworthy (actually I wouldn't
 use it for my own security critical services - neither would I use any
 other CA not under my personal control)... but it's not less secure than
 any other CA we ship.

Unless you are really large (like Google or Microsoft), a CA under your
personal control is useless.  The point of a CA is that your visitors
get the root key through an independent trusted channel.  If you need to
send your personal root key to all your visitors, you can as well send
them the key you use for encryption.

 And right now, the only thing we do is taking away the user's
 possibility to retrieve root certificates in a secure way.
 
 We should not remove certs... we should add more, like CERN CA, TACAR
 TERENA, etc.

On that we agree, then. :-)

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#718434: fixed in ca-certificates 20140223

[Bas Wijnen]

On Mon, Mar 17, 2014 at 09:54:47AM +0100, Thijs Kinkhorst wrote:
 On Mon, March 17, 2014 03:06, Bas Wijnen wrote:
  The other option is to get a
  certificate, which costs money. Except with CAcert.
 
 This is not true. There are several CA services recognised by the major
 browsers and thus the ca-certifcates package which offer free as in money
 SSL certificates; and there are several more that offer them at very low
 prices.

I looked, but didn't find them.  I believe you that they exist, but
there are others which shout they are free, but when you go to them that
doesn't seem to be true.  When I found CAcert, I gave up on those
misleading companies.

Given the situation (described in much more detail than I was aware of
by IanG), I think CAcert is by far the best certificate authority there
is, especially for an organization such as Debian.

I would drop all other CAs from the list before dropping CAcert.

On Sun, Mar 23, 2014 at 02:50:04AM +0100, Christoph Anton Mitterer wrote:
 On Sat, 2014-03-22 at 13:42 +, Ivan Shmakov wrote:
  First of all, accepting some
  “random” certificates may give the users some false sense of
  security.
 
 This is true, and also a reason why I'm really convinced of the argument
 encrypt/sign,... even if it's not trusted...

I don't understand what you're saying here.

 Especially the argument that the only problem one has are MitM attacks
 sounds kinda stupid since everyone that can intercept your traffic
 (which an attacker would need to be able anyway - even if all was
 clear-text)... can also easily do MitM attacks...

No.  The basis of a man in the middle attack is that both parties talk
to you and think you are the other end of the communication.  They
encrypt their traffic against YOUR public key, instead of the actual
recipient's key.  If they encrypt it with the right key, you can see the
encrypted traffic but not read it.  You could modify the packets, but
the only effect would be that they would fail to decrypt.

A certificate authority does not provide the encryption keys.  It only
puts signatures on them.  Without any CA, you can still encrypt if you
have the target's public key.  The problem that a CA tries to solve is
getting the public key that actually belongs to the computer I want to
connect to.  An evil CA cannot read your traffic (unless they are in
the path of your communication).  They can only convince users that some
key is really yours.  And that is only useful if they are in the path of
communication, so they can alter the packets.

So yes, MitM attacks are the only problem that CAs are defending
against, and they are also the only thing to consider when trusting a
CA.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#616689: jessie still not working

[Bas Wijnen]

I'm running unstable, and have been affected by this bug for a few weeks
now, which is really annoying.  After reading this bug report, I decided
to set the -x flag on /usr/share/initramfs-tools/scripts/local-top/lvm2,
the problem was quickly found: this script refuses any path which does
not start with /dev/mapper/.  The root device is given as
/dev/disk/by-uuid/*, so it is not activated.

Simple workaround: change the grub commandline from root=UUID=* to
root=/dev/mapper/vg-root (fill in your volume group and root logical
volume name).  Then it will activate and boot normally.

I expected that this should be done by changing /etc/fstab and running
update-grub, but grub will put UUID values in /boot/grub/grub.conf
anyway.  So it must be done in /boot/grub/grub.conf, and repeated every
time update-grub is run (which isn't ideal, but a lot better than typing
commands every time the system boots).

I'm guessing this bug was triggered by a change in grub to always write
UUIDs to its config.  Still, it should be fixed by changing the
initramfs-tools script to make it allow the UUID-based path.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#718434: fixed in ca-certificates 20140223

[Bas Wijnen]

On Thu, Mar 13, 2014 at 01:03:23PM +, Michael Shuler wrote:
* No longer ship cacert.org certificates.  Closes: #718434, LP: #1258286

I was not aware of this bug until my browser started refusing my cacert
certificate at the latest upgrade.  I see there has been a long
discussion about this, and I've read a significant part of it.  I
understand the viewpoints, but have something to add which is currently
missing from the discussion IMO:

As you may be aware, Poul-Henning Kamp has been talking about browser
security in this year's edition of FOSDEM[1][2].  One of the things he
specifically mentioned was that it would be great if all web traffic was
encrypted.  And really, self-signed certificates are good enough!  MITM
attacks may happen, but will be extremely rare; the choice of encrypting
vs not encrypting should be an easy one.

However, we all know how all browsers scare everyone but the most
persistent away from visiting a site which uses an untrusted
certificate.  Because of this, most of the web is still unencrypted: who
wants to scare their users away?  The other option is to get a
certificate, which costs money.  Except with CAcert.

Because of this, CAcert is the best way to push websites in the
direction of encrypting all websites.  Sure it'd be better if Mozilla
would accept them.  It would be even better if Mozilla would stop
screaming at the user when a self-signed certificate is encountered.
But we, as Debian, don't have control over Mozilla.  We can ask them,
and they might listen.  In the mean time, we can do our own part in
making the web better.

Yes, I understand that CAcert's code and procedures are less secure than
they should be.  I don't care.  First priority is to get the web
encrypted.  Trusted certificates is secondary.  As long as browsers
don't reasonably allow self-signed certificates, I think we should
accept any and all certificates as trustworthy; certainly the ones from
a community-driven CA.  (As noted, the current selection doesn't seem to
filter for security anyway.)

Thanks,
Bas

[1] https://fosdem.org/2014/schedule/event/nsa_operation_orchestra/
[2] 
http://video.fosdem.org/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm


signature.asc
Description: Digital signature

Bug#298138: ssh: PermitRootLogin should defaul to no

[Bas Wijnen]

Control: unarchive -1

Resending to get it in the BTS.

- Forwarded message from Bas Wijnen wij...@debian.org -

Date: Mon, 17 Mar 2014 03:43:01 +0100
From: Bas Wijnen wij...@debian.org
To: Colin Watson cjwat...@debian.org
Cc: Thijs Kinkhorst k...@squirrelmail.org, 298...@bugs.debian.org, Matthew 
Vernon matt...@sel.cam.ac.uk
Subject: Re: Bug#298138: ssh: PermitRootLogin should defaul to no

On Sat, Mar 05, 2005 at 02:20:41PM +, Colin Watson wrote:
 On Sat, Mar 05, 2005 at 02:26:45PM +0100, Thijs Kinkhorst wrote:
  On Sat, March 5, 2005 02:41, Matthew Vernon said:
   Please read README.Debian before submitting your bug reports - this is
   good practice for any package, not just ssh.
  
  You're absolutely correct, I should have done that, sorry.

You're very polite, which is very nice especially compared to how users
are treated for this issue.  But this is not correct; you should check
reported bugs (which may be marked WONTFIX) before reporting a bug.
Reading README.Debian is not at all a requirement.  That's where you
expect to find specifics about using the Debian package (particularly
how it is different from upstream), not arrogant messages preemptively
telling you to not bother the maintainer.

  If you permit, I'd like to ask a question about this. To me, the text in
  README.Debian is not clear on the following point: how is allowing root
  login just as secure as not allowing that?
 
 Note that OpenSSH upstream ship with PermitRootLogin switched on as
 well. This isn't a Debian-specific change.

It's a good idea to fix it there as well then.  However, Debian doesn't
just copy what upstream is doing; if we know better, we do it better.

  You write:
  If you set it to no, then they must compromise a normal user
  account. In the vast majority of cases, this does not give added
  security; remember that any account you su to root from is equivalent
  to root - compromising this account gives an attacker access to root
  easily.
  
  As I understand this, the hacker has to do the following to gain superuser
  privileges.
  
  PRL-on:
  1. Know the root password.
  PRL-off:
  1. Compromise a normal user account (one that allows su-ing).
  2. Know the root password or a local root exploit.
 
 Much easier: compromise a normal user account, install a keylogger, and
 wait for that user to su to root. As long as you have an account which
 is privileged in this way, you should treat it with the same care as you
 treat your root account, since it is ultimately equivalent to root with
 only a little work.

So you're saying there is a different attack possible which is still
more work than simply knowing the root password.  I don't see how this
leads to the conclusion that PermitRootLogin set to yes is not less
secure.

 PermitRootLogin no often buys only the illusion of security, and
 we'd rather people thought about the issues a little more carefully
 than that.

Then you better well tell them about it in a way that they cannot
possibly miss, before they even install the package.  Real-life example:
I set up a single-user machine and used a totally insecure root
password.  I'm not interested in protecting the system, only in
protecting my own account[1].  My thought was: they'll need to get into
my account before they get to root, and if they have my account I don't
care about root anymore.  But of course I did not expect the ssh package
to be so insecure as to let people remotely log in as root.  Because who
would ever want that?  And who would ever expect it to be the default?

I was lucky that I had a break-in soon, before I had any important data
on the machine, and by a very stupid person, so I instantly detected it.
You can't expect everyone to be that lucky.  You're putting our users at
risk for no good reason.  Please stop.

[1] http://xkcd.com/1200/

 Providing the illusion of security without
 providing real security is dangerous, since (in this case) it encourages
 people to use effectively root-equivalent user accounts as if they were
 unprivileged: they must have turned PermitRootLogin off for a reason.

Please explain how anything gets more secure from allowing people to log
in remotely as root.

Your argument that root is an easy target from a user account doesn't in
any way mean that root should be made a target through other means as
well.  All my data is in my user account.  You've added an attack vector
by opening up a second login which has access to it.  That would be sort
of acceptable if I would expect it.  But I have no reason to, and
therefore you shouldn't do it.

Please set PermitRootLogin to false by default.

Thanks,
Bas



- End forwarded message -


signature.asc
Description: Digital signature

Bug#740297: crashes on startup

[Bas Wijnen]

Package: pcb2gcode
Version: 1.1.4-git20110915-1
Severity: grave
Tags: upstream patch
Justification: makes package unusable

Pcb2gcode crashes when starting.  In Ubuntu, there is a patch to fix this:
http://patches.ubuntu.com/p/pcb2gcode/pcb2gcode_1.1.4-git20110915-1ubuntu3.patch

(This patch contains some junk, but the actual fix (in options.cpp) is easy to
filter out.)

Thanks,
Bas

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pcb2gcode depends on:
ii  gerbv   2.6.0-1
ii  libatk1.0-0 2.10.0-2
ii  libboost-program-options1.54.0  1.54.0-4
ii  libc6   2.18-3
ii  libcairo2   1.12.16-2
ii  libcairomm-1.0-11.10.0-1
ii  libfontconfig1  2.11.0-5
ii  libfreetype62.5.2-1
ii  libgcc1 1:4.8.2-16
ii  libgdk-pixbuf2.0-0  2.30.5-1
ii  libglib2.0-02.38.2-5
ii  libglibmm-2.4-1c2a  2.36.2-1
ii  libgtk2.0-0 2.24.22-1
ii  libgtkmm-2.4-1c2a   1:2.24.4-1
ii  libpango-1.0-0  1.36.0-1+b1
ii  libpangocairo-1.0-0 1.36.0-1+b1
ii  libpangoft2-1.0-0   1.36.0-1+b1
ii  libpangomm-1.4-12.34.0-1
ii  libsigc++-2.0-0c2a  2.2.11-3
ii  libstdc++6  4.8.2-16

pcb2gcode recommends no packages.

pcb2gcode suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#736180: Bug #736180: severity update

[Bas Wijnen]

Control: severity -1 serious

On Thu, Feb 13, 2014 at 03:35:24PM -0300, mecha wrote:
 I believe serious might be the actual severity for this bug, since
 the package becomes unusable as it is for schematic to PCB
 footprints association, as well for manual footprints placement.

I agree; repeating it because you didn't use the pseudo-header
correctly.

But I'm not the maintainer; could there be a reply about when this is
likely to be fixed please?

For now the workaround seems to be to downgrade to wheezy, which is what
I shall do.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#601455: marked as done (can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo)

[Bas Wijnen]

 Date: Mon, 9 Dec 2013 15:27:11 +0100
 From: Holger Levsen hol...@layer-acht.org
 To: 601455-d...@bugs.debian.org
 Subject: thats the way these init scripts are, use something else if you care 
 about this
 
 I've decided to close this bug, as this mis-feature / bug is actually a 
 main 
 characteristic of system V init scripts: they can be+do anything, including 
 showing the behaviour which led to this bug report.

That doesn't make it an unreasonable expectation.  I've seen the same
issue as well, and it always annoyed me.  Why shouldn't we write this in
policy?  It must be possible to stop a service with its init script,
even if the package is disabled by its configuration files.

Your argument is a shell script can do this, therefore it is not a bug
if it does, which is nonsense.  A shell script can also remove all
files in /bin, and it definitely is a critical bug if it does.

 If you don't like this, use a modern init system.

Yes, because that's non-controversial and all.  I'll wait until the war
is over to switch to whoever won.  That doesn't mean any actual buggy
behavior on my system is to be ignored as use a modern init system.  I
am running the newest version of the packages in Debian; this is a
configuration we should support.

When Debian no longer supports sysv init, a reply like this is
acceptable.  Currently it is not.

Note that I would consider it acceptable to not fix these bugs until a
decision about init systems has been made.  But they are still real
bugs, even if we decide not to fix them.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#731813: RM: pvcam-dkms -- ROM; No access to hardware anymore

[Bas Wijnen]

Package: ftp.debian.org
Severity: normal

pvcam-dkms currently fails to build with newer kernels.  I no longer have
access to the hardware, and I find it highly unlikely that anyone is going to
adopt it.  Aside from that, as #693663 explains, the code is very buggy, and
requires a lot of work to make clean, which I don't forsee anyone doing.

libpvcam (from non-free) depends on this package, and should be removed as
well; it is an interface to this kernel module, and useless without it.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729146: ITP: cura-engine -- commandline slicer program for 3-D printers

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen wij...@debian.org

* Package name: cura-engine
  Version : 13.06~git20131109
  Upstream Author : Daid daid...@gmail.com
* URL : https://github.com/Ultimaker/CuraEngine
* License : AGPL
  Programming Lang: C++
  Description : commandline slicer program for 3-D printers

3-D printers need a toolpath for printing, while what is usually distributed is
a 3-D model.  A slicer programs converts a model to a toolpath, with user
defined settings for options such as infill density and printing speed.

This slicer is the commandline backend of Cura.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org