Re: RFS (resent): libdumbnet
Hi Paul,
I've uploaded a new package which should address your packaging concerns.[1]
I find a symbols file a bit overkill for a library which is not going to
be developed any further in the forseeable future, but I've added one
anyway. - You've pointed out a few things I might discuss with upstream,
and I certainly will when I have the time.
A few direct responses to your remarks:
You seem to have radically altered the install procedures, why not
install to debian/tmp in the install target and use dh_install like
the current version does instead of manually moving stuff around?
I think this one is just personal preference. (I've chosen to do four
mv calls instead of adding three more .install files and am mostly
moving whole directories.) The 1.8 package version even used dh_movefiles. ;)
There are several lintian complaints:
Lintian (even with -IE --pedantic) is now down to
] P: libdumbnet1: no-upstream-changelog
] P: python-dumbnet: no-upstream-changelog
which I can't remedy myself.
Who is he...@pool.math.tu-berlin.de?
Me, as at least the changelog and the key I'm signing these mails with
should show. I don't like the whole debian-list volume hitting my univer-
sity address, so I'm writing these mails from a different account.
[/usr/share/doc/{packages}]
I'm sharing the doc directory between the lib and the dev package, and as
the difference in files I'd like to install in those directories is so
small I'm not inclined to change that.
Likewise, the package descriptions should reflect the audiences.
libdumbnet-dev/python-dumbnet probably needs a fair bit of information
but libdumbnet1 will probably always be automatically installed so
needs vastly less information.
How could I convey less information? Only include the single sentence
libdumbnet provides [...] networking routines.? That wouldn't satisfy
me as a user at all. The items give me an idea of what that library
actually does and why another package might need it - I don't want to
remove them.
I've changed the short description to make the packages distinguishable.
A single autoreconf call can replace the
aclocal/autoheader/autoconf/automake calls (but not the libtoolize one
IIRC).
If I'm forced to rerun the autotools in order to keep the diff/patchset small,
I'd rather list explicitly what I'm calling and which parameters I use.
PS: I've activated the test suite, but it has its limitations and might
not be of as much use as you might have intended. (Another thing upstream
should take care of, at least partially.)
Regards,
Jan
[1]: http://www-pool.math.tu-berlin.de/~hesso/deb/libdumbnet_1.12-1.dsc
signature.asc
Description: Digital signature
Re: RFS (resent): libdumbnet
On Tue, May 12, 2009 at 1:30 PM, Jan C. Nordholz j...@gmx.net wrote: If you're still willing to sponsor libdnet: upstream is not very active (wrt. source changes), but responds quickly. Review below. Upstream location has changed, too. Argh, there is no indication at the sf.net page that it moved to google code. Please ask upstream to do a proper migration (close the webpage, move the code, bugs and so on) and backup and shut down the sf.net project. At the very least the sf.net project needs to indicate that it moved elsewhere. Also, the README and probably other files need updating too. If you rebuild before sponsoring, please don't forget to use -v1.8-2. ;) Uhhh, there should never be an instance of someone sponsoring prebuilt .deb files, if you see someone doing that, they probably shouldn't be a Debian developer. I've updated the package to use the latest tarball (1.12 from Jan 2007) and corrected all links.[1] [1]: http://www-pool.math.tu-berlin.de/~hesso/deb/libdumbnet_1.12-1.dsc Here is a review: Please ask upstream if they would be willing to rename the library. Both libdnet and libdumbnet are too generic IMO, but libdumbnet would be best for Debian to prevent the need for a transition. This would cause the need for a transition in other distros though so it may not be a good idea. You seem to have radically altered the install procedures, why not install to debian/tmp in the install target and use dh_install like the current version does instead of manually moving stuff around? When running autotools in configure, you want to run make maintainer-clean in the clean target and then clean up any parts it missed. Also send a patch upstream to fix the maintainer-clean target if it misses anything. There are several warnings when running autotools, please file a bug/patch upstream. Likewise there are a few GCC warnings, python related and otherwise. There are several lintian complaints: $ lintian --info --display-info --display-experimental --pedantic --show-overrides --checksums --color auto *.changes I: libdumbnet source: duplicate-short-description libdumbnet1 libdumbnet-dev python-dumbnet I: libdumbnet source: dpatch-missing-description 01rename_library.sh.dpatch I: libdumbnet source: dpatch-missing-description 03build_all_python_versions.dpatch I: libdumbnet1: no-symbols-control-file usr/lib/libdumbnet.so.1.0.1 P: libdumbnet1: no-upstream-changelog I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:362 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:372 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:383 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:392 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:401 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:410 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:823 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:838 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:848 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man8/dumbnet.8.gz:247 P: python-dumbnet: no-upstream-changelog As noted above by lintian there is no symbols file for the library. You can get one for the version in the archive here, please start with it and add any symbols added by upstream: http://qa.debian.org/cgi-bin/mole/seedsymbols/?pkgname=libdumbnet1 I assume you've sent the non-renaming patches upstream? 01rename_library.sh.dpatch refers to sourceforge instead of google. Who is he...@pool.math.tu-berlin.de? libdumbnet1 will probably always be automatically installed, you probably don't need README/TODO installed in it. Use debian/package.docs files to avoid this. Likewise, the package descriptions should reflect the audiences. libdumbnet-dev/python-dumbnet probably needs a fair bit of information but libdumbnet1 will probably always be automatically installed so needs vastly less information. There seems to be a test suite in the upstream source code. Please enable it and also handle DEB_BUILD_OPTIONS=nocheck. Also you don't seem to handle noopt or parallel=n in DEB_BUILD_OPTIONS. You also don't handle cross-compiling, but the version in the archive does. You should also add -g to CFLAGS so that DEB_BUILD_OPTIONS=nostrip works. You run dh_installman but don't install any manual pages using it. A single autoreconf call can replace the aclocal/autoheader/autoconf/automake calls (but not the libtoolize one IIRC). I assume you've read the libpkg-guide and noted the two bugs filed on it? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS (resent): libdumbnet
Hi Paul, I'll add libdumbnet/nmap to the security team's embedded-code-copies file in the meantime. ok - I've added liblua/nmap, but that's only a bug in the buildscripts and will vanish again soon, I hope. If you're still willing to sponsor libdnet: upstream is not very active (wrt. source changes), but responds quickly. Upstream location has changed, too. I've updated the package to use the latest tarball (1.12 from Jan 2007) and corrected all links.[1] If you rebuild before sponsoring, please don't forget to use -v1.8-2. ;) Regards, Jan [1]: http://www-pool.math.tu-berlin.de/~hesso/deb/libdumbnet_1.12-1.dsc signature.asc Description: Digital signature
Re: RFS (resent): libdumbnet
On Sun, May 10, 2009 at 1:48 AM, Jan Christoph Nordholz he...@pool.math.tu-berlin.de wrote: Upstream is dormant since I/2007 judging from the CVS graphs over at SF.[3] In that case, please take over the upstream project: Contact the admins of the project to get them to add you as an admin. If there is no response, register a sf.net project with the same shortname (libdnet) and sf.net will give the admins a couple of weeks to respond and then give you admin access to the project. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS (resent): libdumbnet
Hi Paul, Upstream is dormant since I/2007 judging from the CVS graphs over at SF.[3] In that case, please take over the upstream project: that is a different matter that doesn't void my RFS. libdnet has quite a number of reverse dependencies in the archive and is in good shape (our bugtracker is effectively empty, and the upstream tracker doesn't contain any serious issues either), so I think it would be beneficial to get a recent version uploaded no matter what the upstream status is. nmap even uses its own embedded copy of the library. I'm willing to do maintainer work, i.e. sync bugs with the upstream tracker (maybe he'll reappear one day) and keep the package free from compiler errors on our release architectures (which is enough work in itself with our lib renaming stunt), I'll even fix occasional bugs myself - but I can tell you up front that I don't have enough time to kill to assume upstream responsibility. Would you please reconsider uploading the package? Regards, Jan signature.asc Description: Digital signature
Re: RFS (resent): libdumbnet
On Sun, May 10, 2009 at 12:29 PM, Jan C. Nordholz j...@gmx.net wrote: that is a different matter that doesn't void my RFS. libdnet has quite a number of reverse dependencies in the archive and is in good shape (our bugtracker is effectively empty, and the upstream tracker doesn't contain any serious issues either), so I think it would be beneficial to get a recent version uploaded no matter what the upstream status is. nmap even uses its own embedded copy of the library. Quite. That sounds like a bug in nmap, looks like it hasn't been filed yet, please file one. nmap also looks like it could use a new maintainer too. I'm willing to do maintainer work, i.e. sync bugs with the upstream tracker (maybe he'll reappear one day) and keep the package free from compiler errors on our release architectures (which is enough work in itself with our lib renaming stunt), I'll even fix occasional bugs myself - but I can tell you up front that I don't have enough time to kill to assume upstream responsibility. Hmm, OK. Getting added to the upstream project doesn't mean you become responsible for it, but does mean you can push bugfixes from Debian upstream in the absense of the upstream maintainer, which saves other distros from needing to cherry-pick patches from Debian. That lib renaming stunt seems like one of the worse technical decisions made in Debian, perhaps upstream can be persuaded to change too. Would you please reconsider uploading the package? I haven't had a look at your package yet, just wanted to make sure you consider the upstream aspect of maintaining packages. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS (resent): libdumbnet
recent version uploaded no matter what the upstream status is. nmap even uses its own embedded copy of the library. Quite. That sounds like a bug in nmap, looks like it hasn't been filed yet, please file one. nmap also looks like it could use a new maintainer too. Well, nmap has applied a ton of patches on top of its libdnet copy, and I've only scrolled through the descriptions a few weeks ago - I'm not sure if I'd like to merge all of those into the library if I was upstream-responsible, so I'm not convinced that we can eliminate this problem by keeping the Debian libdumbnet up to date... but it's definitely a step in the right direction. ;) I'll try to get in touch with libdnet upstream in the meantime. Regards, Jan signature.asc Description: Digital signature
Re: RFS (resent): libdumbnet
On Sun, May 10, 2009 at 1:25 PM, Jan C. Nordholz j...@gmx.net wrote: Well, nmap has applied a ton of patches on top of its libdnet copy, and I've only scrolled through the descriptions a few weeks ago - I'm not sure if I'd like to merge all of those into the library if I was upstream-responsible, so I'm not convinced that we can eliminate this problem by keeping the Debian libdumbnet up to date... but it's definitely a step in the right direction. ;) Perhaps you could convince the nmap upstream to contact libdnet upstream and get their patches integrated. I''ll add libdumbnet/nmap to the security team's embedded-code-copies file in the meantime. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
