public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
* [ADOPT] iperf 2.0.8
@ 2015-07-14  1:31 Joel Johnson
  2015-07-14  4:59 ` Marco Atzeri
  2015-07-14  8:27 ` Joel Johnson
  0 siblings, 2 replies; 9+ messages in thread
From: Joel Johnson @ 2015-07-14  1:31 UTC (permalink / raw)
  To: cygwin-apps

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ADOPT] iperf 2.0.8
  2015-07-14  1:31 [ADOPT] iperf 2.0.8 Joel Johnson
@ 2015-07-14  4:59 ` Marco Atzeri
  2015-07-14  8:27 ` Joel Johnson
  1 sibling, 0 replies; 9+ messages in thread
From: Marco Atzeri @ 2015-07-14  4:59 UTC (permalink / raw)
  To: cygwin-apps

On 7/14/2015 3:31 AM, 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

Dear Joel,
of course no objection, when ready please post here a link
to your package proposal so we can review it.

After the approval (GTG=Good To Go) , please follow
https://sourceware.org/cygwin-apps/package-upload.html
so you will able to upload the new versions by yourself.

Please looks a the guideline for packages
https://cygwin.com/setup.html

and use cygport as packaging tool
https://cygwin.com/cygport/manual.html
(same examples here http://sourceforge.net/p/cygwin-ports/_list/git )

Regards
Marco

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ADOPT] iperf 2.0.8
  2015-07-14  1:31 [ADOPT] iperf 2.0.8 Joel Johnson
  2015-07-14  4:59 ` Marco Atzeri
@ 2015-07-14  8:27 ` Joel Johnson
  2015-07-14 11:34   ` Marco Atzeri
  1 sibling, 1 reply; 9+ messages in thread
From: Joel Johnson @ 2015-07-14  8:27 UTC (permalink / raw)
  To: cygwin-apps

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

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.

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

     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!

Joel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ADOPT] iperf 2.0.8
  2015-07-14  8:27 ` Joel Johnson
@ 2015-07-14 11:34   ` Marco Atzeri
  2015-07-14 17:18     ` Joel Johnson
  0 siblings, 1 reply; 9+ messages in thread
From: Marco Atzeri @ 2015-07-14 11:34 UTC (permalink / raw)
  To: cygwin-apps

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ADOPT] iperf 2.0.8
  2015-07-14 11:34   ` Marco Atzeri
@ 2015-07-14 17:18     ` Joel Johnson
  2015-07-15  5:13       ` Marco Atzeri
                         ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Joel Johnson @ 2015-07-14 17:18 UTC (permalink / raw)
  To: Marco Atzeri; +Cc: cygwin-apps

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ADOPT] iperf 2.0.8
  2015-07-14 17:18     ` Joel Johnson
@ 2015-07-15  5:13       ` Marco Atzeri
  2015-07-15 12:46         ` Andrew Schulman
  2015-07-15  5:38       ` Achim Gratz
  2015-09-26  8:46       ` Marco Atzeri
  2 siblings, 1 reply; 9+ messages in thread
From: Marco Atzeri @ 2015-07-15  5:13 UTC (permalink / raw)
  To: Joel Johnson; +Cc: cygwin-apps

On 7/14/2015 7:17 PM, Joel Johnson wrote:
> On 2015-07-14 05:34, Marco Atzeri wrote:

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

Ok,
fair enough, just highlight the problem in the announcement.

You are the new maintainer
Congratulation.

please follow:
https://sourceware.org/cygwin-apps/package-upload.html

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

build a local site and use genini to build the setup.ini
https://sourceware.org/viewvc/cygwin-apps/genini/

For example I use a structure like

http%3a%2f%2fmatzeri.altervista.org%2f/x86/setup.bz2
http%3a%2f%2fmatzeri.altervista.org%2f/x86/setup.ini
http%3a%2f%2fmatzeri.altervista.org%2f/x86/iperf/iperf-2.0.5-1-src.tar.xz
http%3a%2f%2fmatzeri.altervista.org%2f/x86/iperf/iperf-2.0.5-1.tar.xz
http%3a%2f%2fmatzeri.altervista.org%2f/x86/iperf/iperf-debuginfo/iperf-debuginfo-2.0.5-1.tar.xz
http%3a%2f%2fmatzeri.altervista.org%2f/x86/iperf/iperf-debuginfo/setup.hint
http%3a%2f%2fmatzeri.altervista.org%2f/x86/iperf/setup.hint

