Re: RFS: hashalot (updated)
Hello, On Fri, 25 Jan 2008, Adam Borowski wrote: Ok, I did this, then overwrote 0.3-5 on mentors. There's a watch file for uscan now as well. Good work. One last correction... Under the new policy apt-get installs all recommended packages by default. Moreover, Recommends: means that the package normally needs the recommended packages to do the things that the user wants done. So I think you can downgrade Recommends: cryptsetup, dmsetup to Suggests:. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
(done) Re: RFS: hashalot (updated)
Debian Queue daemon wrote: hashalot_0.3-5_arm.changes uploaded successfully to localhost [...] Thanks! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
Adam Borowski scrisse: As the diff is small (except for file deletions), this shouldn't take much of your time. If someone could upload this, that would be cool. I've seen that you've already found Kapil available, fine :). Anyway your gzipped diff is 70K (almost as big as the original tarball), which seems to clash with your previous statement. It also seems to contain a heavy autotool-ization. Looking at the diff and at your email, is that all ok? Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgp9Ck6a1RZeC.pgp Description: PGP signature
Re: RFS: hashalot (updated)
On Thursday 24 January 2008 04:40, Kapil Hari Paranjape wrote: * Vcs-Svn and Vcs-Browser. Shouldn't the Vcs-Svn entry start with svn: instead of http:? SVN can be run over a variety of protocols, next to svn including ssh and http(s). Which is an excellent feature if you ask me :-) Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Thu, Jan 24, 2008 at 09:25:05AM +0100, Luca Bruno wrote: Adam Borowski scrisse: As the diff is small (except for file deletions), this shouldn't take much of your time. If someone could upload this, that would be cool. I've seen that you've already found Kapil available, fine :). Anyway your gzipped diff is 70K (almost as big as the original tarball), which seems to clash with your previous statement. It also seems to contain a heavy autotool-ization. A diff from the previous packages, I mean. I wasn't clear enough, sorry. As in debdiff hashalot_0.3-4.dsc hashalot_0.3-5.dsc. Matthias Urlich enabled AM_MAINTAINER_MODE some time ago -- this stops _new_ unrequested autotoolization changes, but is a reautotooling by itself. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Thu, Jan 24, 2008 at 09:10:11AM +0530, Kapil Hari Paranjape wrote: Hello, Some quick comments. On Thu, 24 Jan 2008, Adam Borowski wrote: * Buffer overflow on RMD160: It will cause only a crash instead of executing arbitrary code, and considering the typical usage this is nearly always harmless. Yet, in non-typical uses even wrong output can be pretty bad for a hash. A nearly-identical fix is already in Ubuntu (they move some functions around without an apparent reason). Has this patch been submitted upstream? Yes, albeit only a week ago. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
Hello, On Thu, 24 Jan 2008, Adam Borowski wrote: On Thu, Jan 24, 2008 at 09:10:11AM +0530, Kapil Hari Paranjape wrote: Has this patch been submitted upstream? Yes, albeit only a week ago. Is upstream still working on this package? The last upload seems to have been in 2004! On Thu, 24 Jan 2008, Luca Bruno wrote: I've seen that you've already found Kapil available, fine :). Luca Bruno: please consider sponsoring if you like. On Thu, 24 Jan 2008, Adam Borowski wrote: On Thu, Jan 24, 2008 at 09:25:05AM +0100, Luca Bruno wrote: Anyway your gzipped diff is 70K (almost as big as the original tarball), which seems to clash with your previous statement. Matthias Urlich enabled AM_MAINTAINER_MODE some time ago -- this stops _new_ unrequested autotoolization changes, but is a reautotooling by itself. It is indeed true that diff -ur hashalot-0.3-[45] | wc -c returns just about 5K. And these are the changes documented in the changelog. At a cursory glance it looks like this package may continue to need such large patches it it continues to be un-maintained upstream (if only for re-autotool-ing!). Is Adam willing to take up the task of being de-facto long-term maintainer of the package in this case? Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Thu, Jan 24, 2008 at 04:44:48PM +0530, Kapil Hari Paranjape wrote: On Thu, 24 Jan 2008, Adam Borowski wrote: On Thu, Jan 24, 2008 at 09:25:05AM +0100, Luca Bruno wrote: Anyway your gzipped diff is 70K (almost as big as the original tarball), which seems to clash with your previous statement. Matthias Urlich enabled AM_MAINTAINER_MODE some time ago -- this stops _new_ unrequested autotoolization changes, but is a reautotooling by itself. It is indeed true that diff -ur hashalot-0.3-[45] | wc -c returns just about 5K. And these are the changes documented in the changelog. Actually, it seems that reverting to upstream autotooling doesn't break anything (except obviously being unfriendly to those who want to update autotoolage themselves). I would need to rename a file by hand in debian/rules, that's all. Should I remove those parts from the diff? At a cursory glance it looks like this package may continue to need such large patches it it continues to be un-maintained upstream (if only for re-autotool-ing!). Debian patches are small: -q for suppressing output, manpage and now the buffer overflow fix. Autotoolage changes appear to be huge, but they're all auto-generated files. Is Adam willing to take up the task of being de-facto long-term maintainer of the package in this case? In long-term, the package will most likely be absorbed into cryptsetup, where already most of functionality has gone to. Unless somehow it is needed for something else (there appears to be no other hasher for RMD160 around), it will probably go away completely. It's mostly there to avoid breaking people's setups. Regards. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
Hello, Sorry about the delay in responding. Different time zones! On Thu, 24 Jan 2008, Adam Borowski wrote: Actually, it seems that reverting to upstream autotooling doesn't break anything (except obviously being unfriendly to those who want to update autotoolage themselves). I would need to rename a file by hand in debian/rules, that's all. Should I remove those parts from the diff? I think so. The package does not depend on anything substantial other than the C library and compiler. Updating the autotool-age should not be necessary. I notice that you have shifted the man page from section 1 (used by upstream) to section 8. Since hashalot is not just a command to be used by system administrators, I don't know why this has been done. Debian patches are small: -q for suppressing output, manpage and now the buffer overflow fix. Rather than include the manpage you should patch the upstream manpage. (Upstream seems to have included the manpage written by Matthias Ulrich at some stage but the Debian packaging hasn't taken this into account). In long-term, the package will most likely be absorbed into cryptsetup, Now that there is luks, there is some doubt about this! It's mostly there to avoid breaking people's setups. That is a very good reason indeed. Overall, it would be good if you simplified the Debian .diff.gz so that it is clear that it consists of (a) packaging (b) bug fixes to the upstream code. (Usually (b) is done by using dpatch or quilt but I won't insist on this). That way anyone wanting to utilise the code later would know exactly what parts to use. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Fri, Jan 25, 2008 at 06:19:57AM +0530, Kapil Hari Paranjape wrote: Hello, Sorry about the delay in responding. Different time zones! Hah, it's 4am, it's me who's hitting the bed now... On Thu, 24 Jan 2008, Adam Borowski wrote: Actually, it seems that reverting to upstream autotooling doesn't break anything (except obviously being unfriendly to those who want to update autotoolage themselves). I would need to rename a file by hand in debian/rules, that's all. Should I remove those parts from the diff? I think so. The package does not depend on anything substantial other than the C library and compiler. Updating the autotool-age should not be necessary. Actually, it does check for all the headers, then... doesn't use that information at all. configure.ac should be empty except for invoking automake. Even that old automake 1.7 upstream used knows where to install things good enough. I thus reverted this part of the diff, reducing it by a factor of 20... I notice that you have shifted the man page from section 1 (used by upstream) to section 8. Since hashalot is not just a command to be used by system administrators, I don't know why this has been done. Matthias Urlichs did this because: 1. hashalot is good nearly solely for cryptsetup. A nicer interface for using the hashes could be nice but SHA256, SHA384 and SHA512 are already provided by coreutils, so anything an user would use is RMD160. Which was totally broken for anything but one-line strings until this upload and no one complained. 2. binary output can be dangerous for an unwary user Rather than include the manpage you should patch the upstream manpage. (Upstream seems to have included the manpage written by Matthias Ulrich at some stage but the Debian packaging hasn't taken this into account). Good point, fixed this. In long-term, the package will most likely be absorbed into cryptsetup, Now that there is luks, there is some doubt about this! luks doesn't need an external helper for this task. Overall, it would be good if you simplified the Debian .diff.gz so that it is clear that it consists of (a) packaging (b) bug fixes to the upstream code. (Usually (b) is done by using dpatch or quilt but I won't insist on this). Ok, I did this, then overwrote 0.3-5 on mentors. There's a watch file for uscan now as well. Bye for tonight! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: hashalot (updated)
Hi!
I seem to have issues catching the previous sponsor, for some time already.
There's an updated package at:
dget http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-5.dsc
Issues fixed:
* Buffer overflow on RMD160:
It will cause only a crash instead of executing arbitrary code, and
considering the typical usage this is nearly always harmless. Yet, in
non-typical uses even wrong output can be pretty bad for a hash.
A nearly-identical fix is already in Ubuntu (they move some functions
around without an apparent reason).
* Lots of packaging cruft:
Due to debian/rules clean not working correctly, prior Debian diffs
included files like config.h, .deps/*, stamp-*, Makefile.
Also, config.{sub,guess} has been yanked away as per the current packaging
practices.
* Debhelper 5, standards 3.7.3, etc.
* Vcs-Svn and Vcs-Browser.
As the diff is small (except for file deletions), this shouldn't take much
of your time. If someone could upload this, that would be cool.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
Hello, Some quick comments. On Thu, 24 Jan 2008, Adam Borowski wrote: * Buffer overflow on RMD160: It will cause only a crash instead of executing arbitrary code, and considering the typical usage this is nearly always harmless. Yet, in non-typical uses even wrong output can be pretty bad for a hash. A nearly-identical fix is already in Ubuntu (they move some functions around without an apparent reason). Has this patch been submitted upstream? * Vcs-Svn and Vcs-Browser. Shouldn't the Vcs-Svn entry start with svn: instead of http:? As the diff is small (except for file deletions), this shouldn't take much of your time. If someone could upload this, that would be cool. I will take a more detailed look at it. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
