Bug#1025206: RFP: bespoke -- Software modular music synthesizer

[Josh Triplett]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

* Package name: bespoke
  Version : 1.1.0
  Upstream Author : Ryan Challinor 
* URL : https://www.bespokesynth.com/
https://github.com/BespokeSynth/BespokeSynth/
* License : GPLv3
  Programming Lang: C++
  Description : Software modular music synthesizer

Bespoke is a graphical tool to synthesize music, by wiring together
modular components.

Bug#933579: ITP: openvr -- openvr sdk

[Josh Triplett]

On Thu, Aug 01, 2019 at 02:23:21AM +0800, Andrew Lee (李健秋) wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andrew Lee (李健秋) 
> 
> * Package name: openvr
>   Version : 1.4.18
>   Upstream Author : Valve Corporation
> * URL : https://github.com/ValveSoftware/openvr
> * License : Expat
>   Programming Lang: C
>   Description : openvr sdk
> 
>  OpenVR is an API and runtime that allows access to VR hardware from
>  multiple vendors without requiring that applications have specific
>  knowledge of the hardware they are targeting. This repository is an
>  SDK that contains the API and samples. The runtime is under SteamVR
>  in Tools on Steam.

Can OpenVR work with any Open Source backend? (And do you intend to
package such a backend?) It appears to only work with SteamVR, which is
proprietary. If this only works with SteamVR or other proprietary
backends, or in general if Debian doesn't have any Open Source backend
for this, it'll have to go to contrib, not main.

Bug#913285: RFP: oxipng -- Parallel lossless PNG compression optimizer

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: oxipng
  Version : 2.1.5
  Upstream Author : Joshua Holmer 
* URL : https://github.com/shssoichiro/oxipng
* License : MIT
  Programming Lang: Rust
  Description : Parallel lossless PNG compression optimizer

Oxipng optimizes PNG images to make them use less storage and bandwidth.
In parallel, oxipng evaluates possible PNG encoding parameters, zlib
DEFLATE encoding parameters, and optionally Zopfli-optimized DEFLATE
encoding parameters, writing out the optimized image that uses the least
storage and bandwidth.

Bug#842943: Also interested in this

[Josh Triplett]

I'd love to see a package of the Signal standalone desktop client in
main.

As far as I can tell, the github repository at
https://github.com/signalapp/Signal-Desktop has the source of the
standalone desktop client.

- Josh Triplett

Bug#883701: RFP: turtl -- Note-taking application with secure online syncing

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: turtl
  Version : 0.6.0
  Upstream Author : i...@turtlapp.com
* URL : https://turtlapp.com/
* License : GPLv3 for the client, AGPLv3 for the server
  Programming Lang: JavaScript and Rust
  Description : Note-taking application with secure online syncing

Turtl is a note-taking application that supports sharing and syncing
notes securely, with client-side encryption, so that the server has no
access to your notes.


The client and server are both FOSS; I'd love to see both packaged,
though the client would be higher priority. The server uses node.js; the
client uses NW.js. Both have a common library written in Rust.

Bug#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager

[Josh Triplett]

On Thu, Apr 20, 2017 at 08:16:00AM +, Ximin Luo wrote:
> Josh Triplett:
> > [..]
> > 
> > ...and looking at git from 20 minutes ago, it looks like you've switched
> > over to directory registries now.
> > 
> 
> Thanks for the tip, yes I figured this out by looking at both your dh-cargo 
> code and also the Fedora cargo package. [1]
> 
> The new version is uploaded to experimental, but there's some more things I'd 
> like to tidy up before uploading it to unstable.
> 
> - I get errors about missing "cargotest" and "hamcrest" when I try to `make 
> test`, it looks like cargotest is actually in the rustc package:
> 
> https://github.com/rust-lang/rust/tree/master/src/tools/cargotest
> 
> Any suggestions on how to deal with this? I guess the obvious thing to do is 
> to package a librust-cargotest-xxx-dev package but I wonder if there are 
> better options.
> 
> - cargo still embeds libgit2-sys source code, and I can see that in the 
> deps-tarball-filter.txt Luca was explicitly leaving it in. Is that because 
> they patch the source code?
> 
> Can we just get rid of it, and link to libgit2 instead?

git2-rs doesn't modify libgit2, but it does use a snapshot from git, via
a submodule.  And unfortunately, while it supports building against a
system version via pkg-config, it doesn't include any version number in
its dependency.  libgit2 itself doesn't have a stable ABI, so either an
older *or* a newer version can potentially fail due to
incompatibilities.  (Also, like many libraries, libgit2 doesn't really
update its SONAME and similar except when releasing, even though many
people run git snapshots.)

Fortunately, git2-rs uses ctest now to attempt to make sure its bindings
match the actual signatures of the functions, so at least an attempt to
build against an older (or sometimes newer) version of libgit2 will tend
to produce compile errors (assuming you get all the environment
variables set correctly to find it).  However, I know of at least one
case where git2-rs pulled in a new snapshot of libgit2 to obtain
critical bugfixes rather than differences in ABI.

In short, I think we *could* switch to pulling in the system version of
libgit2, but we'd need to work very closely with the libgit2 maintainer,
and sometimes package snapshots of libgit2 from git.  We might also want
to work with libgit2 and git2-rs upstreams to 1) get more regular
updates to the version number that appears in the pkg-config file and 2)
get libgit2-sys to declare a pkg-config dependency that matches its
snapshot of libgit2.

- Josh Triplett

Bug#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager

[Josh Triplett]

On Wed, Apr 19, 2017 at 11:11:00PM +, Ximin Luo wrote:
> Ximin Luo:
> > [..]
> 
> I've made some more process and have pushed 0.17.0 to git. However we're 
> getting build errors and I don't know how to proceed:
> 
> https://anonscm.debian.org/cgit/pkg-rust/cargo.git/tree/debian/TODO
> https://anonscm.debian.org/cgit/pkg-rust/cargo.git/tree/debian/cargo-vendor-pack.py
> 
> I'm not familiar with the Cargo repo formats, and I don't know how 
> d/cargo-vendor-pack.py should be fixed. Help would be appreciated.
> 
> Josh, is this anything related to how your dh-cargo works? Any code that we 
> can reuse?

