Bug#898931: Fwd: Bug#898931: Acknowledgement (ITP: looking-glass -- An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough)

[Lennart Weller]

And another upstream release before I could find a sponsor.


* Package name : looking-glass
  Packaging link : https://salsa.debian.org/lhw-guest/looking-glass
  Version : 0+a12
  Upstream Author : Geoffrey McRae 
* URL : https://github.com/gnif/LookingGlass
* License : GPL2+
  Programming Lang: C
  Description : An extremely low latency KVM FrameRelay implementation for 
guests with VGA PCI Passthrough

Bug#898931: Acknowledgement (ITP: looking-glass -- An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough)

[Lennart Weller]

A few things have changed since the initial ITP.
The package had license issues which have been resolved upstream.
The packaging is already finished and available at the link below.

* Package name: looking-glass
  Packaging link  : https://salsa.debian.org/lhw-guest/looking-glass
  Version : 0+a11
  Upstream Author : Geoffrey McRae 
* URL : https://github.com/gnif/LookingGlass
* License : GPL2+
  Programming Lang: C
  Description : An extremely low latency KVM FrameRelay implementation for 
guests with VGA PCI Passthrough

Bug#898931: ITP: looking-glass -- An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller <l...@ring0.de>

* Package name: looking-glass
  Version : 0+a10
  Upstream Author : Geoffrey McRae <ge...@hostfission.com>
* URL : https://github.com/gnif/LookingGlass/
* License : GPL2+ with OpenSSL Exception
  Programming Lang: C
  Description : An extremely low latency KVM FrameRelay implementation for 
guests with VGA PCI Passthrough

LookingGlass enables you to use shared memory to pass rendered frames from a
virtual machine back to the host system. This is exceptionally useful
for IOMMU/VFIO graphics card passthrough setups.

Bug#885661: ITP: cli-helpers -- Helper library for creating Python CLI applications

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller <l...@ring0.de>

* Package name: cli-helpers
  Version : 1.0.1
  Upstream Author : Amjith Ramanujam <amjit...@gmail.com>
* URL : http:github.com/dbcli/cli_helpers
* License : BSD-3-clause
  Programming Lang: Python
  Description : Helper library for creating Python CLI applications

A Python package that makes it easy to perform common tasks when
building command-line apps.

Mostly needed for the newer versions of mycli and pgcli

Bug#725396: RFS: network-manager-ssh/0.9.4-1 [ITP] - ssh vpn for network manager

[Lennart Weller]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "network-manager-ssh"

 * Package name: network-manager-ssh
   Version : 0.9.4-1
   Upstream Author : Dan Fruehauf <malko...@gmail.com>
 * URL : https://github.com/danfruehauf/NetworkManager-ssh
 * License : GPL-2+
   Section : net

It builds those binary packages:
network-manager-ssh - network management framework (SSH plugin core)
network-manager-ssh-gnome - network management framework (SSH plugin 
GNOME GUI)

To access further information about this package, please visit the following 
URL:
http://mentors.debian.net/package/network-manager-ssh

Alternatively, one can download the package with dget using this command:
dget -x 
http://mentors.debian.net/debian/pool/main/n/network-manager-ssh/network-manager-ssh_0.9.4-1.dsc

More information about hello can be obtained from 
https://github.com/danfruehauf/NetworkManager-ssh

