bug-wget
[Top][All Lists]
Advanced

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

[bug #61140] wget 1.21.2 breaks metalink support on 32-bit x86


From: Michal Ruprich
Subject: [bug #61140] wget 1.21.2 breaks metalink support on 32-bit x86
Date: Thu, 14 Oct 2021 07:57:24 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Follow-up Comment #3, bug #61140 (project wget):

Hi Jan,

I was trying to build the new version and hit a problem with failing tests for
metalink. Is it possible that it is related? What was the thing that broke for
metalink in your case? Was it the build or the tests? I see metalink tests
failing only on 32bit arch so I thought it might be related but I was trying
to figure out what is going on for some time now and got nowhere.

The result of the metalink tests on 32bit is always the same(example is the
Test-metalink-http-xml.py test):

Retrieving from Metalink 'main.metalink.meta#2'
Error: Expected file main.metalink.meta#2.#1 not found..
Traceback (most recent call last):
  File "/root/rpmbuild/BUILD/wget-1.21.2/testenv/./Test-metalink-http-xml.py",
line 270, in <module>
    err = http_test.begin ()
  File "/root/rpmbuild/BUILD/wget-1.21.2/testenv/test/http_test.py", line 41,
in begin
    self.do_test()
  File "/root/rpmbuild/BUILD/wget-1.21.2/testenv/test/base_test.py", line 198,
in do_test
    self.post_hook_call()
  File "/root/rpmbuild/BUILD/wget-1.21.2/testenv/test/base_test.py", line 217,
in post_hook_call
    self.hook_call(self.post_configs, 'Post Test Function')
  File "/root/rpmbuild/BUILD/wget-1.21.2/testenv/test/base_test.py", line 207,
in hook_call
    conf.find_conf(conf_name)(conf_arg)(self)
  File "/root/rpmbuild/BUILD/wget-1.21.2/testenv/conf/expected_files.py", line
55, in __call__
    raise TestFailed('Expected file %s not found.' % file.name)
exc.test_failed.TestFailed: Expected file main.metalink.meta#2.#1 not found.

The main.metalink.meta#2 is downloaded but it stops there. Both the passing
tests and failing tests look similar and I was not able to figure out why this
breaks. Is it possible that this could be related?

Thanks for any tips I am really out of clues here.
Michal Ruprich

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61140>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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