Not directly, until we're ready to package all the individual crate
dependencies (which we'll want to do at some point).  But you can
definitely use the same mechanism; it'd be much easier to generate a
directory registry than the full Cargo index format.  Rather than
generating an index file and repo, just:

1) Copy every crate directory, verbatim, into a subdirectory of a vendor
   directory.

2) Create a file .cargo-checksum.json in the crate directory, containing
   {"package":"$SHA256","files":{}} , where $SHA256 is the sha256 of the
   .crate file.

3) Create a directory containing a file "config", containing:

[source.crates-io]
replace-with = "my-registry"

[source.my-registry]
directory = "/path/to/the/vendor/directory"

4) Set CARGO_HOME to the directory containing that config file, and
   build.

debcargo can help a bit with this.  Run it on a crate, move
debian/cargo-checksum.json to .cargo-checksum.json , aggregate
debian/copyright, remove the rest of debian/ , and put the resulting
directory into the registry directory.

...and looking at git from 20 minutes ago, it looks like you've switched
over to directory registries now.

Bug#852451: ITP: rname -- invoke a program under a different name

[Josh Triplett]

On Tue, 24 Jan 2017 17:19:49 +0200 Peter Pentchev <r...@ringlet.net> wrote:
> The rname utility invokes a specified program, passing a different name
> instead of the name of the program executable.  This could be useful in
> a number of cases, both during software development, testing, and in
> production use.  There are many programs that do different things based
> on what name they have been invoked under; the rname utility avoids
> the need to e.g. create ephemeral symlinks to run these programs in
> some conditions when they have not been completely installed.
> 
> I originally wrote this tool in 2000 and I'm resurrecting it now for
> the purpose of writing unit and integration tests for just such
> a multifaceted program.

What kind of test environment do you plan to use rname from?  Not trying
to suggest that you shouldn't package it, but I wanted to call attention
to a little-known feature of the bash exec builtin:

~$ (exec sh -c 'echo $0')
sh
~$ (exec -a differentname sh -c 'echo $0')
differentname

That unfortunately doesn't work in portable sh, though; rname seems like
an appropriate option if you can more easily require rname than
requiring bash (or a better scripting/testing language).

- Josh Triplett

Bug#504266: closing RFP: darwin-calendar-server -- CalDAV calendar server

[Josh Triplett]

On Mon, Sep 12, 2016 at 10:01:57PM -0700, Josh Triplett wrote:
> On Mon, Sep 12, 2016 at 10:20:15AM +, Bart Martens wrote:
> > RFP 504266 has no visible progress for a long time, so closing.
> 
> It looks like the software got packaged (as "calendarserver") back in
> 2011, just without an update to the RFP.

Correction, packaged back in 2008.

Bug#504266: closing RFP: darwin-calendar-server -- CalDAV calendar server

[Josh Triplett]

On Mon, Sep 12, 2016 at 10:20:15AM +, Bart Martens wrote:
> RFP 504266 has no visible progress for a long time, so closing.

It looks like the software got packaged (as "calendarserver") back in
2011, just without an update to the RFP.

Bug#829007: ITP: gnome-shell-extension-move-clock -- move clock extension for GNOME shell

[Josh Triplett]

On Wed, 29 Jun 2016 20:07:22 +0200 "Jonathan Carter (highvoltage)" 
 wrote:
> * Package name: gnome-shell-extension-move-clock
>   Version : 1.0.0
>   Upstream Author : 2011-2013 Ron Yorston 
> 2016 Jonathan Carter 
> * URL :
> https://git.bluemosh.com/highvoltage/gnome-shell-extension-move-clock
> * License : GPL-2+
>   Programming Lang: JavaScript
>   Description : move clock extension for GNOME shell
> 
> This extension will, when enabled, move the clock on your GNOME shell panel
> from the middel to the right.

s/middel/middle/

Also, when you CC debian-devel on ITPs, please use X-Debbugs-CC, so that
the BTS sends debian-devel a version of the bug with a bug number
included.

Bug#827843: ITP: xlogo -- XLogo is an interpreter for the Logo programming language, written in Java.

[Josh Triplett]

On Tue, 21 Jun 2016 18:18:09 +0200 Wolf Bergenheim  wrote:
> * Package name: xlogo

Note that x11-apps ships /usr/bin/xlogo (a tiny toy app that displays
the X Window System logo), so you'll want to avoid a binary name
conflict.

Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture

[Josh Triplett]

Wookey <woo...@wookware.org> wrote:
> +++ Christian Seiler [2016-05-07 16:14 +0200]:
> > On 05/07/2016 03:59 PM, Geert Stappers wrote:
> > > I now have a better idea _why_  a sse-suport package.
> 
> I do think that this sort of ISA-level checking would be best done via
> dpkg and package metadata, although this sse-support mechanism will
> obviously work. i.e the cpontrol file says what ISA features are
> wanted and dpkg can not install it if those HWCAPS are not available
> (or indeed install alternate versions that will work if they are
> available).
> 
> We worked up a prototype spec for this a couple of years ago (at the
> bootstrap sprint), but it needs the namespace and granularity fleshing
> out: what is the set of HWCAPS listed in each package, what is
> presumed to be 'base' that we don't list individually, and so on.

I'd love to see this integrated with dpkg multiarch support.  That way,
for instance, specific packages could provide optimized versions for
specific target CPU features.

I think we'd need three things to make that happen:

1) Support in dpkg multiarch to understand "compatible" architectures
   that can satisfy each others' dependencies (e.g. a dependency on
   libfoo1:amd64 is satisfied by libfoo1:amd64+avx2, and vice versa).

2) Support for synthesizing such architectures in a canonical way from a
   set of CPU features, so that every combination of CPU features
   doesn't need its own unique architecture name (we don't want
   architecture names like "amd64+sse4+avx2+rdrand", even though a
   package might need that set of features).

3) Support for detecting available CPU features, as you mentioned above,
   to not even attempt to install a package that requires unavailable
   CPU features.

