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

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#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 . 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#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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140529022456.gv10...@fmf.nl

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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140524000346.gn10...@fmf.nl

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]

Hi,

On Sun, Mar 30, 2014 at 02:21:39PM +0200, Carlo Stemberger wrote:
> 2014-03-29 21:12 GMT+01:00 Joachim Breitner :
> > 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]

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 
> * 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#729146: ITP: cura-engine -- commandline slicer program for 3-D printers

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: cura-engine
  Version : 13.06~git20131109
  Upstream Author : Daid 
* 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131109152643.11482.9862.report...@heights-197-52.resnet.mtu.edu

Bug#728542: ITP: libpolyclipping -- polygon clipping, polygon offsetting and polyline offsetting library

[Bas Wijnen]

Hi,

On Sun, Nov 03, 2013 at 11:19:44PM +0100, Nicolas Dandrimont wrote:
> Does this have anything to do with Slic3r packaging?

No, this is a prerequisite for the Cura engine.  I thought Slic3r used a
different library, but appearantly I was wrong?  In that case I will need to
have a look at the perl package, because I suppose they have the same source
(I was planning to ignore the perl part and only package the c++ source from
upstream; it contains implementations in many other languages as well).

I can't see it in the repository though; is it already in there?

> While debugging an issue with Slic3r on 32-bit archs, I tried upgrading to
> clipper 6.0.0 and Slic3r's test suite was broken.

I have a 6.0.0 package just about ready to upload now; it might still take a
while before I do, though, because I added a pkgconfig file and upstream said
he wanted to include it, so I'll probably let that happen first.

> However, upstream intends to move to clipper 6.0.0 just after its next
> release, so we might want to wait it out a bit.

Good idea, I think.  When we need it, we can just add a perl binary package
from my source package (some help with packaging would be welcome; I don't
know any perl).

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131104174752.gc24...@fmf.nl

Bug#728542: ITP: libpolyclipping -- polygon clipping, polygon offsetting and polyline offsetting library

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: libpolyclipping
  Version : 6.0.0
  Upstream Author : Angus Johnson <http://sourceforge.net/projects/polyclipping>
* URL : http://sourceforge.net/projects/polyclipping
* License : GPL, BSD, MIT, Boost
  Programming Lang: C++
  Description : polygon clipping, polygon offsetting and polyline 
offsetting library

The Clipper library performs polygon clipping, polygon offsetting and polyline
offsetting. All four boolean clipping operations are supported - intersection,
union, difference and exclusive-or. Also, there are no restrictions on the
types of polygons that can be clipped - they can have holes, be
self-intersecting, have coincident edges etc.

It is written in several languages; only the C++ version is part of this
package.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131102182202.9372.31793.report...@heights-197-52.resnet.mtu.edu

Bug#689636: Bug#724631: ITP: slic3r -- Tool to convert a digital 3D model into printing instructions for 3D printer

[Bas Wijnen]

Control: owner 689636 Zlatan Todoric 
Control: merge 689636 -1

On Thu, Sep 26, 2013 at 02:21:00AM +0200, Zlatan Todoric wrote:
> * Package name: slic3r
>   Programming Lang: C++, Perl
>   Description : Tool to convert a digital 3D model into printing
> instructions for 3D printer

I filed an ITP for this some time ago (#689636).  The problem was that not all
the dependencies were in Debian, so I asked the Perl team to package them.
They have been slowly doing this, and by now I believe all of them are packged.

I have however not yet found the time to prepare a package.  I'm happy that you
want to create one, so I'm merging the ITPs, and set you to own it.

With a few people we have been talking about setting up a 3-D printer packages
team.  I've set up an Alioth project
(https://alioth.debian.org/projects/3dprinter/) for it, which is currently
still empty.  Would you consider maintaining the package as part of that team?
If so, please give me your alioth login and I'll grant you access, so you can
add your packaging to that.

Also, once you have a package I'm happy to sponsor it for you, if you need
that.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130926191341.ga16...@fmf.nl

Bug#706656: Progress

[Bas Wijnen]

On Thu, Sep 26, 2013 at 03:23:53AM +0200, Aureus wrote:
> I was just going to ITP and saw that it already is, so I am just wondering
> how is this packaging progressing? :)

I'm currently discussing with the libclipper maintainer about his naming (in
particular the SONAME) before making a package of that.  This is a requirement
for cura.  Once that is in place, cura itself is trivial.

