Re: [ADOPT] iperf 2.0.8

[Joel Johnson <mrjoel@lixil.net>]

On 2015-07-14 05:34, Marco Atzeri wrote:
> 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

I did test both the 32 and 64 bit version, but not with the -D flag, 
just interactively. Thanks for pointing out that gap. I only had a 
chance to look briefly at the failure, but it occurs on 2.0.5 32 and 
64-bit builds, as well as the existing 2.0.4 32-bit package. Since it's 
strictly not a regression, I'd push for it not holding up the update if 
everything else work, but is still be a nice to have that I'll look at.

As another packaging question, I get that cygport is a build helper not 
package management, but is there an easy way to install a resulting 
binary package on a local system that ties in with the setup.exe 
packaging tracking? I'd like to be able to actually test packages in 
deployed state with and without the debug information present, and be 
able to subsequently remove it as well, for which tar xfJ doesn't do 
such a hot job.

Joel