dnsmasq failed to build from source in Fedora rawhide/f42 https://koji.fedoraproject.org/koji/taskinfo?taskID=127945105 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild Please fix dnsmasq at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, dnsmasq will be orphaned. Before branching of Fedora 43, dnsmasq will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
Created attachment 2068842 [details] build.log
Created attachment 2068843 [details] root.log file root.log too big, will only attach last 32768 bytes
Created attachment 2068844 [details] state.log
*** Bug 2339707 has been marked as a duplicate of this bug. ***
Oh, this would be a tricky change. dnsmasq uses int iface_enumerate(int family, void *parm, int (*callback)()) function prototype to issue callbacks. That has changed with recent compiler, it is considered int callback(void) now, instead of just unlisted parameters. Problem is, dnsmasq uses this function to call *different* set of parameters from different places, depending on whether handler function should process IPv4 or IPv6 addresses. It won't work to just add typedef of appropriate function, because there are conflicting possible definitions in the same function. Example from network.c: ... // Line 836 ret = iface_enumerate(AF_INET6, ¶m, iface_allowed_v6); if (ret < 0) goto again; else if (ret) { ret = iface_enumerate(AF_INET, ¶m, iface_allowed_v4); ... static int iface_allowed_v6(struct in6_addr *local, int prefix, int scope, int if_index, int flags, int preferred, int valid, void *vparam); static int iface_allowed_v4(struct in_addr local, int if_index, char *label, struct in_addr netmask, struct in_addr broadcast, void *vparam); These parameters are *very* different, creating common type does not seem to be simple. Perhaps explicit cast might solve it enough, hiding the problem more than solving it appropriately. These callbacks do a bit different thing when called with different family to iface_enumerate. It implements common part at first, then changes behaviour to do different thing for AF_INET and AF_INET6, then quite different for AF_UNSPEC and also AF_LOCAL. Ideally these might be split to use static functions for common part, but otherwise have different iface_enumerate function with different callback function type. Because effectively they do significantly different tasks, which is not obvious on the first glance. Anyway, this seems should be discussed on upstream list first.
There were already upstream report with this: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2024q4/017855.html Gentoo bug: https://bugs.gentoo.org/945183 Which contains also working fix, although it is not very pretty. It is applied at commit: https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=da2cc84854a01dd08a8bb4161428be20b83a5ec7
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
FEDORA-2025-7d03d3d62c (dnsmasq-2.90-6.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-7d03d3d62c