This is the mail archive of the cygwin-apps mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 specialrequirements 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 comfortableuploading that since one of the changelog entries is an incompatible change ("Require -u for UDP (-b no longer defaults to UDP)"). I'llfollow-up with an ITP for iperf3 which I recommend having as a separatepackage (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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |