[ADOPT] iperf 2.0.8

[Joel Johnson]

On 2015-07-13 19:31, Joel Johnson wrote:
> The list of packages that we use that are not built for 64-bit has
> gotten small enough that the only one remaining is iperf, which is
> marked as orphaned and will therefore not likely have an update. I'd
> like to volunteer as a maintainer of the iperf package since it
> appears to still be in an orphaned state. I'll have a package put
> together and posted shortly if there aren't any objections.
> 
> Joel Johnson

I've put together an update for iperf, with no significant changes 
needed. I've done some consolidation into just the cygport file, and 
removed the override of src_compile as there were no special 
requirements and how it was neglected to do the cygautoreconf update 
step.

I've also bumped to version 2.0.5. There is a fork (sourceforge project 
iperf2 instead of iperf) with releases to 2.0.8, but I'm not comfortable 
uploading that since one of the changelog entries is an incompatible 
change ("Require -u for UDP (-b no longer defaults to UDP)"). I'll 
follow-up with an ITP for iperf3 which I recommend having as a separate 
package (named iperf3 following Debian naming) since it isn't strictly 
compatible.

     Source change history:
         https://github.com/mrjoel/cygwin-iperf

     Proposed-uploads:
         http://www.kecra.com/cygwin/x86/proposed/iperf
         http://www.kecra.com/cygwin/x86_64/proposed/iperf/

As I'm new to cygwin packaging, I have a few questions (coming from a 
Debian slant):

     A) Is there a standard location for accessing source history of 
package files? I've put them on a github for the time being, is there a 
more appropriate location? I couldn't seem to find anything consistent 
for other packages.

     B) What is the convention for line-wrapping on the ldesc in 
setup.hint, wrap or long lines?

     C) There doesn't seem to be a way in the path structure to have the 
x86 binary, x86_64 binary, and a shared source file, or am I missing 
something?

     D) When using setup.hint generation from the X.cygport file values, 
is there a way to specificy prev/current/test versions if needed?

     E) Is the CYGWIN-PATCHES/README strictly required? There was one 
present previously, but I removed it since it didn't seem to add 
anything of value and was another file to track.

One issue that I did run into was in trying to use cygport to 
cross-compile from a x86 installation for a x86_64 target. I installed 
cygwin64, assuming that was in support of doing just that. It appeared 
to work until the actual compilation failing a lookup for rpl_malloc. 
Disabling the AC_FUNC_MALLOC check allowed it to succeed. Should the 
upload include a patch to disable that check, or is there some other 
package that I should have installed to make it work. I ended up doing a 
lean new 64-bit installation and the build went cleanly (as provided 
above), so it appears to be just a cross-compilation issue.

Thanks for review and feedback!

Joel