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]

Fwd: Testing ping for cygwin x86_64


On Thu, Oct 17, 2013 at 11:54 AM, Corinna Vinschen wrote:
> On Oct 17 10:17, Balaji wrote:
>> Hi - since ping appears to be currently orphaned, I wanted to see if I
>> can help out. It being a fairly simple package, definitely aided my
>> decision.
>>
>> I downloaded the source for ping (Cygwin32). While I can't seem to get
>> the provided shell script to run right, I was able to apply the
>> included patch file and build the 32bit version. I tried building the
>> 64bit version which did build and run fine on (Cygwin64 1.7.25). There
>> were a bunch of warnings (even without -Wall) in the 64bit build and I
>> patched them - mostly minor fixes like casts etc. and re-built/tested
>> both versions.
>>
>> So, finally getting to my question - are the rudimentary ping tests
>> that I did, good enough to make this package worthy of release?
>
> I think so, yes.  Just keep in mind that Windows disallows using raw
> sockets for non-admin users, which means that this ping implementation
> will neither work for non-admins, nor for admins running a UAC-crippled
> shell.  This shows up as questions on the Cygwin mailing list once in a
> while, which, as a maintainer, you should be prepared to answer.

Thanks for the reply and the information/guidelines above.

>> This being my first attempt at trying to possibly maintain a Cygwin
>> package, I want make sure I'm doing the right thing. One odd thing is
>> that all of the source code and Makefile are in the patch file. Also,
>> am I free to convert the package to cygport/ditch the shell script
>> etc. - I understand all that may typically be the maintainer's choice?
>> Advance thanks for any advice from you seasoned veterans.
>
> Porting a package to cygport is highly appreciated, no worries.  And of
> course you are free to pack it in a cleaner fashion than the existing
> package.

One other question - I remember there was some discussion about noarch
packages a while ago. Are there any rules for/against making something
a noarch package. And the associated pros/cons - both from a
maintainer and user perspective?

Thanks,
Balaji


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]