Re: [ADOPT] iperf 2.0.8

[Marco Atzeri <marco dot atzeri at gmail dot com>]

On 7/14/2015 10:27 AM, Joel Johnson wrote:
> On 2015-07-13 19:31, Joel Johnson wrote:

> 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/


build fine. Have you tested it?
on 64 bit I see

 $ iperf -s -D

 $       1 [main] iperf 5396 fork: child -1 - forked process 9264 died 
unexpectedly, retry 0, exit code 0xC0000005, errno 11
error

and 32bit strace...

--- Process 8552, exception 80000001 at 73006661

> 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.

no common source area for the time being.
Mine are on github also.

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

both works.

>      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?

correct.

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

There was a discussion, but I don't remind the outcome.

>      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.

It is now optional.

> 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.

No idea.

> Thanks for review and feedback!
>
> Joel