Optionally, we could also detect if the set of CPU features has changed
incompatibly.  For instance, if you move your Debian filesystem to a
system without some features that you have installed packages depending
on, it'd be nice to handle that as gracefully as possible.

- Josh Triplett

Bug#821318: RFP: vim-toml -- Vim filetype and syntax plugin for TOML files

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: vim-toml
* URL : https://github.com/cespare/vim-toml
* License : MIT
  Description : Vim filetype and syntax plugin for TOML files

This package provides vim support for editing TOML files, including
filetype detection and syntax highlighting.


CCing pkg-rust-maintainers, since Rust's Cargo ecosystem uses TOML.

Bug#748321: ITP: raceintospace -- free software version of the Liftoff! board game

[Josh Triplett]

On Sun, 14 Sep 2014 09:49:27 +0200 Dariusz Dwornikowski 
dariusz.dwornikow...@cs.put.poznan.pl wrote:
  Dariusz Dwornikowski dariusz.dwornikow...@cs.put.poznan.pl writes:
  
   Since the package depends on physfs 2.1, which has not been release
   yet, we need to wait for the upstream of physfs to release 2.1 and for
   the package to be in Debian. For now, raceintospace is ready in
   pkg-games git and can go to Debian when physfs is ready. 
  
  Thanks for your efforts in packaging raceintospace. I've noticed that
  Hedgewars used to have a similar problem, which they've solved by adding
  a compatibility layer for PhysFS 2.0. Using this as a starting point, I
  saw that only one more function had to be provided, which I backported
  from the 2.1 branch with some minor modifications. With the attached
  patch, raceintospace compiles and runs with the PhysFS library from
  sid. The compatibility layer checks for the version number of PhysFS, so
  once 2.1 is packaged, the code should automatically stop being included.
 
 Thanks for that Hendrik, I will test it and preppare a release if it
 is ok. 
 
 
  
  The only slight drawback is that Hedgewars is GPL-2 only, so it will no
  longer be possible to ship raceintospace binaries as GPL-2+. But since
  this is only a temporary situation, I think this can be justified.
 
 Yeah I think so. On the other hand I can see that physfs is not very
 actively developed so we could wait a little bit. 

It's been 9 months, and physfs 2.1 still doesn't seem to be available
in either sid or experimental.  This patch seems quite reasonable; is
someone still willing to upload raceintospace with that patch?

- Josh Triplett


-- 
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/20150630004357.GA15976@jtriplet-mobl1

Bug#781984: ITP: libnacl -- ctypes wrapper for libsodium

[Josh Triplett]

On Sun, 05 Apr 2015 22:12:02 +0200 David Douard david.dou...@logilab.fr wrote:
 Package: wnpp
 Severity: wishlist
 Owner: David Douard david.dou...@logilab.fr
 
 * Package name: libnacl
   Version : 1.4.2
   Upstream Author : Thomas S Hatch tha...@saltstack.com
 * URL : https://libnacl.readthedocs.org/
 * License : Apache 2.0
   Programming Lang: Python
   Description : ctypes wrapper for libsodium
 
 This library is used to gain direct access to the functions exposed by
 Daniel J. Bernstein's nacl library via libsodium or tweetnacl. It has
 been constructed to maintain extensive documentation on how to use nacl
 as well as being completely portable.
 
 This package is a dependency for raet, the new transport layer for salt.

Would you consider including a brief note in the final package
description saying This library is unrelated to Native Client (NaCl),
the sandbox used in Chromium.?  I've seen that particular confusion
arise several times, particularly since people often want a library
version of the Chromium NaCl sandbox.

Thanks,
Josh Triplett


-- 
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/20150406213720.GA8782@jtriplet-mobl1

Bug#779232: RFP: screen-session -- Session management and other tools for GNU Screen

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: screen-session
  Version : (git)
  Upstream Author : Artur Skonecki skon...@gmail.com
* URL : https://skoneka.github.io/screen-session/index.html
* License : GPLv3
  Programming Lang: Python
  Description : Session management and other tools for GNU Screen

screen-session (scs) includes various commands to manage GNU Screen
sessions, including saving and restoring sessions, and managing layouts.


Personally, I'm primarily interested in this for the scs new-window
command, which uses /proc to figure out the working directory of the
current screen tab and opens a new window in that directory.  If screen
knew how to do that natively, I wouldn't need screen-session.

- Josh Triplett


-- 
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/20150225184437.3607.15632.reportbug@jtriplet-mobl1

Bug#570611: Bug#669920: Please provide a backport for squeeze

[Josh Triplett]

On Sun, Apr 22, 2012 at 12:49:24AM -0400, Andres Mejia wrote:
 On Sat, Apr 21, 2012 at 8:46 PM, Josh Triplett j...@joshtriplett.org wrote:
  On Sat, Apr 21, 2012 at 06:53:57PM -0400, Andres Mejia wrote:
  On Sat, Apr 21, 2012 at 6:10 PM, Josh Triplett j...@joshtriplett.org 
  wrote:
   Package: libcrystalhd-dev
   Severity: wishlist
  
   Please consider providing a backport of libcrystalhd-dev for squeeze.
   Such a backport would make it easier to prepare MythTV packages for
   squeeze.
  
   Thanks,
   Josh Triplett
  
   -- System Information:
   Debian Release: wheezy/sid
    APT prefers unstable
    APT policy: (500, 'unstable'), (1, 'experimental')
   Architecture: amd64 (x86_64)
  
   Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
   Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
   Shell: /bin/sh linked to /bin/dash
  
  
 
  Hi Josh,
  Were you trying to package MythTV to unstable at all? IMO that should
  be done first before attempting to upload for squeeze (i.e. actually
  get accepted, get tested in unstable, migrate to testing, then
  backport to stable).
 
  At the moment I'm just building some local packages, not official
  backports.  I'd love to see official MythTV packages, and I'd be happy
  to help work on them, but that wasn't my goal at the moment.
 
  - Josh Triplett
 
 I recommend starting off by porting the Ubuntu packaging of MythTV to
 Debian.

