On Thu, Aug 16, 2007 at 08:03:04PM +0530, Kapil Hari Paranjape wrote: > > On Fri, 10 Aug 2007, Luis Rodrigo Gallardo Cruz wrote: > > I am looking for a sponsor for the new version 3:4.20-3 > > of my package "stunnel4". > I have some fixes/suggestions for you. Since this would be the first > package that I would sponsor, I hope we can learn from each other! :) I have uploaded a new version with the suggested fixes. Following your sugestion I used 3:4.20-4~1 as version. If you consider it worthy of upload, please change it to -4. And please build with -v3:4.20-2 Thanks http://mentors.debian.net/debian/pool/main/s/stunnel4/stunnel4_4.20-4~1.dsc > General remark: > =============== > Please go through the package completely *as if* I were the person > who had done the packaging and you were the person performing the > sponsor-ship. Experience says that the time of adoption is probably > the time when the maximum effort is/can be put into cleaning up > packaging issues. Thanks, that's a good idea. It actually prompted two more changes: * Remove empty /usr/sbin dir. * Avoid linking to libz.so. configure checks for an specific function from it, required by openssl. But, as stunnel itself does not use the library, the generated dependency in zlib1g was bogus and marked as such by the checklib report. http://rerun.lefant.net/checklib/index.html http://rerun.lefant.net/checklib/maintainers.S.html#speedblue@debian.org > "Must" fixes: > ============== > - The author of debian/StunnelConf-0.1.pl is not mentioned in the > debian/copyright file. I have *not* checked all the files in your > tree. Please check each file of the unpacked source and the debian/ > directory to find relevant attributions. > - Please fix the debian/copyright file. See > http://lists.debian.org/debian-devel-announce/2003/12/msg00007.html > Specifically, one thing that *is* missing is the dates of the > copyright assertion by the upstream author. Done. > - Avoid patching tools/script.sh in your diff. Use quilt instead. Ups. That was a mistake, I intended to do that from the start. > In fact your collab-maint repository should ideally only contain > the debian/ directory. I've been playing with both kinds of repositories, with and without upstream sources, in my packages, but I'm not sure yet which workflow is easier. Do you have some description on pros/cons from others, to help decide? > - linda complains about the empty directory /usr/share/lintian/overrides/ > I am not sure what you are using overrides here for. I just think it's easier to have debian/rules try to install the overrides file always, instead of adding/removing the snippet whenever the file gets empty. Anyways, the directory creation *is* a mistake. Fixed. > - This changelog entry is not clearly written. > * Use less cmd line args to debhelper commands in debian/rules. > An alternative may be > * Rewrite dh_* invocations in debian/rules. > Or > * Shorten dh_* invocations in debian/rules. Done > Optional fixes: > ============== > - IMHO the README.Debian file needs better organisation. Perhaps > three or four sections. One "Upgrading from stunnel to stunnel4", > two "Sample Stunnel configurator", three "Howto create Tunnels", > four "Howto create SSL keys for stunnel". Done > - debian/StunnelConf-0.1.pl could perhaps be placed in > /usr/share/doc/stunnel4/contrib/ as it is not a document but > contributed code. Done > - The preferred debian/changelog entry format seems to be. > New maintainer. Closes: #416955. > rather than > Adopt package (closes: #416955). Done > - I (have learnt to) prefer changelog entries that clearly indicate > which files were changed rather than those that just describe the > effect of the changes. Done. Kind of. I think some of the entries were explicit enough already. > Not sure aspects: > =============== > - I am not sure that the warnings in the doc/ directory are enough > of a warning for those who have so far been using stunnel3. > Since "stunnel" starts network tunnels through init.d or inetd > someone could suffer quite a bit in the transition. We should > think about this some more ... I don't think there's much problem. Any automatic tunnel the user had will continue to work, thanks to the wrapper compatibility script. No new automatic tunnels will be created, because that requires manual enabling. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28
Attachment:
signature.asc
Description: Digital signature