wget-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Tests for the --resolve option and passing ipv4/ipv6 flag to test enviro


From: Shamil Gumirov
Subject: Tests for the --resolve option and passing ipv4/ipv6 flag to test environment
Date: Tue, 6 Apr 2021 11:59:39 +0200

Hi Darshit,

Thanks! Sure, I'll sign the copyright assignment once needed, please
let me know. As far as I understand the minor patches do not need it.
I'll create a new gitlab PR regarding minor bug fixes today.

I'm currently working on a proposal to add a `--resolve hostname:ip`
option and a tests to cover it. Please correct me if I've got wrong
assumptions or findings.

Which test suite to add test to?

I see that there're two test suites: the one in testenv/ (in python)
and another in tests/ (in perl). Which is the one to be used? A
testenv/ seems to be a more fresh one.

IPv6/IPv4-only test suites.

Another question is if that's possible for a test to know if IPv6 is
disabled for the source (via ./configure --disable-ipv6). This can be
useful for the `--resolve` option I'm working on as there's a need to
add separate implementations for IPv4-only and IPv6/IPv4 cases. So
that would be great to be able to have additional tests for when IPv6
is enabled.

I'm not yet sure exactly how the CI tests the project, so I assume
that `make check` is called in the project root.

Also from what I see in perl test logs (tests/**.log), almost all the
tests (except the ftp related ones) fail if the project is configured
without IPv6 (`./configure --disable-ipv6`). This means that the perl
tests' http daemon is bound to the ipv6 interface no matter if sources
are configured with or without IPv6 support. If needed this can also
be fixed by different setup for tests depending on the --disable-ipv6
configuration flag.

Best regards,
Shamil

On 19/03/2021, Darshit Shah <darnir@gnu.org> wrote:
> Hi Shamil,
>
> We're glad you'd like to contribute. As you've mentioned, both
> approaches are perfectly valid for contributing to Wget. You may fork
> the project at gitlab.com/gnuwget/wget and send a merge request, or just
> send the patch via email with a cover letter. We will process both of
> them the same way.
>
> However, before we can accept your contribution, we will need you to
> submit a copyright assignment form to the Free Software Foundation. But
> that's at a later stage and we will handle it after your first patches
> are submitted.
>
> On 19.03.21 14:37, Shamil Gumirov wrote:
>> Hi everyone,
>>
>> My name is Shamil, I'm a software engineer living in Sweden with ~20
>> years of experience. I'm new to wget development and I'd be pleased to
>> contribute a couple of patches to wget ver.1 (regarding minor bug
>> fixes and maybe another one on adding a new "--resolve=host:ip"
>> argument similar to the one from curl). As far as I see there're two
>> ways now to contribute, please correct me if I'm wrong:
>> - create a new PR in gitlab/wget repo, or
>> - patch submission to bug-wget@gnu.org.
>> Which one is the appropriate way? Thanks!
>>
>> Best regards,
>> Shamil Gumirov
>> https://shamil.gumirov.org
>>
>>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]