I actually started from the debian-multimedia packaging, and hacked out
all the bits that depended on packages outside of Debian, as well as
dependency cruft that applied to previous versions but not to the
current version.  I've managed to successfully build working squeeze
packages at this point, which only depend on packages in Debian to build
and run; installing them requires a couple of packages from
squeeze-backports (fonts-droid, libmp3lame0, libx264-120, libxvidcore4),
and a locally built backport of libcrystalhd3, and all the rest of the
dependencies come from squeeze.

 I presume if these are local packages, you're using reprepro
 or something similar to host a local archive. In such a case, you may
 as well build packages of libcrystalhd and upload them to your local
 archive. Then you can build mythtv.

I did end up building local packages of crystalhd and libcec, which
proved relatively straightforward.

 Note that mythtv is using it's own copy of ffmpeg. It needs to be
 modified so it can build/run with system libav before it can be
 uploaded to Debian. If that's something you're interested in doing, by
 all means, feel free to modify mythtv source tree, and preferably work
 with mythtv upstream to pass along patches.

Yeah, I do know about that problem.  Arguably not an issue for an upload
to Debian experimental; only an issue for having a version in a
security-supportable release.

Considering that upstream went out of their way to remove support for
system libav/ffmpeg (due to issues with different versions on end-user
systems, particularly versions of the command-line tools), I suspect
they might not like the idea of adding it back, or for that matter the
idea of adding support for using avconv rather than ffmpeg.  This needs
a long conversation with upstream before attempting to write a patch; no
sense writing a patch that'll never make it upstream.

- Josh Triplett



--
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/20120422093318.GA4379@leaf

Bug#570611: Bug#669920: Please provide a backport for squeeze

[Josh Triplett]

On Sat, Apr 21, 2012 at 06:53:57PM -0400, Andres Mejia wrote:
 On Sat, Apr 21, 2012 at 6:10 PM, Josh Triplett j...@joshtriplett.org wrote:
  Package: libcrystalhd-dev
  Severity: wishlist
 
  Please consider providing a backport of libcrystalhd-dev for squeeze.
  Such a backport would make it easier to prepare MythTV packages for
  squeeze.
 
  Thanks,
  Josh Triplett
 
  -- System Information:
  Debian Release: wheezy/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
  Architecture: amd64 (x86_64)
 
  Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
  Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
  Shell: /bin/sh linked to /bin/dash
 
 
 
 Hi Josh,
 Were you trying to package MythTV to unstable at all? IMO that should
 be done first before attempting to upload for squeeze (i.e. actually
 get accepted, get tested in unstable, migrate to testing, then
 backport to stable).

At the moment I'm just building some local packages, not official
backports.  I'd love to see official MythTV packages, and I'd be happy
to help work on them, but that wasn't my goal at the moment.

- Josh Triplett



--
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/20120422004617.GA30987@leaf

Bug#642288: RFP: cabal-dev -- Manage sandboxed Haskell build environments

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: cabal-dev
  Version : 0.8
  Upstream Author : Josh Hoyt j...@galois.com, Jonathan Daughtery 
j...@galois.com, Rogan Creswick cresw...@galois.com
* URL : http://hackage.haskell.org/package/cabal-dev
* License : BSD (3-clause)
  Programming Lang: Haskell
  Description : Manage sandboxed Haskell build environments

cabal-dev is a tool for managing development builds of Haskell projects.
It supports maintaining sandboxed cabal-install repositories, and
sandboxed ghc package databases.

For most packages, just use cabal-dev instead of cabal, and you will get
a sandboxed build that will not install anything (even automatically
installed dependencies) into the user or global ghc package databases.
You can also add local sources for patched or unreleased libraries.



-- 
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/20110921064611.2421.86209.reportbug@leaf

Bug#637471: RFP: tj3 -- TaskJuggler 3, a project management tool with resource constraint solving

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: tj3
  Version : 0.2.1
  Upstream Author : Chris Schläger ch...@linux.com
* URL : http://taskjuggler.org/
* License : GPLv2
  Programming Lang: Ruby
  Description : TaskJuggler 3, a project management tool with resource 
constraint scheduling

TaskJuggler 3 provides project management tools built around a
text-based project description format.  It supports project scoping,
task tracking, resource assignment, and cost and revenue planing.

TaskJuggler includes a resource constraint scheduler, which can
automatically assign resources to tasks, and prevent conflicts between
tasks that require the same resource.

TaskJuggler compiles project descriptions, computes  and produces reports,
including task lists, schedules, timesheets, Gantt charts, iCal, and
CSV.

[ Note that this package explicitly needs to refer to TaskJuggler 3,
to distinguish it from the obsolete TaskJuggler 2 for KDE3/Qt3. 

Also note that this package includes a vim mode, which will need
installing in the appropriate path, and configuring for automatic use on
..tjp and .tji files. ]



-- 
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/20110811204319.16333.7386.reportbug@leaf

Bug#482938: Confirming

[Josh Triplett]

Just to confirm, I stopped using foxmarks a long time ago when it
stopped using a FOSS license, and in any case Firefox Sync has made it
entirely obsolete.  So I definitely no longer care about this RFP.

- Josh Triplett



-- 
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/20110731054204.GA4378@leaf

Bug#570611: LAME now in Debian

[Josh Triplett]

