Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
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 -- 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/17375292.10420951333023056597.JavaMail.root@wmail65
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
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
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
On Thu, 2012-03-29 at 19:47 +0200, Lennart Weller wrote: 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. Talking to upstream just now, the libsquish and poshlib embedded code copies are sadly both forked so don't worry about them. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
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
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. 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. 02-multiarch.patch looks like it *does* need forwarding. You might want to run wrap-and-sort -sa so that diffs of the debian/ dir are more readable. IMO libnvtt-bin should be called nvidia-texture-tools. The package version has +dfsg in it but there is no indication of how the upstream tarball was repacked and what was non-free. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
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
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. 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. 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 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. I guess you missed removal of the non-free nvidia logo? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
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
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. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120327230115.gt12...@decadent.org.uk
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
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
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
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. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6hg6kv5pgzoi5taa0bscanpppkh9ufgtsbjqlfam36...@mail.gmail.com
