This is the mail archive of the
mailing list for the Cygwin project.
Re: [ADOPT] iperf 2.0.8
- From: Joel Johnson <mrjoel at lixil dot net>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 14 Jul 2015 02:27:04 -0600
- Subject: Re: [ADOPT] iperf 2.0.8
- Authentication-results: sourceware.org; auth=none
- References: <5518580c020d188244da3f0626fe05b8 at lixil dot net>
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.
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!