As of the recent clearing of the NEW queue
(http://blog.schmehl.info/Debian/NEW-empty), it looks like LAME and x264
both made it into Debian.  That should make MythTV packaging much
easier.

- Josh Triplett



-- 
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/20110729220331.GA5909@leaf

Bug#574800: nss-myhostname packaged for Debian

[Josh Triplett]

On Fri, May 07, 2010 at 10:03:36PM +0200, Joachim Breitner wrote:
 after being kindly asked to do it, I packaged nss-myhostname for Debian
 and uploaded it. It will have to pass through the NEW queue and will
 then be installable via apt-get on Debian. Thanks for creating this nice
 piece of software.

I'll second the thanks for creating it, and add my thanks to Joachim for
packaging it.

- Josh Triplett



-- 
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/20100508035547.ga11...@feather

Bug#574800: RFP: libnss-myhostname -- nss module to resolve the system hostname

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: libnss-myhostname
  Version : 0.2
  Upstream Author : Lennart Poettering mzzlubfga...@0pointer.de
* URL : http://0pointer.de/lennart/projects/nss-myhostname/
* License : LGPLv2.1
  Programming Lang: C
  Description : nss module that resolves the system hostname instead of 
/etc/hosts

nss-myhostname is a plugin for the GNU Name Service Switch (NSS) functionality
of the GNU C Library (glibc) providing host name resolution for the locally
configured system hostname as returned by gethostname(2). A lot of software
relies on resolving the local host name via DNS to an IPv4 or IPv6 address.
Most systems resolve the system hostname via /etc/hosts, which either
duplicates /etc/hostname or requires dynamically editing /etc/hosts.
nss-myhostname automatically resolves the current system hostname to the IPv4
address 127.0.0.2 (which is on the local loopback) and the IPv6 address ::1.



-- 
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/20100321054733.2727.47394.report...@feather

Bug#556135: RFP: xul-ext-weave -- Syncronize personal data between Mozilla browsers

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: xul-ext-weave
  Version : 0.8
  Upstream Author : Mozilla
* URL : https://mozillalabs.com/weave/
* License : Standard Mozilla tri-license: MPL, GPLv2+, LGPLv2.1+
  Programming Lang: XUL, JavaScript, C++
  Description : Syncronize personal data between Mozilla browsers

Mozilla Weave securely shares and synchronizes personal data between
Mozilla browsers running on different systems.  In particular, Weave can
synchronize bookmarks, history, passwords, open tabs, and user
preferences.  Weave uses encryption to keep data secure on the server,
decrypting it using a passphrase.



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

Bug#551955: RFP: ttf-anonymous-pro -- A fixed-width sans-serif font designed especially for coders

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: ttf-anonymous-pro
  Version : 1.001
  Upstream Author : Mark Simonson m...@ms-studio.com
* URL : http://www.ms-studio.com/FontSales/anonymouspro.html
* License : SIL Open Font License
  Description : A fixed-width sans-serif font designed especially for coders

Anonymous Pro is a family of four fixed-width fonts designed especially with
coding in mind. Characters that could be mistaken for one another (O, 0, I, l,
1, etc.) have distinct shapes to make them easier to tell apart in the context
of source code.

Anonymous Pro also features an international, Unicode-based character set, with
support for most Western and European Latin-based languages, Greek, and
Cyrillic. It also includes special box drawing characters for those who need
them.

/long-description

I spoke with Mark Simonson previously about releasing his freeware font
Anonymous Pro as FOSS.  He had apparently considered the idea before
that as well.  I just discovered that Mark generously released Anonymous
Pro under the Open Font License recently.  To encourage widespread usage
and distribution of this excellent font, I've filed this RFP requesting
a package for Debian.

Thank you, Mark!  And thank you to whoever ends up packaging this for
Debian.

- Josh Triplett



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

Bug#551955: RFP: ttf-anonymous-pro -- A fixed-width sans-serif font designed especially for coders

[Josh Triplett]

A followup note about packaging this font: Anonymous Pro includes
embedded bitmaps for several sizes, so the font packaging should ideally
include fontconfig rules that enable the embedded bitmaps as
appropriate.

- Josh Triplett



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

Bug#509850: RFP: haskell-curl -- Haskell bindings to the libcurl URL transfer library

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: haskell-curl
  Version : 1.3.3
  Upstream Author : Sigbjorn Finne
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl
* License : BSD (3-clause)
  Programming Lang: Haskell
  Description : Haskell bindings to the libcurl URL transfer library

This package provides the Haskell Network.Curl bindings to the libcurl
client-side URL transfer library.

- Josh Triplett

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)



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

Bug#509182: RFP: haskell-fastcgi -- Haskell interface to FastCGI

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: haskell-fastcgi
  Version : 3001.0.2.2
  Upstream Author : Bjorn Bringert bj...@bringert.net
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fastcgi
* License : 3-clause BSD
  Programming Lang: Haskell
  Description : Haskell interface to FastCGI

This package provides the Haskell module Network.FastCGI, a Haskell
interface to FastCGI.  FastCGI provides an interface between web servers
and CGI programs that runs the CGI program as a long-running server
which services many requests.  Network.FastCGI provides an interface
almost identical to Network.CGI, making it easy to port existing Haskell
CGI programs to FastCGI.



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

Bug#504266: RFP: darwin-calendar-server -- CalDAV calendar server

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: darwin-calendar-server
  Version : 1.3
  Upstream Author : Apple
* URL : http://calendarserver.org/
* License : Apache License 2.0
  Programming Lang: Python
  Description : CalDAV calendar server

Darwin Calendar Server provides a collaborative shared calendar using
the standard CalDAV protocol.  Many calendaring programs support
synchronizing their calendar with a CalDAV server.

Note that Darwin Calendar Server uses filesystem extended attributes
(xattrs), so you must enable xattrs on the filesystem used to store
the calendar data.



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

Bug#482938: RFP: foxmarks -- Synchronize bookmarks between multiple systems running Firefox or Iceweasel

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: foxmarks
  Version : Stable 2.0.45, beta 2.0.44.20
  Upstream Author : Foxmarks Inc.
* URL : http://foxmarks.com/
* License : Apache License, Version 2.0
  Programming Lang: XUL and JavaScript
  Description : Synchronize bookmarks between multiple computers running 
Firefox or Iceweasel

Foxmarks synchronizes bookmarks between multiple computers running
Firefox or Iceweasel.  It stores bookmarks via your
account on the Foxmarks server, also accessible via the web at
http://my.foxmarks.com.  It can also store bookmarks on any server
running WebDAV.


The stable version 2.0.45 seems like the safest choice to package.
Foxmarks has a version for Firefox 3 in beta, and packaging that for
experimental might make sense, but it seems easier to just wait for
the stable version to support Firefox 3, which it almost certainly
will by the time the stable release of Firefox 3 occurs.

The binary package should have the name iceweasel-foxmarks or
mozilla-foxmarks; probably the former.

- Josh Triplett

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

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



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