Changes since the last upload:
  * Initial release. (Closes: #725396)

Regards,
 Lennart Weller

Bug#725396:

[Lennart Weller]

This sounds like a nice plugin. I would package it if nobody else is working on 
it.

Bug#794250: pgcli packaging progress

[Lennart Weller]

Hey,

I already finished the packaging a while back when pgcli didn't need pgspecial 
yet.
I just updated my version to 0.20.1 and added a reference to your package in my 
git[1] and also added the git-dpm stuff.

My normal sponsor is currently really busy and I myself was too, so I hadn't 
looked for someone else to sponsor it.
I would prefer uploading it to collab-maint git and in case it is still a 
requirement for PAPT then do a subversion
export from there.

So to answer your questions. Still interested in maintaining or co-maintaining 
pgcli but I do need a sponsor for it. I also need one for mycli in case you are 
interested (same developer just mysql/mariadb).

Lennart

[1] https://git.ring0.de/debian/python-pgcli

November 23 2015 5:15 PM, "ChangZhuo Chen"  wrote:
> Hi Lennart,
> 
> Are you still interesting in pgcli packaging? I am working on its
> dependency python-pgspecial [0], and it will be ready once the upstream
> fix the license issue [1].
> 
> Please let me know if you need help or sponsor.
> 
> [0] https://bugs.debian.org/805882
> [1] https://github.com/dbcli/pgspecial/issues/7
> 
> -- 
> ChangZhuo Chen (陳昌倬) 
> Debian Developer
> Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D

Bug#794251: need to update python-pymysql ?

[Lennart Weller]

Potentially yes. I'm currently trying to get it to work with 0.6.2, if you want 
you can follow that progress
on the github tracker[0]. Otherwise I will have no choice but to ask the 
PyMySQL-maintainers to update the
debian version.

Lennart

[0] https://github.com/dbcli/mycli/issues/155

September 22 2015 12:30 PM, j...@free.fr wrote:
> Traceback (most recent call last):
> File "/usr/bin/mycli", line 5, in 
> from pkg_resources import load_entry_point
> File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2876, in 
> 
> working_set = WorkingSet._build_master()
> File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 451, in 
> _build_master
> return cls._build_from_requirements(__requires__)
> File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 464, in 
> _build_from_requirements
> dists = ws.resolve(reqs, Environment())
> File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 639, in resolve
> raise DistributionNotFound(req)
> pkg_resources.DistributionNotFound: PyMySQL>=0.6.6

Bug#797654: ITP: s3backer -- Amazon AWS S3-backed virtual hard disk device

[Lennart Weller]

September 1 2015 5:27 PM, "Nikolaus Rath" <nikol...@rath.org> wrote:
> Why compare it with something that has been unmaintained for years and is
> not even in Debian? (Leaving alone the fact that there are at least 3
> projects calling themselves s3fs, but AFAIK they're all in similar
> states).
> 
> Contrasting it with something like S3QL would probably be more helpful
> :-).

As you said there are three different projects with the name s3fs. But the one 
I was
referring to, s3fs-fuse[1], is actively maintained while s3fs (python)[2] and 
s3fslite[3] are not.
The name doesn't really matter though as the approach of all of them and S3QL 
is pretty much the same.
Create an S3 based filesystem.

s3backer on the other hand exposes just a single "block" device to the system 
and allows common filesystems
to be used on top of it. I kinda like that approach so I went with it.

Cheers,
Lennart Weller


[1] https://github.com/s3fs-fuse/s3fs-fuse
[2] https://fedorahosted.org/s3fs/
[3] https://github.com/russross/s3fslite

Bug#797654: ITP: s3backer -- Amazon AWS S3-backed virtual hard disk device

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller <l...@ring0.de>

* Package name: s3backer
  Version : 1.4.1
  Upstream Author : Archie L. Cobbs <arc...@dellroad.org>
* URL : https://www.github.com/archiecobbs/s3backer
* License : GPL, OpenSSL
  Programming Lang: C
  Description : Amazon AWS S3-backed virtual hard disk device

s3backer is a filesystem that contains a single file backed by the Amazon
Simple Storage Service (Amazon S3). The blocks of the file are stored as S3
objects. This way s3backer acts as a virtual hard disk device. s3backer also
offers encryption as part of the VHD.

s3backer offers some great benefits over s3fs as any filesystem can be used on
top of the VHD removing all inconsistencies which might occur with a naive
implementation of a filesystem.

Currently there is a license conflict between the GPL code and OpenSSL. I have
forwarded some of the common solutions to the upstream author.

Bug#794570: ITP: python-prompt-toolkit -- Python library for building interactive command lines

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller l...@ring0.de

* Package name: python-prompt-toolkit
  Version : 0.45
  Upstream Author : Jonathan Slenders
* URL : https://github.com/jonathanslenders/python-prompt-toolkit
* License : BSD-3-clause
  Programming Lang: Python
  Description : Python library for building interactive command lines

prompt_toolkit is a GNU readline replacement written in pure Python supporting
 advanced features like syntax highlighting, multi line editing and code
 completion.

