Bug#583476: ITP: openscad -- script file based graphical CAD environment
Package: wnpp Severity: wishlist Owner: chrysn * Package name: openscad Version : 2010.05 Upstream Author : Clifford Wolf * URL : http://www.openscad.org/ * License : GPL-2+ with exception for CGAL (libcgal) Programming Lang: C++ and own domain specifc OpenSCAD (examples) Description : script file based graphical CAD environment OpenSCAD is a software for creating solid 3D CAD objects. It focuses on CAD aspects rather than artistic ones. OpenSCAD is not an interactive modeller. Instead it is something like a 3D-compiler that reads in a script file that describes the object and renders the 3D model from this script. This gives the designer full control over the modelling process and enables him to easily change any step in the modelling process or make designes that are defined by configurable parameters. notable dependencies of this software are libcgal (which is non-free, but it's just some QPL parts, so openscad will go to contrib) and opencsg, which is not yet packaged (RFP/ITP will follow). i have a more-or-less ready package at [1], but as this is both the first package of software i didn't write myself and the first package i use with platform dependent binaries (ie not python), i'll need some feedback on whether i'm doing it right (everything works quite ootb, but i'm not sure if it works everywhere). the only left over lintian complaint is binary-without-manpage, and it can be built in cowbuilder with the opencsg packages from [2]. [1] http://archive.amsuess.com/pool/contrib/o/openscad/ [2] http://archive.amsuess.com/pool/main/o/opencsg/ -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Bug#583705: ITP: opencsg -- image-based CSG (Constructive Solid Geometry) library using OpenGL
Package: wnpp Severity: wishlist Owner: chrysn * Package name: opencsg Version : 1.3.0 Upstream Author : Florian Kirsch * URL : http://opencsg.org/ * License : GPL-2+ Programming Lang: C++ Description : image-based CSG (Constructive Solid Geometry) library using OpenGL OpenCSG is a library for CGS (Constructive Solid Geomet) that can combine geometric primitives to more complex objects, for example the difference between two primitives. Instead of explicitly calculating the shape of the resulting object, it uses OpenGL's z-buffer to render the image. OpenCSG implements both the Goldfeather and the SCS algorithm. this library is required for the openscad program (itp at #583476). as with openscad, i have a working package, but again, i'm new to packaging libraries. the underlying software seems to be reasonably simple from a packaging point of view (once you kick out the glew library it wants to provide). it does not provide an installer on its onw, so the current package has an overridden dh_auto_install which handles that; apart from that, it's quite close to the default dh_make/dh7 3-liner. the current state of the packages is published on [1]. the package builds cleanly in cowbuilder and ubuntu ppa (see [2]). notable problems in the package are my lack of deep understanding of shared libraries (as a result, i don't know what to do with lintian's no-symbols-control-file), and the fact that i'll have to duplicate the whole glew copyright file inside the opencsg copyright file. unlike with openscad, i'm neither interested in this package itself nor in contact with upstream. i'd maintain the package for keeping openscad running, but am likely to orphan it if openscad drops the dependency, so if anyone else wants to maintain this package, consider this an RFP with patch. [1] http://archive.amsuess.com/pool/main/o/opencsg/ [2] https://launchpad.net/~chrysn/+archive/openscad -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Bug#597641: ITP: visolate -- tool for engraving PCBs using CNCs
Package: wnpp Severity: wishlist Owner: chrysn * Package name: visolate Version : 2.0.0 Upstream Author : Marsette A. Vona, III * URL : http://www.mit.edu/~vona/Visolate/ * License : GPL Programming Lang: Java Description : tool for engraving PCBs using CNCs Visolate reads the gerber files describing printed circuit boards and converts them into the g-code needed to engrave they layout into a board using a CNC machine. Precise renditions of the original layout can be created as well as voronoi fillings of the original layout, shortening the toolpath. there are some issues to be resolved with upstream concerning which version is the latest, but these can be expected to be resolved easily. as far as packaging itself is concerned, the current status relies on javahelper and hardly does anything but call javahelper and include a binary wrapper. for sake of completeness, i should mention that i have no experience in java programming at all -- for all but trivial fixes in the code, i will have to rely on upstream or others. that whole jar business seems to be handled by jh quite well, fortunately :-) -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Bug#616626: ITP: pcb2gcode -- command-line tool for engraving PCBs using CNCs
Package: wnpp Severity: wishlist Owner: chrysn * Package name: pcb2gcode Version : 1.1.0 Upstream Author : Patrick Birnzain * URL : http://sourceforge.net/apps/mediawiki/pcb2gcode/ * License : GPL-3+ Programming Lang: C++ Description : command-line tool for engraving PCBs using CNCs pcp2gcode is a command-line tool for isolation routing and drilling PCBs that provides full support for both single- and double-sided boards. It generates G-code (RS-274 code) for engraving and drilling from Gerber and Excellon files. i have packaged this program half a year ago (forgot to file an itp) and have been building updated packages several times since then. the packaging relies heavily on dh-autoreconf; apart from that, its debian/rules includes the necessary provisions for building a -dbg package and solving the rpath issue [1] brutally using chrpath. concerning dependencies, the program links against boost, gtk (for image operations and saving) and gerbv (the gerber viewer for file loading). it is lintian clean up to --pedantic. collaboration with upstream works well, there are numerous patches i've either written myself or relayed from other users that are now integrated. the package is about to be uploaded to mentors [2] (will be uploaded as soon as i get a bug number for this). please review the package; i'm about to submit it to debian-mentors@l.d.o with RFS. [1] http://wiki.debian.org/RpathIssue [2] http://mentors.debian.net/debian/pool/main/p/pcb2gcode/ signature.asc Description: Digital signature
Bug#716924: ITP: hyperrogue -- non-euclidean graphical rogue-like game
Package: wnpp Severity: wishlist Owner: chrysn * Package name: hyperrogue Version : 3.7 Upstream Author : Zeno Rogue * URL : http://www.roguetemple.com/z/hyper.php * License : GPL-2+ Programming Lang: C++ Description : non-euclidean graphical rogue-like game HyperRogue III is a game in which the player collects treasures and fights monsters -- a classical rogue-like but for the fact that it is played on the hyperbolic plane and not in euclidean space. . In HyperRogue, the player can move through different parts of the world, which are home to particular creatures and may be subject to own rules of "physics". . While it can use ASCII characters to display the world the classical rogue symbols, the game needs graphics to render the non-euclidean world. hyperrogue is a straightforward package. upstream's build system is plain make (thus debhelper for clean and install). the package has to be made dfsg free by removing shipped dlls and the bistream vera sans font, and some patching to bend paths to their proper locations. the debian extra mile involves desktop file, menu entry and man page. work is in progress. -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Bug#646876: ITP: libpaint-ruby -- terminal paint library with 256 color and effect support
Package: wnpp Severity: wishlist Owner: chrysn * Package name: libpaint-ruby Version : 0.8.3 Upstream Author : Jan Lelis * URL : http://rubygems.org/gems/paint * License : MIT Programming Lang: Ruby Description : terminal paint library with 256 color and effect support The paint library for ruby provides a single method, `Paint.[]`, that produces colored output on terminals. It comes with support for 256 color terminals, ANSI effects, and allows defining custom shortcuts. this library is a dependency of lolcat (itp will follow); i have no other interest in the library itself. i am not familiar with Ruby as a language, neither with ruby packaging. my current packaging approach is to just dump the lib/ files into /usr/lib/ruby/1.8/ (as it is done in libtrollop), but that might not be best practice. also, i completely ignore the spec/ directory, which might be needed for online documentation (?; i'm more familiar with python, where we have dh_python2 and docstrings in the source). in general, the package is lintian clean. i'm far from confident everything is packaged the right way, but it works and has nothing fancy to it that could break anything -- some positive feedback from someone who can judge the ruby side of it provided, i'd ask for a sponsor. the packages will be available on debian mentors in a few minutes. signature.asc Description: Digital signature
Bug#646877: ITP: lolcat -- colorful `cat`
Package: wnpp Severity: wishlist Owner: chrysn * Package name: lolcat Version : 42.0.99-1 Upstream Author : Moe * URL : https://github.com/busyloop/lolcat * License : WTFPL Programming Lang: Ruby Description : colorful `cat` lolcat concatenates files like the UNIX `cat` program, but colors it for the lulz in a rainbow animation. Terminals with 256 colors and animations are supported. lolcat is a typical "game" program in the sense of cowsay or fortune; the kind of tool you keep installed for occasional amuesement. i'm not familiar with Ruby or ruby packaging; the current packaging just dumps the lib/ files in /usr/lib/ruby/1.8/ and installs the executable script to /usr/games/. if there is a better way to install gems (ideally one that doesn't involve cdbs, just as a matter of personal preference), please let me know. the package is lintian clean (except for the pedantic issue of not having an upstream changelog), and works well. if someone could confirm that the ruby packaging part is sound, i'd be looking for a sponsor. the packages will be available on debian mentors in a few minutes. signature.asc Description: Digital signature
Bug#647060: ITP: openscad-mcad -- library for the OpenSCAD 3D modeling software
Package: wnpp
Severity: wishlist
Owner: chrysn
* Package name: openscad-mcad
Version : 0 (unreleased yet)
Upstream Author : quite a bunch
* URL : http://reprap.org/wiki/MCAD
* License : LGPL2.1 (and some more)
Programming Lang: OpenSCAD
Description : library for the OpenSCAD 3D modeling software
The MCAD library is a collection of modules and functions for OpenSCAD. It
contains boxes, gears, screws, and several generic shapes.
.
The library is a kind of a standard library for OpenSCAD.
the package is technically ready, but quite a mess on the copyright
side; plus, upstream has not yet decided how to do releases. i'm
packaging it anyway as it will be included in the next openscad release
(itp bug 583476), and i stripped it out in favor of a Recommends: to
openscad-mcad.
with copyright, there are several issues:
* the "base library" (the library is really just a collection of useful
files) doesn't clearly state an author. (although it can be deduced
from git logs and package website.)
* some files don't mention original copyright holders (constants.scad,
math.scad). i'd be tempted to attribute them to the base library
author, but then why should they use another license? (plus, the base
library author's other files are cleanly labelled.)
it could be argued that they don't reach the required threshold of
originality, but i'd have to ask -legal about the implications of
that.
* some files don't mention licenses, just copyright (polyholes.scad,
teardrop.scad).
* some files mention incomplete licenses ("Creative Commons" is not a
license (involute_gears.scad), neither is "BSD" (boxes.scad), and
neither "public domain" (at least where i live, but at least it is
clear what the author means; trochoids.scad))
for the time being, a basic package is uploaded at debian mentors[1].
[1] http://mentors.debian.net/package/openscad-mcad
signature.asc
Description: Digital signature
Bug#691349: ITP: libopencm3 -- firmware library for ARM Cortex-M3 and similar microcontrollers
Package: wnpp
Severity: wishlist
Owner: chrysn
* Package name: libopencm3
Version : not released yet
Upstream Author : Uwe Hermann , Piotr Esden-Tempski
and others
* URL : http://libopencm3.org/
* License : LGPL-3+
Programming Lang: C
Description : firmware library for ARM Cortex-M3 and similar
microcontrollers
libopencm3 (formerly libopenstm32) provides the basic library functions
for programming ARM Cortex M-3 microcontrollers. These tend to have
around up to 128k RAM and 1024k flash ROM, and onoboard peripherials
like SPI, UARTs, USB and general purpose IO (GPIO) pins. The library
contains drivers for the common core chip functionality (turning on and
off interrupts, managing the systick timer) and for the individual
chips.
* * *
the debian branch i'm keeping in the upstream git repo at [1] is
functional in the sense that libopencm3 can be used from the installed
package, but has several shortcomings:
* it depends on something to provide arm-none-eabi-gcc and an
appropriate libc (eg newlibc).
currently, i'm using a popular script to download, compile and install
the required toolchain: summon-arm-toolchain[2] (by the libopencm3
authors), for which i wrote a little debian directory[3] -- in that
form, it's pretty inacceptable as a debian package, though.
* it feels strange to have compiled binaries (statically linked
libraries) in an "architecture: all" package -- but seems technically
correct. (things were different if there was a debian port to those
chips, but only few of them support running linux at all).
* loads of lintian warnings, many about files at strange locations.
upstream installs to /usr/arm-none-eabi/{lib,include}, which is in
line with what the gcc used is expecting.
* some essential packaging stuff is missing (copyright and watch file,
the latter for lack of a release process, which is just being
discussed on the project mailing list) -- can fix that myself, it's
just lower priority than getting everything to build in the first
place
* examples are not installed yet -- can fix that myself too
so what i'd need in order to complete that package is:
* an idea of how to create an arm-none-eabi-gcc package properly.
my gut feeling says that the gcc-4.[67] packages should build another
binary package called gcc-4.[67]-arm-none-eabi, similar to
gcc-4.6-hppa64. i'm not familiar with how gcc actually works, so i
wonder whether we could have a gcc-4.7-multiarch just like we have
binutils-multiarch (which works well for libopencm3). same goes for
gdb (not depended on, but more "essential" than "useful" to
developers)
* a packaged newlibc; given how libstdc++ is integrated with gcc, i
don't know whether that's separate from the above or not.
* a statement on where things should actually go. /usr/share feels just
as wrong as "architecture: any" feels, and lintian complains about
/usr/arm-none-eabi/.
i'd like to emphasise that (from my understanding) this is neither
related to multiarch nor to emdebian, both of which are dealing with
cross compilation to other debian architectures, and this is about bare
metal programming.
[1] https://github.com/libopencm3/libopencm3/tree/debian
[2] https://github.com/esden/summon-arm-toolchain
[3] https://github.com/chrysn/summon-arm-toolchain
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: Digital signature
Bug#696933: ITP: lanyfs-utils -- Userspace utilities for Lanyard FS (LanyFS)
Package: wnpp Severity: wishlist Owner: chrysn * Package name: lanyfs-utils Version : 1.4 Upstream Author : Dan Luedtke * URL : https://www.nonattached.net/lanyfs/ * License : GPL or BSD 3-clause Programming Lang: C Description : Userspace utilities for Lanyard FS (LanyFS) lanyfs-utils contains the userspace utilities required for operating a LanyFS file system, ie. mkfs.lanyfs and detectfs.lanyfs. the lanyfs file system is in the progress of being upstreamed to mainline linux; i think having the packages early would be a good idea as it helps both attract early adaptors and people working on kernel integration. packaging-wise, lanyfs-utils is pretty trivial; it's just a makefile generating the binaries. my current package uses debhelper with minimal overrides to find the makefile. signature.asc Description: Digital signature
Re: [Prepare mass bug filling][RFC] New lintian tags: privacy-breach
hello debian developers,
hello trademark team,
(trademark team tl;dr: how's the incoming trademark policy going? having
trademarked and copyighted logos around is an issue again.)
i'm hooking into this topic with another aspect of it, attempting to cut
the "let's just ship the icons"-sayers with what has already been said
and done on the topic.
On Mon, Dec 23, 2013 at 04:23:19PM +0100, Bastien ROUCARIES wrote:
> I plan to mass bug the concerned package.
>
> They are some pattern in the privacy breaking website:
> - Valid html icons (w3.org). This one is problematic because we could
> not carry the icons in our tree (icons are not modifiable thus not
> free). Do we have an alternative ?
> - [...]
> - donation website. This one is problematic. I consider unethical to
> strip completly the donation part on the documentation. Free software
> need money. But I consider unethical to track our user. Thus I
> personnaly think documentation in this case need to redirect (but
> asking for a user click and by loudly noting that user will be
> redirect to external site) to upstream website. I need some comment on
> this
some software avoids this by shipping copies of nonfree logos, [1] can
be an example, as are various search engine logos. (this is not reported
yet for it would be another mass filing, see `apt-file find acebook
|grep 'gif\|png'`).
this is especially the way to go for programs which don't serve them via
a web server, but use the images locally (to represent accounts (instant
messengers), or for donation buttons in the about dialog).
i don't have any plan for action on how to resolve this in general;
there are two directions i see, both of which should be followed:
* some owners of logos will be cooperative. in the case of flattr (which
was what got me involved via the openscad package), i received a
statement from the flatr bigboss amounting to "we can work it out,
what do you need?". afaict, there is an ongoing work on an "incoming
trademark policy", the idea being that logo owners could release the
logo under a permissive licence while simultaneously restricting
misrepresenting modification by a trademark policy.
i don't know how much progress there has been in that area. in my
ideal world, there'd be a document from debian, similar to the
upstream guide, explaining to willing upstreams how they can release
their logo files while protecting their brand (which they might be
even legally bound to), but to the best of my knowledge there isn't
yet.
* we can establish a way of working around the problem technically. that
might involve a nonfree "logos-various-internet-services-nonfree", a free
"logos-various-internet-services-imitations" and a free
"logos-various-internet-services-free", where
* -nonfree contains icons of google, yahoo, flickr etc in all the
common resolutions; possibly, it'd be an installer package
(downloading the icons at install time if we can't ship them even in
nonfree).
* -imitations contains remakes of them (eg a plain white f on blue
background)
* -free contains icons that are usable in debian
when someone needs another icon, he can submit it for inclusion in
-nonfree and design a workaround for -imitations. further steps with
the icon upstreams coud then make the icon migrate to -free. a symlink
farm (possibly alternatives-based) can take the load of dealing with
this off the package, which only needs to +dfsg-repackage the software
and {install a symlink instead of the image,bend the image path} and
depend on something that provides logos-various-internet (>= when the
icon was added <= major release we reserve to drop icons of dead
services).
i'd prefer an easier technical solution if there were one.
for further reference, this issue has also come up with ikiwiki[2].
did i miss an easy solution? what can affected packages actually do?
best regards
chrysn
[1]
http://sources.debian.net/src/trac-authopenid/0.4.1-2/authopenid/htdocs/images
[2] https://ikiwiki.info/bugs/do_not_let_big_brother_spy_on_our_users_on_login/
--
A beginning is the time for taking the most delicate care that the balances are
correct.
-- Princess Irulan, Manual of Muad'Dib
signature.asc
Description: Digital signature
Re: git interface to snapshot.debian.org
On Thu, Aug 20, 2015 at 11:03:45AM +0200, Marco d'Itri wrote: > If you are just looking at adding a git interface to snapshot.d.o. then > maybe git-annex would be more appropriate while using much less > resources? This is primarily targeted at serving as a common starting point for packages that enter into the dgit workflow, which aims at having something git-cloneable that is equivalent to the source package. Unless there is a view of the package's history available, dgit would (and currently does) start off with whichever state the package is in in the archive at the point in time when dgit is first used with it. chrysn signature.asc Description: Digital signature
Re: User-installable Debian packages?
On Tue, Jul 25, 2017 at 12:04:27PM +0200, Florian Weimer wrote: > But it's not clear if the HPC community wants to run > containers/namespaces at all. Exploring the container-less approaches for different but related purposes[1], I just did what turned out to be a practice test of installation location independence: Installing openttd as a user with an out-of-root apt and dpkg location. Steps I needed to take were roughly: * Creating appropriate sources.list, apt.conf and debconfrc files * Creating some of the basic directory structure / empty files * (repeatedly, through the next steps) run `apt install openttd` * Adapt some postinst scripts * Bend paths to log files to the user-root location and similar * Drop python bytecode precompilation and ldconfig updates * The only thing I needed to do as root: Move away /var/lib/ucf and /etc/apt/apt.conf.d/* files as I didn't find a way to override them (as they're in preinst and probably hardcoded, respectively) * Run openttd with appropriate PATH, LD_LIBRARY_PATH and (as the game itself is not installation location dependent) working directory I think that if we can, if we want to, largely support location independent installations for the next release. That would help both user-installable packages and simplify creation of any of the container packages (if I understand them correctly). It seems most of the work on infrastructure and library packages could be done in generic places like postinst snipplets, some (but well testable) would be needed in particular packages like ucf, and then applications could be user-installable (or otherwise usable for position-independent installations) as soon as they become position-independent by themselves. Best regards chrysn [1]: I'd like to use sid versions of games on stable boxes w/o always needing to go through a changeroot -- I shouldn't have written all those tank programs. -- Kevin Flynn signature.asc Description: PGP signature
Bug#808945: RFP: openrct2 -- theme park simulation game (clone of Rollercoaster Tycoon 2)
Package: wnpp Severity: wishlist Owner: chrysn * Package name: openrct2 Version : 0.0.4 Upstream Author : Ted John * URL : https://openrct2.com/ * License : GPL-3+ (with potential issues) Programming Lang: C, Assembly Description : theme park simulation game (clone of RollerCoaster Tycoon 2) OpenRCT2 is a recreation of the RollerCoaster Tyocon 2 game. It relies on the presence of the original game's asset files, and is unplayable without them. The game itself is a build-up economy simulation, in which the player take the role of a park manager. The game's goal vary by scenario, but are usually achieved by freely built roller coasters and other rides and shops, while managing finances, staff and general guest happiness. OpenRCT2 also features a cooperative multiplayer mode. openrct2 copies the gameplay of the original rollercoaster tycoon very closely, and like the original game, offers many hours of challenging scenarios with a plethorea of rides to build. so far, it is the most (the only) complete theme park simulator available as free software or for linux. the game is currently being reverse engineered from the original rollercoaster tycoon binary, still depends on binary sections thereof to be included in the executable. as such, neither the sources nor the resulting game are distributble in debian, maybe not even in nonfree. the authors claim using the same process originally used with openttd, which after some discussion made it through dfsg checks, so in the end the game should become distributable. (personally, i tend to subscribe to a rather broad definition of derivative work and strict interpretation of copyright, under which this would forever be tainted for not being a clean room clone, but the history of openttd seems to indicate that i'm being overly cautious.) anyway, the game will depend on original artwork (possibly managable with game-data-packager), so until free assets to make it playable are available, it could at best go into contrib. until the original .exe can be dropped from the build process, the build is likely to be i386 only (but can both be built and used on amd64). the game declares several dependencies available in debian. unpackaged libraries are shipped in a dedicated orclibs zip file (argparse, cutest, lodepng), they probably need to be packaged beforehand if they are not modified. (i vaguely remember lodepng being one of those "don't bother with library stuff, just copy/paste the file in to your sources and season to taster" libraries). overall, this is package is likely not to be a usable package any time soon. i'd like to use this bug to spool preparative work on a future package, that is, packaging of libraries, packaging of game data in game-data-packager, and discussion of legal aspects of distribution. best regards chrysn -- Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Terry Pratchett (attributed) signature.asc Description: PGP signature
Re: Going ahead with non-free-firmware
On Mon, Jan 11, 2016 at 09:34:07AM -0800, Nikolaus Rath wrote: > On Jan 09 2016, Dominic Hargreaves wrote: > > I think the *policy* for this section should be firmware, as defined > > as code not executing on the main CPU, or something like that. > > Uh, so intel-microcode is still out? From that description, yes, and I appreciate that. FWICT, nonfree-firmware aims to find a middle ground between 1) security issues with non-free system components, and 2) hardware being unusable without nonfree blobs. Right now microcode does not fit in that middle ground from either 1) (because no DMA to protect us) nor 2) (because things work without as well). If, at some future point in time, CPUs do require microcode updates, we might need to revisit this. best regards chrysn -- A beginning is the time for taking the most delicate care that the balances are correct. -- Princess Irulan, Manual of Muad'Dib signature.asc Description: PGP signature