Bug#470369: RFP: haskell-tagsoup -- Haskell library to robustly parse non-standards-compliant HTML

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: haskell-tagsoup
  Version : 0.4
  Upstream Author : Neil Mitchell [EMAIL PROTECTED]
* URL : http://www-users.cs.york.ac.uk/~ndm/tagsoup/
* License : 3-clause BSD
  Programming Lang: Haskell
  Description : Haskell library to robustly parse unstructured HTML

TagSoup extracts information out of unstructured HTML code, sometimes
known as tag soup. TagSoup does not require well-formed or
standards-compliant HTML, or HTML that renders correctly in any
particular rendering engine.  TagSoup transforms HTML into a list of
open tags with attributes, close tags, and text, but makes no attempt
to group these together into any kind of structure.

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

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#456165: RFP: handbrake -- Rips and encodes DVDs

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: handbrake
  Version : 0.9.1
  Upstream Author : Various; see http://handbrake.m0k.org/?article=development
* URL : http://handbrake.m0k.org/
* License : GPL
  Programming Lang: C
  Description : Rips and encodes DVD videos

Handbrake provides a friendly graphical interface for ripping DVD
videos and encoding them as video files.  It can show a preview of
content before ripping, to verify titles and chapters.  It can
deinterlace, crop, and scale video.  It supports DVD subtitles by
encoding them directly in the video image.
..
Handbrake supports numerous formats and codecs:
 - File format: MPEG-4 (MP4), Matroska (MKV), Ogg (OGM), or AVI
 - Video: MPEG-4 or H.264 (1 or 2 passes or constant quantizer/rate
   encoding)
 - Audio: AAC, MP3, Vorbis or AC-3 pass-through (supports encoding of
   several audio tracks)
..
Handbrake also provides a command-line interface, HandbrakeCLI.


Some notes on Handbrake:

* Its build system needs some serious work.  It wants to download and
  build all its dependencies at build time, and statically link to
  those copies.  (I have not actually managed to get it to build, due
  to build errors in one of these libraries.)  This will need to
  change to support dynamically linking to system libraries.

* Some of the libraries it depends on do not exist in Debian due to
  legal problems such as patent issues or anti-circumvention laws.
  For libdvdcss, ideally it could do the same thing all the DVD
  players in Debian do: use libdvdread (which Handbrake already does),
  and let libdvdread pull in libdvdcss if installed.  For encumbered
  codecs, ideally it could pick up libraries if installed and disable
  the corresponding codecs if not; however, if it cannot, then perhaps
  it could have a DEB_BUILD_OPTIONS=risky like ffmpeg.

* Build-Depends available in Debian: jam, liba52-0.7.4-dev,
  libavcodec-dev, libdvdread3-dev, libmpeg2-4-dev, libogg-dev,
  libvorbis-dev, libsamplerate0-dev

- Josh Triplett

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