The package is a dependency of pgcli and mycli (#794250, #794251)


-- 
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/20150804142314.21415.53080.report...@lhw.ring0.de

Bug#794250: ITP: pgcli -- CLI for PostgreSQL with syntax highlighting and completion

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller l...@ring0.de

* Package name: pgcli
  Version : 0.18.0
  Upstream Author : Amjith Ramanujam amjit...@gmail.com
* URL : http://pgcli.com/
* License : BSD-3-clause
  Programming Lang: Python
  Description : CLI for PostgreSQL with syntax highlighting and completion

This is a PostgreSQL client that does auto-completion and syntax highlighting.
The CLI is also capable of pretty printing tabular data

Reasons for ITP:
Usefuly utility for people who like to do their SQL work on the Shell.
I intend to maintain this with either sponsorship from PATP or my personal 
sponsor.


-- 
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/20150731171957.29633.26292.report...@lhw.ring0.de

Bug#794251: ITP: mycli -- CLI for MySQL/MariaDB with syntax highlighting and completion

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller l...@ring0.de

* Package name: mycli
  Version : 1.0.1
  Upstream Author : Amjith Ramanujam amjit...@gmail.com
* URL : http://mycli.net
* License : BSD-3-clause
  Programming Lang: Python
  Description : CLI for MySQL/MariaDB with syntax highlighting and 
completion

This is a MySQL/Mariadb client that does auto-completion and syntax
highlighting. The CLI is also capable of pretty printing tabular data

Reasons for ITP:
Usefuly utility for people who like to do their SQL work on the Shell.
I intend to maintain this with either sponsorship from PATP or my personal 
sponsor.


-- 
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/20150731172211.30047.55061.report...@lhw.ring0.de

Bug#792228: ITP: termdebug -- Tools for recording and replaying terminal I/O

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller l...@ring0.de

* Package name: termdebug
  Version : 2.2
  Upstream Author : G.P Halkes 
* URL : http://os.ghalkes.nl/termdebug.html
* License : GPL-3
  Programming Lang: C
  Description : Tools for recording and replaying terminal I/O

Termdebug is a set of utilities to record and replay the input and output of
terminal programs. Its main goal is to aid in developing and debugging terminal
programs.

Similar to termrec/termplay and nethack-recorder/player, neither of which is
packaged for debian, but also records terminal input.


-- 
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/20150712221234.27048.60723.report...@lhw.ring0.de

Bug#667989: ITP: s2tc -- S2TC is a patent-free S3TC compatible texture compression

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart l...@ring0.de


* Package name: s2tc
  Version : 0~git20110809 
  Upstream Author : Rudolf Polzer divver...@alientrap.org
* URL : https://github.com/divVerent/s2tc 
* License : MIT/X11 
  Programming Lang: C/C++ 
  Description : S2TC is a patent-free S3TC compatible texture compression 
implementation

 S2TC is a patent-free S3TC compatible implementation and provides
 texture compression to Mesa. The package also includes tools to 
 compress/decompress S2TC textures and convert S3TC textures to
 S2TC ones using the patent-free algorithm.



-- 
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/20120407210739.8751.39434.reportbug@nas.local

Bug#594800: (no subject)

[Lennart Weller]

The nvidia-texture-tools are now in debian unstable[1]. If you need any
help with creating the package for 0ad drop me a message and I will see
how I can be of assistance to you.

[1] http://packages.debian.org/source/sid/nvidia-texture-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/4f7b8308.1000...@ring0.de

Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools

[Lennart Weller]

Am 29.03.2012 02:17, schrieb Paul Wise:
 On Wed, 2012-03-28 at 22:40 +0200, Lennart Weller wrote:
 
 Because I did not plan to have it submitted to debian when I
 created it for my ubuntu ppa.
 
 Hmm, OK.
 
 In what way do you think it's broken? Also I did submit [1] the
 patch for the library versioning but it got ignored so far. Every
 software which would benefit from the library currently uses the
 two year old version 2.0.8 and there is more then one open
 request so why should the library be hidden from the system?
 
 Firstly, source code version and SONAME are completely different
 things. There is no reason to start the SONAME at 2, it should
 start at 0. Secondly, if upstream is not producing properly
 versioned shared libraries, it is very inappropriate to trample
 their SONAME name-space and much better to use a Debian-specific
 SONAME. If upstream chooses 0 as the SONAME and then makes two new
 releases with an incompatible ABI, they will be up to SONAME 2
 which will be ABI incompatible with the Debian SONAME 2.

The SONAME starting with 2 was suggested by my supporter and I
understand the reasoning for it. The upstream developer seems to only
break ABI in major versions and if someone creates a package for
version 1.* than there won't be any conflicts. Also the upstream
package does not contain any SO versioning for the current stable
release. But I will contact the upstream developer about these concerns.

 02-multiarch.patch looks like it *does* need forwarding.
 This way of implementing multi-arch support is debian specific so
 I don't think upstream would need this. Which is also written in
 the abstract of the patch. Building the library with this patch
 would definitely go against the the multi-arch solution of e.g.
 RHEL-based distributions.
 
 I don't know CMake that well but it appears that upstream is
 incorrectly hard-coding the lib install directory. Anyone wanting
 to customise the library dir will get the wrong result. RHEL/Fedora
 distributions don't support proper multi-arch, they only have
 bi-arch (aka multilib). When they start switching to proper 
 multi-arch, they are going to need that patch so it is best to get
 it upstream now.

In the upstream version you can currently choose the PREFIX of the
installation but it will always be installed to PREFIX/lib. That was
fixed by my patch. But as I said I will talk with the upstream author
and try to have it added to his version.

 I used this naming scheme because it is frequently used by other
  libraries like libc-bin, ncurses-bin, libnotify-bin,
 libglib2.0-bin and so on. Of course I'm free to any suggestions
 on this part.
 
 Well, ultimately the library isn't the most important part of the 
 package, the important bit is the command-line tools and they
 should be named appropriately. The libraries come from an embedded
 code copy of nvidia-oss, not from nvidia-texture-tools itself. I
 would say the name of the package with the binaries should reflect
 the above.
 
 Embedded code copies are discouraged in Debian. There are also the 
 libsquish and poshlib embedded code copies. Please inform the
 security team about these issues if the package reaches the
 archive.
 
 http://wiki.debian.org/EmbeddedCodeCopies 
 http://code.google.com/p/nvidia-oss/ 
 http://code.google.com/p/libsquish/ http://hookatooka.com/poshlib/
 
 In addition, libsquish can be built with SSE or Altivec on the 
 appropriate platforms, increasing its speed. By embedding
 libsquish, nvidia-texture-tools is missing out on that speed-up.
 Since

As you can see in the nvidia-oss repository there was no changeset
since 2009 where
as nvidia-texture-tools received changes to former nvidia-oss
directories upto the stable
release in 2010 and is still being updated for the next release. Thats
why I didn't use the nvidia-oss version. With the other libraries you
have a fair point and I will package them seperatly for the next
upstream release.

 I removed gnuwin32 binary files, auto-generated Visual Studio
 project files (because they had no license header and were not
 necessary) and a custom configure script which broke automatic
 cmake building and basically called just cmake in the first
 place. I will look into it to add this information to the
 package.
 
 You should have a get-orig-source debian/rules target to
 automatically build/repack the tarball. Please see debian-policy
 for info on that.

Okay I will look into that and add the target.

 I guess you missed removal of the non-free nvidia logo?
Those icons were also inside the visual studio project directories. I
didn't even notice that I erased them as the whole directory structure
wasn't important to the 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/4f74a041.3020...@ring0.de

Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools

[Lennart Weller]

Am 29.03.2012 14:10, schrieb Fabio:
 If you are packaging 2.0.8 please have a look at the README.txt and patches 
 at:
 http://trac.wildfiregames.com/browser/ps/trunk/libraries/nvtt/

 The issue139.patch is particularly important: it fixed image corruption I 
 noticed on 0.A.D., see here:
 http://www.wildfiregames.com/forum/index.php?
 showtopic=13617view=findpostp=211880
 
 Thanks,
 Fabio
 
 

I will look through the patches and add the ones which seem important
until the next release update.



-- 
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/4f74a085.4020...@ring0.de

Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools

[Lennart Weller]

Am 28.03.2012 04:48, schrieb Paul Wise:
 On Wed, Mar 28, 2012 at 3:15 AM, Lennart Weller wrote:
 
 * Package name: nvidia-texture-tools
  Version : 2.0.8
  Upstream Author : Ignacio Castano icast...@nvidia.com
 * URL : http://code.google.com/p/nvidia-texture-tools/
 * License : MIT/Expat, BSD-2-clause
  Programming Lang: C++
  Description : image processing and texture manipulation tools

  NVIDIA Texture Tools is a collection of image processing and texture
  manipulation tools, designed to be integrated in game tools and asset
  conditioning pipelines.  The primary features of the library are mipmap and
  normal map generation, format conversion and DXT compression.
 
 I had intended to package this and have some early packaging already,
 so if you need a sponsor I can do that.
 
 I've been talking to upstream about some deficiencies in the software
 and its dependencies (that are not yet in Debian). I would suggest
 that you wait until these discussions are concluded and the upstreams
 have made new releases before working on the package.
 
I already got a sponsor for the package and I already completed the
packaging a few month back but thanks for offering your help. The
package is already in collab-maint [1]. And in the new queue for
unstable. It was mainly meant to allow to build 0ad. Here [2] is the ITP
for 0ad which requires nvidia-texture-tools to continue.

[1]
http://anonscm.debian.org/gitweb/?p=collab-maint/nvidia-texture-tools.git;a=summary
[2] http://bugs.debian.org/594800



-- 
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/4f72e736.8030...@ring0.de

Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools

[Lennart Weller]

Am 28.03.2012 13:51, schrieb Paul Wise:

On Wed, 2012-03-28 at 12:25 +0200, Lennart Weller wrote:

I already got a sponsor for the package and I already completed the
packaging a few month back but thanks for offering your help.

How come you didn't file an ITP *before* packaging it? That is what ITPs
are for.
Because I did not plan to have it submitted to debian when I created it 
for my ubuntu ppa.

The package is already in collab-maint [1]. And in the new queue for
unstable. It was mainly meant to allow to build 0ad. Here [2] is the
ITP for 0ad which requires nvidia-texture-tools to continue.

I see.

Here is a quick review of your packaging:

Your library versioning is broken, you should use a Debian-specific
SONAME until upstream sets that. Personally I don't think the libs
should be public, better to put them in a private dir.
In what way do you think it's broken? Also I did submit [1] the patch 
for the library versioning but it got
ignored so far. Every software which would benefit from the library 
currently uses the two year old
version 2.0.8 and there is more then one open request so why should the 
library be hidden from the system?

02-multiarch.patch looks like it *does* need forwarding.
This way of implementing multi-arch support is debian specific so I 
don't think upstream would need this. Which is also
written in the abstract of the patch. Building the library with this 
patch would definitely go against the the multi-arch solution

of e.g. RHEL-based distributions.


You might want to run wrap-and-sort -sa so that diffs of the debian/ dir
are more readable.
Didn't know that tool. Thanks for mentioning it. Otherwise I would have 
done this myself manually in the future.


IMO libnvtt-bin should be called nvidia-texture-tools.
I used this naming scheme because it is frequently used by other 
libraries like libc-bin, ncurses-bin, libnotify-bin, libglib2.0-bin and 
so on.

Of course I'm free to any suggestions on this part.


The package version has +dfsg in it but there is no indication of how
the upstream tarball was repacked and what was non-free.
I removed gnuwin32 binary files, auto-generated Visual Studio project 
files (because they had no license header and were not necessary) and a 
custom configure
script which broke automatic cmake building and basically called just 
cmake in the first place. I will look into it to add this information to 
the package.



[1] http://code.google.com/p/nvidia-texture-tools/issues/detail?id=170



--
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/4f737746.6050...@ring0.de

Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller l...@ring0.de


* Package name: nvidia-texture-tools
  Version : 2.0.8
  Upstream Author : Ignacio Castano icast...@nvidia.com 
* URL : http://code.google.com/p/nvidia-texture-tools/
* License : MIT/Expat, BSD-2-clause 
  Programming Lang: C++ 
  Description : image processing and texture manipulation tools

  NVIDIA Texture Tools is a collection of image processing and texture
  manipulation tools, designed to be integrated in game tools and asset
  conditioning pipelines.  The primary features of the library are mipmap and
  normal map generation, format conversion and DXT compression.

  The sourcecode contains algorithms protected by US patent 5,956,431 aka S3TC.
  Though from what I've read on debian-legal this should be okay as the patent
  is not actively enforced.



-- 
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/20120327191527.2568.48901.reportbug@silverline

Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools

[Lennart Weller]

Am 28.03.2012 01:01, schrieb Ben Hutchings:
 On Tue, Mar 27, 2012 at 09:15:27PM +0200, Lennart Weller wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Lennart Weller l...@ring0.de


 * Package name: nvidia-texture-tools
   Version : 2.0.8
   Upstream Author : Ignacio Castano icast...@nvidia.com 
 * URL : http://code.google.com/p/nvidia-texture-tools/
 * License : MIT/Expat, BSD-2-clause 
   Programming Lang: C++ 
   Description : image processing and texture manipulation tools

   NVIDIA Texture Tools is a collection of image processing and texture
   manipulation tools, designed to be integrated in game tools and asset
   conditioning pipelines.  The primary features of the library are mipmap and
   normal map generation, format conversion and DXT compression.

   The sourcecode contains algorithms protected by US patent 5,956,431 aka 
 S3TC.
   Though from what I've read on debian-legal this should be okay as the 
 patent
   is not actively enforced.
  
 Since you've accepted as fact that this software infringes those
 patents, it looks like you're about to violate item 1 of the Debian
 patent policy.
 
 Ben.
 
S3TC is not actively enforced by S3. And I took this thread [1] as a
reference to create the ITP anyway. According to this thread from 2010
there are at least three other projects already using the S3TC
algorithms. And there is more than one project which depends on this
package. e.g. 0ad and wine

[1] http://lists.debian.org/debian-legal/2010/12/msg00062.html



-- 
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/4f725148.3050...@ring0.de