Re: [Bug-wget] Metalink support

[Hubert Tarasiuk]

Hi Tim,

W dniu 03.07.2015 o 10:17, Tim Ruehsen pisze:
> Just a few minor points I stumbled upon when I tried to apply your patches :-)
> 
> - they don't apply smoothly on latest master. Could you rebase your work on 
> current master ?
> (What I did it is 'git am 00*' with your patches)
That was my bad. It is now rebased.
> 
> - I had to find out that I need libgpgme11-dev package (on Debian here), else 
> ./boostrap and/or ./configure would not work. Please add this information to 
> README.checkout.
Both libmetalink and GPGME were supposed to be "weak" dependencies. How
about copying GPGME's m4 macro to Wget's m4 directory? If I add it to
the Wget repository, the scripts will not fail without GPGME installed.
> 
> - still libmetalink was missing and a 'make check' failed with
> ../src/libunittest.a(libunittest_a-test.o): In function `all_tests':
> /usr/oms/src/wget/src/test.c:51: undefined reference to `test_find_key_value'
> /usr/oms/src/wget/src/test.c:52: undefined reference to `test_find_key_values'
> /usr/oms/src/wget/src/test.c:53: undefined reference to `test_has_key'
> Please add a #ifdef to src/test.c and also mention libmetalink in 
> README.checkout.
I have repaired this problem. I have also conditionally disabled the
Metalink Python tests (whenever Metalink support is not compiled). Thus,
Wget should work fine without neither of them. (Both make and make-check.)
Should I list these dependencies as optional in the README.checkout?
> 
> It seems that libmetalink hasn't been packaged by Debian yet. I'll come back 
> when I have libmetalink installed...
I see. The 0.13 version is not yet available on ArchLinux either, so I
am compiling it manually at this moment.
> (I'll find some time at the weekend).
Please note that I will not be able to commit changes after tomorrow
night (the schedule of my GSOC is altered). However, if you come up with
any more issues before that time, I will do my best to resolve them.

Thank you,
Hubert
> 
> Regards, Tim
> 
> On Friday 03 July 2015 00:56:21 Hubert Tarasiuk wrote:
>> I have adjusted some comments to reflect the current libmetalink situation.
>>
>> Moreover, I added another option: --preferred-location=<location> that
>> can be used to give priority to certain Metalink resources based on
>> their location.
>>
>> These changes are presented in three additional commits (10, 11, 12) for
>> easier review (against previous patches). They should be probably
>> squashed before merging:
>> squash 1,9,10,11 into one
>> squash 5,12 into one
>

0001-Metalink-support.patch
Description: Text Data

0002-Start-HTTP-test-only-when-calling-begin.patch
Description: Text Data

0003-Test-case-for-Metalink-in-XML.patch
Description: Text Data

0004-Support-multiple-headers-with-same-name-in-Python-te.patch
Description: Text Data

0005-Test-case-for-Metalink-over-HTTP.patch
Description: Text Data

0006-Unit-test-for-find_key_value.patch
Description: Text Data

0007-Unit-test-for-has_key.patch
Description: Text Data

0008-Unit-test-for-find_key_values.patch
Description: Text Data

0009-Move-some-Metalink-related-code-from-http.c-to-metal.patch
Description: Text Data

0010-Support-at-most-one-file-signature.-Adapt-comments-t.patch
Description: Text Data

0011-Geolocation-support-for-Metalink-resources.patch
Description: Text Data

0012-Test-preferred-location-in-Metalink-over-HTTP-test-c.patch
Description: Text Data

signature.asc
Description: OpenPGP digital signature