Kernel: Linux 2.6.22-rc1 (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#452026: RFP: golly -- Game of Life simulator using hashlife algorithm

[Josh Triplett]

Package: wnpp
Severity: wishlist

* Package name: golly
  Version : 1.3
  Upstream Author : Tomas Rokicki [EMAIL PROTECTED]
Andrew Trevorrow [EMAIL PROTECTED]
* URL : http://golly.sourceforge.net/
* License : GPL version 2 or later
  Programming Lang: C++, with Python scripting support
  Description : Game of Life simulator using hashlife algorithm

 Golly simulates Conway's Game of Life with an arbitrarily large grid
 of cells.  It can optionally use a hashlife algorithm, which allows
 it to rapidly compute generations for huge patterns, and to compute
 many generations into the future at a time.
 .
 Golly provides a graphical interface for viewing and editing cellular
 automata.  It supports copy and paste, zoom, auto-fit, multiple
 layers, and viewing different areas of a pattern simultaneously in
 different areas of a window.
 .
 Golly can load patterns from RLE, Life 1.05/1.06, dblife, and
 macrocell file formats; it can also interpret images as Life
 patterns.  Golly provides integrated help, including a copy of the
 Life Lexicon.
 .
 Golly also supports other rules for 2D cellular automata with an
 8-cell neighborhood, and supports 1D cellular automata.

(end of description)

Some notes:

* Golly has some serious portability issues: in particular, it
  generates many compiler errors if sizeof(node *) != sizeof(int).
  Much of this seems to occur in the hash table code when hashing
  pointer values, so in theory it might not cause a problem if made to
  go away via appropriate casting.

* Golly uses wxWidgets, and supports building for either X11 or GTK+;
  however, the authors specifically recommend against the X11 version,
  so I'd suggest only packaging the GTK+ version.

* Golly runs extremely fast, and the hashlife algorithm makes many
  complex patterns easy to simulate.  On my system, I could easily
  simulate a 3x3 grid of Unit Life cells running a blinker, with one
  Unit Life generation per step, in real-time.  I could also take any
  of the patterns from Golly's database and run it to 1e10 generations
  with no problems, even those with asymptotically quadratic growth.

* The interface beats xlife hands down.

- Josh Triplett



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

Bug#396648: ITP: rt73 -- Linux device driver for Ralink RT73 a/b/g WLAN Card

[Josh Triplett]

Piotr Roszatycki wrote:
 The driver loads firmware from separate file and has included
 the blob with the default firmware if separate file is not available.
 
 I think the driver can go to contrib with removed the blob from its sources

Yes.

 and with the firmware rt73.bin file can go to non-free as rt73-firmware 
 package.

 The rt73.bin file is marked as GPL. There is no real source code included but
 this license implies that it is redistributable file at least as non-free.

No.  Distribution of a GPLed binary requires provision of the preferred form
for modification; if Debian does not have that, Debian cannot distribute the
firmware at all.

Also, does the binary have an explicit GPL license attached (some file
specifically says that the firmware falls under the GPL, and/or the version in
the driver source has a GPL header above the firmware binary), or does it just
reside in the driver next to all the GPLed source and a copy of the GPL?  If
the latter, it may not actually fall under the GPL, and you should request a
specific license for it.  (Whether or not upstream intended it as GPLed does
not affect distributability, but it does affect how you approach upstream; in
one case you just need to ask about a license for the firmware, and in the
other case you need to explain the issues about GPLing a binary.  Also, as
usual, throwing in a request for the source as a lark couldn't hurt; worst
case, they say no, no harm done.)

One other question: do all variants of this device require firmware from the
driver, or only some of them?  (Just asking because several other ralink cards,
such as rt2500, do not seem to require the driver to supply firmware.)  If
some variants of the device will work without supplied firmware, then the
driver can go to main, regardless of where or if the firmware gets distributed.

- Josh Triplett



signature.asc
Description: OpenPGP digital signature

Bug#358558: byzanz packaging

[Josh Triplett]

I also have Debian packaging for byzanz, available at
http://minilop.net/~josh/byzanz/ .  Among other things, it includes a
manpage I wrote for the byzanz-record command-line utility, and a
debian/watch file.  Would you have any interest in co-maintaining Debian
packaging for byzanz?

CCed to Daniel Holbach since he may want to include the manpage in the
Ubuntu package.  I've already emailed the manpage upstream, along with
two bugfixes: a typo in configure.ac, and the fact that COPYING contains
the GPL but the source files indicate LGPL licensing.

- Josh Triplett



signature.asc
Description: OpenPGP digital signature

Bug#284190: ITP: drdsl -- DSL Assistant for AVM DSL/ISDN-Controllers

[Josh Triplett]

Matthias Klose wrote:
 Josh Triplett writes:
Matthias Klose wrote:

CC'ing debian-legal, please could you have a look at the license?

The question being is this acceptable to go into non-free?
 
 exactly.

OK.

 I asked to clarify the paragraph, the current text now has append and
 the terms of the LGPL.
 
 The Proprietary Source Software, which is delivered in object code
 format only, such as the .o files, shall in no event be
 disassembled, reverse engineered, decompiled or otherwise be opened
 and the results realised insofar shall not be copied or distributed
 without the prior written approval of AVM except to the extent as may
 be expressly authorized under mandatory law and the terms of the LGPL.

With this addition, the software can be distributed in non-free.

- Josh Triplett


signature.asc
Description: OpenPGP digital signature

Bug#284190: ITP: drdsl -- DSL Assistant for AVM DSL/ISDN-Controllers

[Josh Triplett]

Matthias Klose wrote:
 CC'ing debian-legal, please could you have a look at the license?

The question being is this acceptable to go into non-free?

[...]
 The available AVM driver package consists of two portions, namely an Open
 Source Software portion and a Proprietary Source Software portion. The
 Proprietary Source Software portion is delivered in object code format only
 and includes i.e. the lib.o files which, again, include libraries as well
 as specific portions of the driver. The Open Source Software portion is
 licensed under the terms and conditions of the GNU Lesser GPL (LGPL).
 Please be aware of the requirements of the LGPL. You may easily download
 the terms of the LGPL as follows:
 http://www.gnu.org/copyleft/lesser.html.
 
 On Debian GNU/Linux systems, the complete text of the GNU Lesser General
 Public License can be found in `/usr/share/common-licenses/LGPL'.
 
 In general, you may distribute both portions of the available AVM driver
 package, i.e. on a distribution CD delivered in conjunction with your
 products. In addition to the terms of the LGPL and under all AVM
 intellectual property and proprietary rights, AVM grants you the worldwide,
 non-exclusive and royalty-free rights

  (1)   to use and copy 

  (2)   to make (and have made), use, import, sell, offer for sale or   
otherwise distribute any of your (legal) products or services   
containing (portions of) the AVM driver package, and

  (3)   to sublicense rights to the extend a license is necessary for using 
your products or services.  

Up to this point, the license seems acceptable for non-free; it seems to
permit redistribution of the binary-only portion, and the LGPLed portion
is of course acceptable.  However:

 The Proprietary Source Software, which is delivered in object code format
 only, such as the .o files, shall in no event be disassembled, reverse
 engineered, decompiled or otherwise be opened and the results realised
 insofar shall not be copied or distributed without the prior written
 approval of AVM except to the extent as may be expressly authorized under
 mandatory law.

This condition is incompatible with the GNU LGPL.  Clause 6 of the LGPL
states in part:
   6. As an exception to the Sections above, you may also combine or
 link a work that uses the Library with the Library to produce a
 work containing portions of the Library, and distribute that work
 under terms of your choice, provided that the terms permit
 modification of the work for the customer's own use and reverse
 engineering for debugging such modifications.

It goes on to state that distributing object code for relinking is
acceptable, as AVM does.  However, the license on the work as a whole,
including the .o files, does not permit modification of the work for
the customer's own use and reverse engineering for debugging such
modifications.

The result is that neither the .o files which link to the library nor
any compiled binary from both the .o files and the library can be
distributed.

 It is understood that you will be responsible/liable for the software which
 you offer/distribute/make available in conjunction with or which you
 combine with (portions of) the AVM driver package. For instance, we refer
 to the implications mentioned in the LGPL in case of a breach (your rights
 granted under LGPL would terminate automatically, see Art. 4 LGPL).  You
 should state clearly that you offer any necessary support on your own.

This clause doesn't look like a problem.


Summary: non-distributable, because the license on the proprietary
portion does not permit modification of the work for the customer's own
use and reverse engineering for debugging such modifications, which is
incompatible with the LGPLed portion.

- Josh Triplett


signature.asc
Description: OpenPGP digital signature

Bug#278940: ITP: socket++ -- lightweight convenience library to handle low level BSD sockets in C++

[Josh Triplett]

Dan Weber wrote:
 * Package name: socket++
   Version : 1.12.12
   Upstream Author : Gnanasekaran(Sekar) Swaminathan [EMAIL PROTECTED],
   Herbert Straub [EMAIL PROTECTED]
 * URL : http://www.linuxhacker.at/socketxx
 * License : Pasted below with License Statement
   Description : lightweight convenience library to handle low level BSD 
 sockets in C++
 
[snip long description]

 -- License
 
 Original Copyright Notice:
 
 Permission is granted to use at your own risk and distribute this software
 in source and  binary forms provided  the above copyright notice and  this
 paragraph are  preserved on all copies.  This software is provided as is
 with no express or implied warranty.

This license alone would not be sufficient, since it does not allow
modification.  However...

 Copyright Statement:
 
Got your message. Please feel free to include it in
any software and use it as you please. Let me know if
you need any help with it.
 
 and further:
 +++
 Hi Herbert,
 
 That was not the intention. It is a free code. You can modify,
 copy, and distribute and use it in anyway as you see fit.
 
 Other people are maintaining it and ported it to different
 OSes. Other than that, not much has changed as far as I know.
 I haven't looked at it recently.
 
 -Sekar

... this clarification makes the software clearly DFSG-Free (though it
would be preferable if this mail explicitly referred to socket++ and not
just it :) ).

 -- Side Note
 
 This ITP is being cross posted to debian-legal for the purpose of verifying
 that this is capable of being placed in main.

Definitely.  Be sure to include the clarification in the copyight file
along with the original license.

- Josh Triplett


signature.asc
Description: OpenPGP digital signature

Bug#251885: ITP: cgal -- C++ library for computational geometry

[Josh Triplett]

Joachim Reichel wrote:
 If the two licenses only applied to different libraries that linked to
 each other, they would be compatible, because the scope of the LGPL
 deliberately stops at the library boundary.  However, the LGPL requires
 that all code which directly incorporates LGPLed code be LGPLed.
 [...]
 So any work based on the library must be licensed under the LGPL.
 Since the QPL is not compatible with the LGPL, the entire work is
 non-distributable.
 
 So what are the options for upstream?
 
 a) Relicense the code in a way that the work is redistributable, if
 possible DFSG-free.

That would work.  Note that if upstream likes the QPL, they would not
need to give it up completely; they could choose to dual-license the
work under the LGPL and the QPL, or under the GPL and the QPL, or under
any other Free license and the QPL.  As long as one of the license
options is a Free Software license.

 b) Split the library in (at least) two libraries, one (or more) for the
 LGPL code and one (or more) for the QPL code. (By splitting, I mean
 creating two (or more) static/dynmaic libraries, not splitting the
 package itself.)

That would work, but the resulting package would go into non-free, since
it uses the QPL.

 c) What about clause 7 of the LGPL:
 
   7. You may place library facilities that are a work based on the
 Library side-by-side in a single library together with other library
 facilities not covered by this License, and distribute such a combined
 library, provided that the separate distribution of the work based on
 the Library and of the other library facilities is otherwise
 permitted, and provided that you do these two things:

 a) Accompany the combined library with a copy of the same work
 based on the Library, uncombined with any other library
 facilities.  This must be distributed under the terms of the
 Sections above.

I think this would mean accompany in the same package, so this is
basically the same as the previous option, except that you could also
provide a combined library.  Again, the resulting package would go into
non-free.

 b) Give prominent notice with the combined library of the fact
 that part of it is a work based on the Library, and explaining
 where to find the accompanying uncombined form of the same work.
 
 For clarification, as I understand it:
 Library = LGPL-part of the code
 library = the dynamic/static library (including QPL code)
 
 Would this be another option? Is there a piece of software that actually
 uses this clause?

 d) What about an exception with respect to clause 2c) of the LGPL?
 Something similar like the GPL-waiver for libssl? This would also be an
 option, right?

Assuming the authors hold the copyright to the entire work (meaning that
they didn't incorporate any other LGPLed code), that would work.  See
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs for details
on the exception, and modify it to work with the LGPL instead of the
GPL.  Again, this option would only let the package go into non-free.

- Josh Triplett

Bug#251885: ITP: cgal -- C++ library for computational geometry

[Josh Triplett]

Joachim Reichel wrote:
 License:
 The library consists of three modules. The lower layers (Kernel and the
 Support library) are licensed under LGPL, the upper layer (Basic Library) is
 licensed under QPL. Code under LGPL and code under QPL is combined in one
 library.
 
 I've CC'ed debian-legal and I would like to know whether both licenses are
 compatible.

If the two licenses only applied to different libraries that linked to
each other, they would be compatible, because the scope of the LGPL
deliberately stops at the library boundary.  However, the LGPL requires
that all code which directly incorporates LGPLed code be LGPLed.
From the LGPL, version 2.1:
   The precise terms and conditions for copying, distribution and
 modification follow.  Pay close attention to the difference between a
 work based on the library and a work that uses the library.  The
 former contains code derived from the library, whereas the latter must
 be combined with the library in order to run.
[...]
   The Library, below, refers to any such software library or work
 which has been distributed under these terms.  A work based on the
 Library means either the Library or any derivative work under
 copyright law: that is to say, a work containing the Library or a
 portion of it, either verbatim or with modifications and/or translated
 straightforwardly into another language.  (Hereinafter, translation is
 included without limitation in the term modification.)
[...]
   2. You may modify your copy or copies of the Library or any portion
 of it, thus forming a work based on the Library, and copy and
 distribute such modifications or work under the terms of Section 1
 above, provided that you also meet all of these conditions:
 
 a) The modified work must itself be a software library.
 
 b) You must cause the files modified to carry prominent notices
 stating that you changed the files and the date of any change.
 
 c) You must cause the whole of the work to be licensed at no
 charge to all third parties under the terms of this License.
[...]

So any work based on the library must be licensed under the LGPL.
Since the QPL is not compatible with the LGPL, the entire work is
non-distributable.

The other issue here is that the QPL is not a Free Software license at
all.  See the thread starting at
http://lists.debian.org/debian-legal/2004/04/msg00233.html for
details.  The QPL requires that all changes are sent to the original
author upon request, and that all license disputes are settled in
Amsterdam City Court by the laws of the Netherlands.  Both of these
restrictions are non-DFSG-free.

I would suggest asking the authors to dual-license their library under
the QPL and the GPL, like Trolltech did with Qt.  In addition to solving
the freeness and compatibility problems, this would also makes the
library GPL-compatible, which allows the huge number of GPLed programs
to link with the library.

(Incidentally, the libcwd package which raised the issue of the QPL
seems to have been uploaded to main even after that discussion concluded
that the license was non-free.)

- Josh Triplett