You're welcome to comaintain it if you like.

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130926191631.gb16...@fmf.nl

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

[Bas Wijnen]

Update: I'm having a discussion with upstream, and hopefully we will
soon have a package in the archive.  I was waiting for the new release,
which has now happened; now we're looking at the clipperlib that is
used, which seems to be different from the one in Debian.

Thanks,
Bas

On Sat, Jul 27, 2013 at 08:02:36AM -0700, Tony Godshall wrote:
> +1
> 
> On May 2, 2013 6:18 PM, "Bas Wijnen"  wrote:
> >
> > Package: wnpp
> > Severity: wishlist
> > Owner: Bas Wijnen 
> >
> > * Package name: cura
> >   Version : 13.04~git20130502-1
> >   Upstream Author : David Braam (daid...@gmail.com)
> > * URL : http://daid.github.io/Cura/
> > * License : AGPL-3+
> >   Programming Lang: Python
> >   Description : Controller for 3D printers
> >
> > Cura is a project which aims to be an single software
> > solution for 3D printing. While it is developed to be used
> > with the Ultimaker 3D printer, it can be used with other
> > RepRap based designs.
> >
> > Cura helps you to setup an Ultimaker
> > Cura shows your 3D model, allows for scaling/positioning
> > Cura can slice the model to 3D GCode
> > Cura can send this GCode to the 3D printer for printing
> > And more...
> >
> >
> > --
> > 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/20130503011533.13027.38521.report...@heights-197-63.mtu.edu
> >


signature.asc
Description: Digital signature

Bug#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers

[Bas Wijnen]

