https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-python/txredisapi-1.4.10 fails tests. Discovered on: amd64 (internal ref: tinderbox_musl) System: MUSL-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#MUSL) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0015
Created attachment 887669 [details] build.log build log and emerge --info
The issue is that the redis-server fails to start because it cannot bind to ::1 in my case: 2985:M 15 Mar 2024 11:56:09.954 # Warning: Could not create server TCP listening socket ::1:6379: bind: Address not available 2985:M 15 Mar 2024 11:56:09.954 # Failed listening on port 6379 (TCP), aborting. Interestingly, it works with glibc for the same network configuration.
I investigated the issue further and portage does not create networking name space in musl system. `ip a` looks in src_test phase like this in musl system: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever but it looks different in glibc system: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 10.0.0.1/8 scope global lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host proto kernel_lo valid_lft forever preferred_lft forever it is different name space: in src_phase: net -> 'net:[4026532630]' host: net -> 'net:[4026532486]' Could it be portage issue?
The issue seems to be in portage. Commit 19e27e0415fd ("Add workaround for loading libc on musl") for bug #925311 fixes the issue for me.
Repurposing this bug for the portage fix https://github.com/gentoo/portage/commit/19e27e0415fd321c39104f7d687bcdc4f4132e24
We don't need a duplicate bug report.
Oh, I see, not a duplicate. Still, your test suite really cannot rely on network-sandbox. It's not guaranteed to be enabled.
I think it would be ok to CANTFIX this. A possible workaround would be to run something like this python program before trying to run tests: > import socket > import sys > > try: > with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock: > sock.bind(("127.0.0.1", 6379)) > except OSError: > sys.exit(1) You could then skip the tests if the pre-test fails.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f1e53b9368c215451e3af78b557d8b86a2db9677 commit f1e53b9368c215451e3af78b557d8b86a2db9677 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-04-28 00:31:29 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-04-28 00:31:29 +0000 sys-apps/portage: add 3.0.64 Closes: https://bugs.gentoo.org/925481 Closes: https://bugs.gentoo.org/675748 Closes: https://bugs.gentoo.org/712222 Closes: https://bugs.gentoo.org/920330 Closes: https://bugs.gentoo.org/925213 Closes: https://bugs.gentoo.org/925863 Closes: https://bugs.gentoo.org/925888 Closes: https://bugs.gentoo.org/925907 Closes: https://bugs.gentoo.org/926048 Closes: https://bugs.gentoo.org/926221 Closes: https://bugs.gentoo.org/927059 Closes: https://bugs.gentoo.org/927632 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.64.ebuild | 242 +++++++++++++++++++++++++++++++++ 2 files changed, 243 insertions(+)
