Bug#1029942: ITP: python-lua -- library for using Lua scripts from Python
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
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
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
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.
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
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
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
-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
-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
-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
-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#842211: ITP: eeshow -- Schematics renderer and viewer for KiCad
-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
-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
-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
(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#742704: ImplicitCad in Debian
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
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
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
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
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#729146: ITP: cura-engine -- commandline slicer program for 3-D printers
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-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
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
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * 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
Control: owner 689636 Zlatan Todoric zlatan.todo...@gmail.com 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
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
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 wij...@debian.org wrote: Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * 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
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
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
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
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 www.ubuntu.com | Debian Maintainer www.debian.org signature.asc Description: Digital signature
Bug#706656: ITP: cura -- Controller for 3D printers
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * 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
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * 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
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#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * Package name: slic3r Version : 0.9.3 Upstream Author : Alessandro Ranellucci a...@cpan.org * 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#689649: RFP: libboost-geometry-utils-perl -- Bindings for the Boost Geometry library
Package: wnpp Severity: wishlist * Package name: libboost-geometry-utils-perl Version : 0.05 Upstream Author : Alessandro Ranellucci a...@cpan.org * 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#689650: RFP: libmath-clipper-perl -- Perl module for polygon clipping in 2D
Package: wnpp Severity: wishlist * Package name: libmath-clipper-perl Version : 1.09 Upstream Author : Alessandro Ranellucci a...@cpan.org * 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#689652: RFP: libmath-convexhull-perl -- Calculate convex hulls using Graham's scan (n*log(n))
Package: wnpp Severity: wishlist * Package name: libmath-convexhull-perl Version : 1.04 Upstream Author : Steffen Müller smuel...@cpan.org * 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#689653: RFP: libmath-geometry-voronoi-perl -- compute Voronoi diagrams from sets of points
Package: wnpp Severity: wishlist * Package name: libmath-geometry-voronoi-perl Version : 1.3 Upstream Author : Sam Tregar s...@tregar.com * 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#689654: RFP: libmath-planepath-perl -- points on a path through the 2-D plane
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#686339: ITP: python-wherigo -- python module for creating a wherigo player
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * Package name: python-wherigo Version : 0.1 Upstream Author : Bas Wijnen wij...@debian.org * 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#686357: ITP: python-network -- python module for easy networking
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * Package name: python-network Version : 0.1 Upstream Author : Bas Wijnen wij...@debian.org * 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#672344: ITP: python-lua -- library for using lua scripts from python
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * Package name: python-lua Version : 0.1 Upstream Author : Bas Wijnen wij...@debian.org * 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#672410: ITP: wherpygo -- player for wherigo cartridges
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * Package name: wherpygo Version : 0.1 Upstream Author : Bas Wijnen wij...@debian.org * 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#650072: ITP: vmmlib -- templatized C++ vector and matrix math library
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * Package name: vmmlib Version : 0~svn540 Upstream Author : Stefan Eilemann e...@users.sf.net, Jonas Boesch l...@users.sf.net, Susanne Suter susu...@users.sf.net * 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
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * Package name: repsnapper Version : 1.9.0 Upstream Author : Michael Meeks michael.me...@novell.com * 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
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#622142: ITP: libpvcam -- library for using Photometrics coolsnap ES camera
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * 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#622137: ITP: pvcam-dkms -- kernel module for Photometrics Coolsnap ES camera
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * Package name: pvcam-dkms Version : 4.1.0. Upstream Author : Bas Wijnen wij...@debian.org * 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#622143: ITP: pvcam-utils -- utilities for using the Photometrics Coolsnap ES camera
Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * Package name: pvcam-utils Version : 0.1 Upstream Author : Bas Wijnen wij...@debian.org * 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#621480: ITP: libshevek
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
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: model.elf.Elf object at 0x8b03eac 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
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
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
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
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]