On Sun, Jul 07, 2013 at 09:14:50AM +0200, Nicolas Dandrimont wrote:
> My login is `dandrimont-guest'. Thanks,
On Sun, Jul 07, 2013 at 12:23:42PM +0200, Andrea Colangelo wrote:
> Although I don't current maintain 3D-printing-related packages, I am very
> interested in the topic, and willing to give an help in the team (plus acting
> as a liaison with Ubuntu). Mind adding me to the team as well? Login is
> warp10-guest.

You're very welcome.  I've added both of you as administrators.  I've
also given add DDs commit access; they certainly won't abuse it; I doubt
they'll use it at all. ;-)

I haven't set up anything in the repository yet.  Feel free to start it.
We will certainly need a directory for each package; should we separate
them subdirectories by type (interface, slicer, firmware, other)?

It's probably a good idea to start a mailinglist there and continue this
discussion on it.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers

[Bas Wijnen]

On Sat, Jul 06, 2013 at 11:48:08PM +0200, Nicolas Dandrimont wrote:
> On a related note, I was thinking of putting a team together to join forces on
> the 3d-printing related packaging effort (probably by creating an alioth
> project, which would give us a central place to put our code repositories, and
> mailing lists). Would you be interested in creating such a structure?

I've just created an alioth project; if you give me your alioth login,
I'll add you as an administrator.

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers

[Bas Wijnen]

On Sat, Jul 06, 2013 at 11:48:08PM +0200, Nicolas Dandrimont wrote:
> The dependencies for version 0.9.10b should be good to go in sid,
> thanks to the debian-perl team. I updated and/or packaged the last few
> modules that needed updating, and I had Slic3r run on my machine
> without using CPAN.

Cool, thanks for checking. :-)

> Slic3r's git repo grew a few extra dependencies today (with a few branches
> getting merged into master), I'll take a look (it'll be easier if there's a
> preliminary package).
> 
> I'd be glad to comaintain Slic3r if you need help.

Yes, that would be very welcome.  I don't know any perl, so while I can
understand most of it, I can't really fix anything if I'd need to.

> On a related note, I was thinking of putting a team together to join
> forces on the 3d-printing related packaging effort (probably by
> creating an alioth project, which would give us a central place to put
> our code repositories, and mailing lists). Would you be interested in
> creating such a structure?

Yes, that sounds very useful.  I currenly have two packages which would
belong there: arduino-mighty-1284p, for supporting the melzi board, and
the new Cura (which will actually be two packages, -engine and -gui).

I previously looked at Repsnapper, but someone else eventually packaged
it; it should be part of this as well, I think.

I've also written a print server and am in the process of writing new
firmware.  Once done, they should be packaged as well, of course.

As for the structure, I'd prefer to use git for our repositories.  Is
that ok with you?

Thanks,
Bas


signature.asc
Description: Digital signature

Bug#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers

[Bas Wijnen]

Hi,

There were several perl modules required for making a Debian package.
I'm not confident that I can properly maintain those, so I asked the
Perl team.  They have slowly added them.  I'm not sure if all of them
are packaged now; I should check again.

Thanks for the reminder,
Bas

On Thu, Jul 04, 2013 at 09:34:24AM +0200, Andrea Colangelo wrote:
> Hi Bas Wijnen,
> 
> I'm interested in seeing this package uploaded into archive. A few months
> passed since this bug has been opened. How are things going?
> 
> Regards,
> Andrea.
> 
> -- 
> Andrea Colangelo |   http://andreacolangelo.com
> Ubuntu Developer |   Debian Maintainer  




signature.asc
Description: Digital signature

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

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: cura
  Version : 13.04~git20130502-1
  Upstream Author : David Braam (daid...@gmail.com)
* URL : http://daid.github.io/Cura/
* License : AGPL-3+
  Programming Lang: Python
  Description : Controller for 3D printers

Cura is a project which aims to be an single software
solution for 3D printing. While it is developed to be used
with the Ultimaker 3D printer, it can be used with other
RepRap based designs.

Cura helps you to setup an Ultimaker
Cura shows your 3D model, allows for scaling/positioning
Cura can slice the model to 3D GCode
Cura can send this GCode to the 3D printer for printing
And more...


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130503011533.13027.38521.report...@heights-197-63.mtu.edu

Bug#706503: ITP: arduino-mighty-1284p -- Platform files for Arduino to run on ATmega1284P

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: arduino-mighty-1284p
  Version : 0~svn20130430
  Upstream Author : http://maniacbug.wordpress.com/
* URL : https://github.com/maniacbug/mighty-1284p
* License : LGPL-2.1+, GPL-2+, GPL-3+, MIT
  Programming Lang: C
  Description : Platform files for Arduino to run on ATmega1284P

This package provides the files to make the arduino environment use several
non-standard boards.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130430235235.2.8545.reportbug@wijnen

Bug#634067: Still interested

[Bas Wijnen]

Ok, I'm still interested to adopt this package. However, it doesn't
really need any updates, which is why I didn't upload anything yet.

Also, I'm not that fast with uploading, so if someone else wants to
adopt is, please go ahead. For that reason, I'll leave it as orphaned
for now. Please don't remove the package, though. There's nothing wrong
with it.

Thanks,
Bas



signature.asc
Description: OpenPGP digital signature

Bug#689654: RFP: libmath-planepath-perl -- points on a path through the 2-D plane

[Bas Wijnen]

Package: wnpp
Severity: wishlist

* Package name: libmath-planepath-perl
  Version : 89
  Upstream Author : Kevin Ryde (e-mail unknown)
* URL : http://search.cpan.org/~kryde/Math-PlanePath-89/
* License : GPL
  Programming Lang: Perl
  Description : points on a path through the 2-D plane

I want to package Slic3r (#689636). This is a dependency for it. I don't know
Perl myself, and don't think it's a good idea to let a Perl module be
maintained by someone who doesn't. So I hope someone who does wants to create
and maintain this package.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121004192301.13252.76286.reportbug@localhost

Bug#689653: RFP: libmath-geometry-voronoi-perl -- compute Voronoi diagrams from sets of points

[Bas Wijnen]

Package: wnpp
Severity: wishlist

* Package name: libmath-geometry-voronoi-perl
  Version : 1.3
  Upstream Author : Sam Tregar 
* URL : http://search.cpan.org/~samtregar/Math-Geometry-Voronoi-1.3/
* License : unknown
  Programming Lang: Perl
  Description : compute Voronoi diagrams from sets of points

I want to package Slic3r (#689636). This is a dependency for it. I don't know
Perl myself, and don't think it's a good idea to let a Perl module be
maintained by someone who doesn't. So I hope someone who does wants to create
and maintain this package.

Unfortunately the licensing of this module is unclear and needs to be sorted
out. If you would be interested in maintaining this package, but don't want to
do this, please let me know and I'll see what I can do myself.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121004191824.13209.76646.reportbug@localhost

Bug#689652: RFP: libmath-convexhull-perl -- Calculate convex hulls using Graham's scan (n*log(n))

[Bas Wijnen]

Package: wnpp
Severity: wishlist

* Package name: libmath-convexhull-perl
  Version : 1.04
  Upstream Author : Steffen Müller 
* URL : http://search.cpan.org/~smueller/Math-ConvexHull-1.04/
* License : The Perl 5 License (Artistic 1 & GPL 1)
  Programming Lang: Perl
  Description : Calculate convex hulls using Graham's scan (n*log(n))

I want to package Slic3r (#689636). This is a dependency for it. I don't know
Perl myself, and don't think it's a good idea to let a Perl module be
maintained by someone who doesn't. So I hope someone who does wants to create
and maintain this package.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121004191130.13153.23774.reportbug@localhost

Bug#689650: RFP: libmath-clipper-perl -- Perl module for polygon clipping in 2D

[Bas Wijnen]

Package: wnpp
Severity: wishlist

* Package name: libmath-clipper-perl
  Version : 1.09
  Upstream Author : Alessandro Ranellucci 
* URL : http://search.cpan.org/~aar/Math-Clipper-1.09/
* License : The Perl 5 License (Artistic 1 & GPL 1)
  Programming Lang: Perl
  Description : Perl module for polygon clipping in 2D

I want to package Slic3r (#689636). This is a dependency for it. I don't know
Perl myself, and don't think it's a good idea to let a Perl module be
maintained by someone who doesn't. So I hope someone who does wants to create
and maintain this package.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121004190416.13112.35552.reportbug@localhost

Bug#689649: RFP: libboost-geometry-utils-perl -- Bindings for the Boost Geometry library

[Bas Wijnen]

Package: wnpp
Severity: wishlist

* Package name: libboost-geometry-utils-perl
  Version : 0.05
  Upstream Author : Alessandro Ranellucci 
* URL : http://search.cpan.org/~aar/Boost-Geometry-Utils-0.05/
* License : The Perl 5 License (Artistic 1 & GPL 1)
  Programming Lang: Perl
  Description : Perl-bindings for the Boost Geometry library

I want to package Slic3r (#689636). This is a dependency for it. I don't know
Perl myself, and don't think it's a good idea to let a Perl module be
maintained by someone who doesn't. So I hope someone who does wants to create
and maintain this package.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121004185932.13029.69055.reportbug@localhost

Bug#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: slic3r
  Version : 0.9.3
  Upstream Author : Alessandro Ranellucci 
* URL : http://slic3r.org/
* License : AGPL-3
  Programming Lang: Perl, C++
  Description : STL-to-GCODE translator for 3D printers

Slic3r can convert a 3D model into GCODE which is needed by 3D printers like
the RepRap. It can be used as a graphical program to convert files, or from the
commandline, for example from a printer interface like Printrun's pronterface.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121004164454.30295.66515.reportbug@localhost

Bug#686357: ITP: python-network -- python module for easy networking

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: python-network
  Version : 0.1
  Upstream Author : Bas Wijnen 
* URL : https://github.com/wijnen/python-network
* License : AGPL-3+
  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.

This module provides four classes: Socket and Server for string-based
connections, and RPCSocket and RPCServer for connections which call methods on
remote objects. All of this is symmetrical: once the connection is
established, the client and server use the same interface.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120831151511.10696.81048.reportbug@localhost

Bug#686339: ITP: python-wherigo -- python module for creating a wherigo player

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: python-wherigo
  Version : 0.1
  Upstream Author : Bas Wijnen 
* URL : https://github.com/wijnen/python-wherigo
* License : AGPL-3+
  Programming Lang: Python
  Description : python module for creating a wherigo player

Wherigo cartridges are real-world adventure games, which require the user to
move with their legs instead of their keys. This module implements the logic
that a cartridge needs, except the interface. It can be used to create a
player program, or embed wherigo playing into a larger program.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120831094946.14903.78370.reportbug@localhost

Bug#672410: ITP: wherpygo -- player for wherigo cartridges

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: wherpygo
  Version : 0.1
  Upstream Author : Bas Wijnen 
* URL : None, first publication will be in Debian.
* License : AGPL-3+
  Programming Lang: Python
  Description : player for wherigo cartridges

A sister-site of geocaching.com is wherigo.org. There people can publish 
cartridge files, which can contain tour guides, puzzles (often leading to a 
geocache), or other adventure-style games. The adventures always make use of a 
gps receiver to know your position, and part of the adventure is to actually 
walk around with your legs instead of your keys. A player is required to use 
those cartridges. The site provides a non-free player. There are several other 
players available for different phones.

Wherpygo is another player. It is designed for a netbook. That is not a usual 
platform for the game, because taking a netbook with you is not very 
comfortable. However, the good thing about it is that the interface has more 
features than the default interface. It also includes a debugging mode, which 
can be used by cartridge writers, or players who are stuck.



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120510205309.27735.42515.reportbug@localhost

Bug#672344: ITP: python-lua -- library for using lua scripts from python

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: python-lua
  Version : 0.1
  Upstream Author : Bas Wijnen 
* URL : None, first publication will be in Debian
* License : GPL-3+
  Programming Lang: Python
  Description : library for using lua scripts from python

This library provides an interface for using lua scripts from python.
It can call lua functions, pass any type of objects, including python
functions, which can be called from lua.



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120510091109.16596.74246.reportbug@localhost

Bug#650072: ITP: vmmlib -- templatized C++ vector and matrix math library

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: vmmlib
  Version : 0~svn540
  Upstream Author : Stefan Eilemann , Jonas Boesch 
, Susanne Suter 
* URL : http://http://vmmlib.sourceforge.net/
* License : BSD
  Programming Lang: C++
  Description : templatized C++ vector and matrix math library

Vmmlib's basic functionality includes a vector and a matrix class, with 
additional functionality for the often-used 3d and 4d vectors and 3x3 and 4x4 
matrices.

More advanced functionality include solvers, frustum computations and frustum 
culling classes, and spatial data structures.

It is implemented using C++ templates, making it versatile, and being a header 
library, it is very easy to integrate into other libraries and programs.



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2026090728.5615.91070.reportbug@localhost

Bug#649392: ITP: repsnapper -- STL - > GCode Converter and print software for RepRap machines

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: repsnapper
  Version : 1.9.0
  Upstream Author : Michael Meeks 
* URL : http://reprap.org/wiki/RepSnapper_Manual:Introduction
* License : GPL2+
  Programming Lang: C++
  Description : STL to GCode Converter and print software for RepRap 
machines

A RepRap is a 3D printer: a machine which can print 3-dimensional plastic
objects from a computer model. Repsnapper can convert STL, which can be created
with most 3D drawing programs like Blender, into GCode, which the RepRap can
understand. It can also be used to send the result to the RepRap.

This is how Repsnapper compares to other converters:

- RepRap host requires a non-free version of Java. It is otherwise equivalent.
- Skeinforge is much slower but produces much better output. It doesn't support
  sending the GCode to the RepRap.
- ReplicatorG requires a non-free version of Java. It calls Skeinforge to
  convert STL to GCode.



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2020161134.3515.46131.reportbug@localhost

Bug#621480: Uploading in spite of manpage problems

[Bas Wijnen]

This is a message to whoever sees the package in NEW, or anyone else who
wants to know why I'm uploading a package with a lintian error in it.

There are two problems with the generated manual pages in libshevek-doc:
- There is no short description for any of them.
- backslashes in the code are not properly escaped.

Both problems seem to be caused by doxygen. I've reported the issues
there[1][2]. Since I want the library to be in Debian (for use with
other programs), and these are only minor issues, I'm uploading the
package anyway, so it can sit in the NEW queue. These issues will be
fixed later (either by me or the doxygen people).

Thanks,
Bas

[1] https://bugzilla.gnome.org/show_bug.cgi?id=654870
[2] https://bugzilla.gnome.org/show_bug.cgi?id=654871




-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1311025687.4850.7.camel@vlam.psnet

Bug#622143: ITP: pvcam-utils -- utilities for using the Photometrics Coolsnap ES camera

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: pvcam-utils
  Version : 0.1
  Upstream Author : Bas Wijnen 
* URL : None yet, hopefully soon http://alioth.debian.org/.
* License : GPL
  Programming Lang: C++
  Description : utilities for using the Photometrics Coolsnap ES camera

This package contains the daemon and graphical client for using the camera. See
bug #622137 for more details.



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110410152345.2943.4942.reportbug@localhost.localdomain

Bug#622137: ITP: pvcam-dkms -- kernel module for Photometrics Coolsnap ES camera

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: pvcam-dkms
  Version : 4.1.0.
  Upstream Author : Bas Wijnen 
* URL : None yet, hopefully soon on http://alioth.debian.org.
* License : GPL
  Programming Lang: C
  Description : kernel module for Photometrics Coolsnap ES camera

Photometrics/Roper Scientific is the producer of the Coolsnap ES camera for
scientific measurements. They provide an unsupported driver for GNU/Linux,
consisting of a closed-source library and source for a kernel module.

The module doesn't compile on modern kernels, so I fixed it and maintain the
fixed version. I have also written some tools to make use of the library. An
overview:

- The kernel module is free and maintained by me. It has an interface which is
  only documented by its source. Since the only user of the module is the
  library, it should be considered an undocumented interface. This makes the
  module suitable for contrib.
- The library which they provide as a binary. It is broken because it doesn't
  have a SONAME and includes libm, but it does work. This obviously has to go
  into non-free. This library is like many C libraries: the program needs to
  take many steps even to do simple things.
- Because of this I wrote a daemon which allows simple commands to just work.
  This daemon uses a public interface to applications which want to do
  measurements. I may also write a different back-end at some point, which uses
  any video4linux(2) device instead of the Coolsnap. Even better would be to
  change the kernel module to turn the camera into a v4l device itself, but
  that doesn't seem feasable at the moment.
- While the daemon is controlled over a textual interface through a network
  port, which makes it very suitable for scripting, I also wrote a simple
  graphical program to use it.

At the moment I don't have a license to distribute the library, but they do
have it available on their website. Until I get a license (I don't think
they'll have a problem with that, they don't have a "don't distribute" license,
they simply have no license at all), I can let the postinst download the file
and install it.

This ITP is about the kernel module. I'll file separate reports for the library
and the tools.



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110410143611.2672.52696.reportbug@localhost.localdomain

Bug#622142: ITP: libpvcam -- library for using Photometrics coolsnap ES camera

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: libpvcam
  Version : 2.7.0.0
  Upstream Author : Unknown, unmaintained.
* URL : http://www.photometrics.com/support/downloads/lin_pvcam.php
* License : None
  Programming Lang: Probably C
  Description : library for using Photometrics coolsnap ES camera

This is a non-free library for using the Coolsnap ES camera. See bug #622137
(the corresponding kernel module) for more information.



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110410145227.2817.2136.reportbug@localhost.localdomain

Bug#621480: ITP: libshevek

[Bas Wijnen]

Package: wnpp

Libshevek is a library of functions and classes on top of gtkmm. It aims
at making them more easily usable, in particular to minimize the
configuration you need to do for useful default behaviour.

I am upstream of this library. I'm using it in several programs which I
intend to package eventually as well. As a first step, I want to package
the library.

License: GPL-3+
Current repository: http://a83-163-111-92.adsl.xs4all.nl/svn/trunk/libshevek
This is my home server; I've registered a project on Alioth where the
repository should be moved.


signature.asc
Description: Digital signature

Bug#441833: RFS: wound-up -- Arcade/Puzzle game involving cogs and elves

[Bas Wijnen]

Hi Matthew,

I'm looking at the package, and a few comments first.

- It's not completely stable, I was able to crash the game.  I have a
  backtrace at the bottom, which can be copied into a bug report once
  the game gets into unstable.
- There are several lintian warnings about the menu files.  Please fix
  them.
- The license says you must mark modified versions of the program as
  such.  Since you're patching the game, you must do this.
- When starting the game as "woundup --help", it responds with
  "usage: run_game.py [options]".  This should of course be
  "usage: woundup [options]".

For the rest, it looks good to me.  Although I must admid that I never
packaged a python program before, and had to read the policy first. :-)

Thanks,
Bas

Backtrace:

$ woundup 
/usr/share/games/wound-up/lib/game.py:308: DeprecationWarning: integer
argument expected, got float
  pxl = self.tutorial_map.get_at((px, py))
Traceback (most recent call last):
  File "./run_game.py", line 16, in ?
main.main()
  File "/usr/share/games/wound-up/lib/main.py", line 25, in main
menu.Menu(display.gl_render.GLRenderer, options).run()
  File "/usr/share/games/wound-up/lib/menu.py", line 175, in run
self.main_loop()
  File "/usr/share/games/wound-up/lib/menu.py", line 164, in main_loop
self.handle_events()
  File "/usr/share/games/wound-up/lib/menu.py", line 76, in
handle_events
self.start_game()
  File "/usr/share/games/wound-up/lib/menu.py", line 435, in start_game
time = new_game.run()
  File "/usr/share/games/wound-up/lib/game.py", line 283, in run
self.main_loop()
  File "/usr/share/games/wound-up/lib/game.py", line 262, in main_loop
self.state.tick()
  File "/usr/share/games/wound-up/lib/model/gamestate.py", line 95, in
tick
result = t.update(self)
  File "/usr/share/games/wound-up/lib/model/task.py", line 141, in
update
gs.acquire_winding_elf(elf)
  File "/usr/share/games/wound-up/lib/model/gamestate.py", line 283, in
acquire_winding_elf
self.elves.remove(elf)
KeyError: 

I had connected two touching cogs with a rubber band.  It shouldn't
work, of course, but it shouldn't crash either. :-)

On Thu, Sep 13, 2007 at 11:01:25AM +0100, Matthew Johnson wrote:
> Hi, I have recently packaged a game some friends of mine wrote for
> pyweek and I'm looking for a sponsor to upload it; I was hoping one of
> the DDs on this list would have time to review and upload it. The
> packages are available here:
> http://mjj29.matthew.ath.cx/debian-upload/wound-up/ and the ITP here:
> http://bugs.debian.org/441833
> 
> Thanks,
> Matt
> --
> Matthew Johnson



> ___
> Pkg-games-devel mailing list
> [EMAIL PROTECTED]
> http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Bug#203211: Software patents and Debian

[Bas Wijnen]

On Thu, Aug 17, 2006 at 10:44:25PM +0800, Weakish Jiang wrote:
> Bas Wijnen wrote:
> 
> > I thought we didn't care about them except if they were actively enforced,
> > because it's completely impossible to avoid all patented software,
> > considering the junk that gets patented.  
> >
> Unless the patent is licensed for everyone's free use or not licensed at
> all, it won't conform to the DFSG, even if it is not actively enforced.

Ok, I should be more careful with what I say on debian-legal. :-)  What you
say is obviously true if the programmer of the software has a patent on that
software.  However, in this case (and, I suppose, in the case of any other
program), there are patents held by third parties.  They may or may not
actively enforce them.  It is likely that distributing the program is a patent
violation by the programmer, at least in some countries (such as the US).  It
is also a violation for us to distribute it in those countries (if the patents
are valid, which is doubtful, but some of them may be, and this particular one
for mpeg4 probably is, I think).

So the license of the software is fine, the problem is that the programmer may
be illegally distributing the software to us, and it would be illegal for us
to distribute it to anyone else.  We can of course claim that we don't know,
and assume that the programmer knew what he was doing.  This is not unlikely
(actually, it's even true for me).  This means we only have to stop
distributing when the programmer does indeed get sued and loses the case.

The question was if that is indeed the way Debian does these things.  And in
particular, people do get sued for using the mpeg4 codec, IIUC.  So does that
mean we would at least consider it non-free?  Or not distributable at all?

Of course IANAL (that's why I'm asking here ;-) ), so in case of any
inaccuracies in the above, I'd appreciate corrections.

Oh, and about the suggestion to remove the problematic code: That's an option,
but I prefer not spending time on removing functionality from programs.

Thanks,
Bas Wijnen

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html


signature.asc
Description: Digital signature

Bug#203211: Software patents and Debian

[Bas Wijnen]

Hello,

When looking for some video-editing software, I found avidemux.  According to
the wnpp bug, there is a problem with license issues regarding the MPEG2/MPEG4
codec.  There is a software patent on this codec, and a paid license is needed
in order to use it, appearantly.

My question is how Debian handles software patents.  I thought we didn't care
about them except if they were actively enforced, because it's completely
impossible to avoid all patented software, considering the junk that gets
patented.  If that is the case, would any of you know if the MPEG[24] codec
patents are actively enforced?  In other words, can this be in Debian?

Thanks,
Bas Wijnen

Ps: Please keep me CCd, I'm not on the list.

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html


signature.asc
Description: Digital signature

Bug#352252: ITP: sdljump -- an improved clone of xjump featuring multi-player mode

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen <[EMAIL PROTECTED]>

* Package name: sdljump
  Version : 0.91-1
  Upstream Author : Juan Pedro Bol\('ivar Puente <[EMAIL PROTECTED]>
* URL : http://sdljump.sourceforge.net
* License : GPL
  Description : an improved clone of xjump featuring multi-player mode

 The goal in this game is to jump to the next floor so you don't fall
 down.  As you go higher in the Falling Tower the floors will fall
 faster.  Try to survive longer than anyone, or, in single player mode,
 as long as you can.
 .
 This game provides all the features of xjump, plus some more:
  * Multiplayer mode (up to four players, not networked)
  * Smooth graphics possible (but xjump style as well)
 .
 Home page: http://sdljump.sourceforge.net

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#308310: ITP: z80asm -- assembler for the Zilog Z80 microprocessor

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen <[EMAIL PROTECTED]>

* Package name: z80asm
  Version : 0.1
  Upstream Author : Bas Wijnen <[EMAIL PROTECTED]>
* URL : http://savannah.nongnu.org/projects/z80asm/
* License : GPL
  Description : assembler for the Zilog Z80 microprocessor

The Z80 microprocessor is used in old home computers, such as the
ZX-spectrum and MSX, and in several newer devices, such as the TI-83
graphical calculator and the GameBoy.

Features include:
 * including other sources (or generated label files)
 * complex expressions (similar to bash)
 * labels of unlimited length
 * conditional compilation depending on expressions

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]