[ADOPT] iperf 2.0.8
Tue Jul 14 08:27:00 GMT 2015
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
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
Source change history:
As I'm new to cygwin packaging, I have a few questions (coming from a
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
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!
More information about the Cygwin-apps