Arch Linux User Repository

Oh wow, well done figuring that out! 👍️

It's not exactly a Manjaro issue -- after all, the package built correctly on two of my four Manjaro machines. But I finally tracked it down to the fact that the failing machines didn't have an ipv6 localhost entry in /etc/hosts. Adding that was enough to pass all five of the failing test.

...so if anyone else experiences a similar problem, check that /etc/hosts contains

::1        localhost

@smw

it maybe a Manjaro specific issue, the testsuite passes fine on my vanilla Arch setup.

============================================================================
Testsuite summary for wget2 2.3.0
============================================================================
# TOTAL: 91
# PASS:  91
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

You're welcome no worries.

Yeah so the explanation is bound to be something to do with paru keeping files between builds in its cache.

At the bottom of paru's README it says:

Paru is not an official tool. If paru can't build a package, you should first check if makepkg can successfully build the package. If it can't, then you should report the issue to the maintainer. Otherwise, it is likely an issue with paru and should be reported here.

So the first thing to do would be:

git clone https://aur.archlinux.org/wget2.git
cd wget2
makepkg --syncdeps

which if the test still fails, narrows it down to a dependency issue on that machine (something that is or is not installed, in a specific version maybe or in a broken state).

But if we rewind to the paru question, why the first thing to do when something fails is to remove paru from the equation by using makepkg is that when you do paru -Syu, you have stuff in $HOME/.cache/paru/clone/wget2 that is irrelevant, possibly outdated, and that might get in the way of the build (or the tests). By default, paru keeps those files, just pulls any updates from git, and tries to makepkg on top of the whole mess. It keeps those files from one run to the next because that might save download time, but I think it can be configured to delete them automatically, see man paru.conf (yeah there is the CleanAfter option).

Of course, you can just rm -fR "$HOME/.cache/paru/clone/wget2" then paru -S wget2 again, and see if that helps, but it's safer and cleaner to use the approach described above. And finally: paru also has it's own way of setting up for packages to be build in a clean chroot, see the --chroot flag (and corresponding .conf option).

@marcool04 Thank you for those suggestions. The build attempts so far have all been done using paru, in all cases initiated with a simple

paru -Syu

I didn't think of building in a clean chroot, and I wasn't aware of clean-chroot-manager, so thank you for pointing that out. For now I'll probably just follow your other idea of copying the package file from one of the two successful machines.

Meanwhile I was hoping someone might have an idea about what part of my environment might differ in a way that would cause those specific failures, and even more that someone might suggest why the build would fail and then succeed on the same machine.

@swm since the package builds and runs its tests fine (you showed this yourself, and I just tested again in a clean chroot), this must mean that something on those systems is interfering. Avoiding this is the whole point of building in a clean chroot if you can set that up you'll save yourself a lot of trouble down the line (see also graysky2's clean-chroot-manager maybe).

If you tell us more about how you are running this on the failing machines it would help point you in the right direction: what exact commands are you running to get to those failing tests?

Also, in the interim, if you have managed to build it on one machine, then it would also be trivial to copy the package file to the other and install it there with pacman -U...

I just tried to update to version 2.3.0-1 on four machines, all running Manjaro. One of them succeeded on the first try, one succeeded on the second try after failing some tests on the first try, and two more are failing repeatedly in exactly the same way. The relevant test suite output is as follows:

PASS: test-post-handshake-auth
PASS: test-unlink
PASS: test-ocsp-server
PASS: test-ocsp-stap
FAIL: test-limit-rate-http2
PASS: test-timestamping
PASS: test-cookies
PASS: test-E-k
PASS: test-ignore-length
PASS: test-convert-file-only
PASS: test-download-attr
PASS: test-directory-prefix
PASS: test-level
FAIL: test-http2-multiplexing
FAIL: test-http2-stream-errors
FAIL: test-http2-connection-errors
FAIL: test-http2-settings
PASS: test-cert-key-usage
PASS: test-interrupt-response
PASS: test-connection-failure
PASS: test-span-hosts-domains
PASS: test-convert-links-css
PASS: test-gpg-valid
PASS: test-gpg-invalid
PASS: test-gpg-missing
PASS: test-gpg-styles
PASS: test-gpg-bad
PASS: test-gpg-save-failed
PASS: test-gpg-verify-no-file
PASS: test-plugin
PASS: test-https-proxy-auth.sh
PASS: test-waitretry
============================================================================
Testsuite summary for wget2 2.3.0
============================================================================
# TOTAL: 91
# PASS:  86
# SKIP:  0
# XFAIL: 0
# FAIL:  5
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log for debugging.
Some test(s) failed.  Please report this to bug-wget@gnu.org,
together with the test-suite.log file (gzipped) and your system
information.  Thanks.
============================================================================

The four machines share most of their configuration, so I don't understand why the outcome is inconsistent between them. I've looked at src/wget2-2.3.0/unit-tests/test-suite.log without being enlightened. Can anyone recommend a fix or workaround?

@a821 fixed

@a821 oh well noticed! I don't know how I managed to make that mistake... I'll request deletion of this package then, or possibly just allow it to merge with @tee's wget2 PKGBUILD

Cheers.

Edit: SOLVED!

The configure option --without-pcre does not exist. I believe it should be --without-libpcre