Hi... On Sat, Mar 08, 2008 at 05:17:21PM -0800, Todd A. Jacobs wrote: : : Thanks again for merging the bugs. I have updated all packages, and : lintian now only reports: : : $ lintian libdmtx_0.4.0+svn102-2_i386.changes : W: libdmtx source: native-package-with-dash-version : W: libdmtx0: non-dev-pkg-with-shlib-symlink usr/lib/libdmtx.so.0.0.0 usr/lib/libdmtx.so : : which seem like spurious warnings to me. You can grab the latest : packages from here: : : deb http://www2.codegnome.org:59321/codegnome-debs/ sid contrib non-free : deb-src http://www2.codegnome.org:59321/codegnome-debs/ sid contrib non-free
The first one can only pass if the debian/ directory are included in the official distribution, but in http://prdownloads.sourceforge.net/libdmtx/libdmtx-0.4.0.tar.gz?download the debian/ directory is not included, so it must go in the .diff.gz, also the svn102 changes. I see that the debian/ directory is in the svn repository :) The changes are easy: just dowload libdmtx-0.4.0.tar.gz and rename to libdmtx_0.4.0.orig.tar.gz. Then I'd rename the version and debian revision to 0.4.0-2+svn102, so it is clear that official version is 0.4.0. Debian shouldn't ship an unofficial version (0.4.0+svn102) if there is not a good reason for that. The libdmtx project is alive and active, so I don't see the point for bypassing them. the second one... if you run lintian with "-Ii" options it is well explained: W: libdmtx0: non-dev-pkg-with-shlib-symlink usr/lib/libdmtx.so.0.0.0 usr/lib/libdmtx.so N: N: Although this package is not a `-dev' package, it installs a N: `libsomething.so' symbolic link referencing the corresponding shared N: library. When the link doesn't include the version number, it is used N: by the linker when other programs are built against this shared N: library. N: N: Shared libraries are supposed to place such symbolic links in their N: respective `-dev' packages, so it is a bug to include it with the main N: library package. N: N: However, if this is a small package which includes the runtime and the N: development libraries, this is not a bug. In the latter case, please N: override this warning. N: N: Refer to Policy Manual, section 8.4 for details. N: libdmtx has a libdmtx-dev package, now it only includes the headers for compiling; static library libdmtx.a and the "shlib-symlink" must go also in the -dev. BTW, libdmtx.3.gz must also go in the -dev package, as it is only needed in development. : and let me know if they pass muster. I'm happy to continue maintaining : the libdmtx packages, and will certainly look into the Debian python : packaging issues for the next release. Well... after playing around with python packaging a bit, I think it is not very important. I've tried packaging it with cdbs and it is not working well because this is not a python specific package. I prefer to have a good package without python bindings that nobody uses yet. I send you attached the watch file for the package. Include it in the debian/ directory. With it, you can use "uscan" to see the upstream status: $ uscan --report Processing watchfile line for package libdmtx... Newest version on remote site is 0.4.0, local version is 0.4.0+svn102 libdmtx: remote site does not even have current version The watch file is used in the qa.debian.org site: http://qa.debian.org/developer.php?login=rover%40debian.org&comaint=yes so you can see easily ("watch" column) if the package is updated to the upstream last release. Salud, -- Roberto Lumbreras .''`. <rover : :' : debian.org> Debian Developer `. `' `-
version=3 http://sf.net/libdmtx/libdmtx-?_?([\w+\d+\.]+|\d+)(?:\.tar|\.tgz)(?:\.gz|\.bz2|)