http%3a%2f%2fmatzeri.altervista.org%2f/x86_64/setup.bz2
http%3a%2f%2fmatzeri.altervista.org%2f/x86_64/setup.ini
http%3a%2f%2fmatzeri.altervista.org%2f/x86_64/iperf/iperf-2.0.5-1-src.tar.xz
http%3a%2f%2fmatzeri.altervista.org%2f/x86_64/iperf/iperf-2.0.5-1.tar.xz
http%3a%2f%2fmatzeri.altervista.org%2f/x86_64/iperf/iperf-debuginfo/iperf-debuginfo-2.0.5-1.tar.xz
http%3a%2f%2fmatzeri.altervista.org%2f/x86_64/iperf/iperf-debuginfo/setup.hint
http%3a%2f%2fmatzeri.altervista.org%2f/x86_64/iperf/setup.hint

and a script like
-----------------------------------------
rm x86/setup.ini x86_64/setup.ini

genini --recursive x86_64 > x86_64/setup.ini
bzip2 -k -c x86_64/setup.ini > x86_64/setup.bz2

genini --recursive x86 > x86/setup.ini
bzip2 -k -c x86/setup.ini > x86/setup.bz2
-----------------------------------------


see "setup-x86.exe --help"
how to install locally from your local site.


> Joel

Regards
Marco

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ADOPT] iperf 2.0.8
  2015-07-14 17:18     ` Joel Johnson
  2015-07-15  5:13       ` Marco Atzeri
@ 2015-07-15  5:38       ` Achim Gratz
  2015-09-26  8:46       ` Marco Atzeri
  2 siblings, 0 replies; 9+ messages in thread
From: Achim Gratz @ 2015-07-15  5:38 UTC (permalink / raw)
  To: cygwin-apps

Joel Johnson writes:
> 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?

It's mainly a matter of updating / creating the appropriate entries in
/etc/setup/installed.db which a few lines of scripting can take care of.

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

The prefered way is to create a local install hierarchy with genini and
point setup to additionally use that.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ADOPT] iperf 2.0.8
  2015-07-15  5:13       ` Marco Atzeri
@ 2015-07-15 12:46         ` Andrew Schulman
  0 siblings, 0 replies; 9+ messages in thread
From: Andrew Schulman @ 2015-07-15 12:46 UTC (permalink / raw)
  To: cygwin-apps

> You are the new maintainer
> Congratulation.

Gold star awarded!  https://cygwin.com/goldstars/#JJ

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ADOPT] iperf 2.0.8
  2015-07-14 17:18     ` Joel Johnson
  2015-07-15  5:13       ` Marco Atzeri
  2015-07-15  5:38       ` Achim Gratz
@ 2015-09-26  8:46       ` Marco Atzeri
  2 siblings, 0 replies; 9+ messages in thread
From: Marco Atzeri @ 2015-09-26  8:46 UTC (permalink / raw)
  To: Joel Johnson; +Cc: cygwin-apps

On 14/07/2015 19:17, Joel Johnson wrote:
> 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.
>>>
>>>      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.
>
> Joel


Joel,
any news ?

We are still lacking you uploads

Regards
Marco

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-09-26  8:46 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-14  1:31 [ADOPT] iperf 2.0.8 Joel Johnson
2015-07-14  4:59 ` Marco Atzeri
2015-07-14  8:27 ` Joel Johnson
2015-07-14 11:34   ` Marco Atzeri
2015-07-14 17:18     ` Joel Johnson
2015-07-15  5:13       ` Marco Atzeri
2015-07-15 12:46         ` Andrew Schulman
2015-07-15  5:38       ` Achim Gratz
2015-09-26  8:46       ` Marco Atzeri

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).