PASS: test_toolarge_request_headers make[5]: Leaving directory '/var/tmp/portage/net-libs/libmicrohttpd-1.0.1-r1/work/libmicrohttpd-1.0.1-abi_x86_32.x86/src/testcurl' make[5]: Entering directory '/var/tmp/portage/net-libs/libmicrohttpd-1.0.1-r1/work/libmicrohttpd-1.0.1-abi_x86_32.x86/src/testcurl' PASS: test_toolarge_reply_headers make[5]: Leaving directory '/var/tmp/portage/net-libs/libmicrohttpd-1.0.1-r1/work/libmicrohttpd-1.0.1-abi_x86_32.x86/src/testcurl' make[5]: Entering directory '/var/tmp/portage/net-libs/libmicrohttpd-1.0.1-r1/work/libmicrohttpd-1.0.1-abi_x86_32.x86/src/testcurl' FAIL: test_tricky_url make[5]: Leaving directory '/var/tmp/portage/net-libs/libmicrohttpd-1.0.1-r1/work/libmicrohttpd-1.0.1-abi_x86_32.x86/src/testcurl' make[5]: Entering directory '/var/tmp/portage/net-libs/libmicrohttpd-1.0.1-r1/work/libmicrohttpd-1.0.1-abi_x86_32.x86/src/testcurl' ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_systemd_abi32+64_test-20250409-195823 KEYWORDED/UNMASKED [gcc-15] Requested by sam <sys-devel/gcc-15.0.9999:15 [meson] Please re-assign to ztrawhcse@ if it works with regular meson. <dev-build/meson-9999 The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-14 * llvm-config: Python 3.12.9 HEAD of ::gentoo commit 83c1d5617907fa19d6cfc98f540af0c86ecc39a8 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Wed Apr 9 22:20:23 2025 +0000 2025-04-09 22:20:23 UTC The tinderbox task was: %emerge -1u --selective=n --deep=0 =$(portageq best_visible / sys-devel/gcc) emerge -qpvO =net-libs/libmicrohttpd-1.0.1-r1 [ebuild N ] net-libs/libmicrohttpd-1.0.1-r1 USE="epoll eventfd ssl test thread-names -debug -static-libs -verify-sig" ABI_X86="32 (64) (-x32)"
Created attachment 924260 [details] emerge-info.txt
Created attachment 924261 [details] emerge-history.txt
Created attachment 924262 [details] environment
Created attachment 924263 [details] etc.portage.tar.xz
Created attachment 924264 [details] logs.tar.xz
Created attachment 924265 [details] net-libs:libmicrohttpd-1.0.1-r1:20250409-232744.log.xz
Created attachment 924266 [details] qlist-info.txt
Created attachment 924267 [details] temp.tar.xz
As per the linked issue, not a cURL bug. It's _probably_ safe to skip this test, the actual "issue" is `\r`in a test case URI. The handling has changed between cURL 8.12 and 8.13 where it is now encoded rather than sent as an invalid request; if there _is_ a bug it's the old behaviour. Debian patch via the SUSE bug to skip the test: https://salsa.debian.org/debian/libmicrohttpd/-/blob/master/debian/patches/FTBFS_testcurl_tricky_url.patch
According to the logs (test_tricky_url.log): Wrong URI: `/one%0dtwo', line: 304 FAIL test_tricky_url (exit status: 22) It means that initial request URI string "/one\rtwo" is URL-encoded by libcurl. This is wrong, as flag CURLU_URLENCODE is not used for the request. Unrelated, but flags CURLU_PATH_AS_IS and CURLU_ALLOW_SPACE are used for the URL, so libcurl must not change the content. See https://git.gnunet.org/libmicrohttpd.git/tree/src/testcurl/test_tricky.c?h=v1.0.1#n780 https://git.gnunet.org/libmicrohttpd.git/tree/src/testcurl/test_tricky.c?h=v1.0.1#n189 https://curl.se/libcurl/c/curl_url_get.html Looks like libcurl bug. In short: "/one\rtwo" is encoded as "/one%0dtwo", while CURLU_URLENCODE is not set.
Wrong link to libcurl documentation. The correct link: https://curl.se/libcurl/c/curl_url_set.html
libcurl bug: https://github.com/curl/curl/issues/17029
https://bugs.gnunet.org/view.php?id=9664 https://bugzilla.opensuse.org/show_bug.cgi?id=1241036 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101232
Also in https://github.com/curl/curl/issues/16874
I'd already added most of those links to the bug apart from your new one (as it didn't exist at the time), they're in the See Also field.
(In reply to Sam James from comment #15) > I'd already added most of those links to the bug apart from your new one (as > it didn't exist at the time), they're in the See Also field. Missed them. My bad. I'll implement a proper patch in the stable libmicrohttpd branch and then add it as patch for net-libs/libmicrohttpd-1.0.1. Should be finished today.
(In reply to Karlson2k from comment #16) > (In reply to Sam James from comment #15) > > I'd already added most of those links to the bug apart from your new one (as > > it didn't exist at the time), they're in the See Also field. > > Missed them. My bad. > I'll implement a proper patch in the stable libmicrohttpd branch and then > add it as patch for net-libs/libmicrohttpd-1.0.1. > Should be finished today. No problem -- and thank you!
The patch is here: https://git.gnunet.org/libmicrohttpd.git/patch/?id=036f8fdec2802e48e2555b2caf381bb1c565ab82 I'll update ebuild after local testing.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2d39e230d9f4e899241ff6e7aeb97ebf4cad5a52 commit 2d39e230d9f4e899241ff6e7aeb97ebf4cad5a52 Author: Evgeny Grin (Karlson2k) <k2k@drgrin.dev> AuthorDate: 2025-04-13 13:27:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-04-13 20:37:31 +0000 net-libs/libmicrohttpd: fix tests with curl-8.13 libcurl changed behaviour, tests needs to be adapted. Closes: https://bugs.gentoo.org/953520 Signed-off-by: Evgeny Grin (Karlson2k) <k2k@drgrin.dev> Closes: https://github.com/gentoo/gentoo/pull/41572 Signed-off-by: Sam James <sam@gentoo.org> ...microhttpd-0.9.76-fix-test_tricky-libcurl.patch | 62 ++++++++++++++++++++++ .../libmicrohttpd/libmicrohttpd-0.9.77-r1.ebuild | 6 ++- net-libs/libmicrohttpd/libmicrohttpd-0.9.77.ebuild | 6 ++- .../libmicrohttpd/libmicrohttpd-1.0.1-r1.ebuild | 6 ++- net-libs/libmicrohttpd/libmicrohttpd-1.0.1.ebuild | 6 ++- 5 files changed, 82 insertions(+), 4 deletions(-)