for reference: https://bugs.sabayon.org/show_bug.cgi?id=4495 netatalk will fallback and link to dns_sd instead of avahi when mdnsresponder-compat useflag is set for avahi. this will make afpd panic repeatedly when netatalk service is started. also compilation with debug useflag fails entirely in this case. Reproducible: Always
+ 01 Dec 2013; Justin Lecher <jlec@gentoo.org> netatalk-3.0.5-r1.ebuild, + netatalk-3.1.0-r1.ebuild: + Avoid linking against dns_sd, #492716 +
issue persists with 3.1.0-r1
(In reply to masc from comment #2) > issue persists with 3.1.0-r1 Which USE do you have for avahi?
(In reply to Justin Lecher from comment #3) > Which USE do you have for avahi? autoipd dbus gdbm gtk3 howl-compat introspection ipv6 mdnsresponder-compat python
the ebuild has avahi? ( net-dns/avahi[dbus,-mdnsresponder-compat] ) So it should be blocked. Please attach a build.log.
issue occurs on a sabayon box. just checked, and it does indeed block on my gentoo system. is there an upstream bug for this or is it generally not possible to have avahi support with mdnscompat enabled?
(In reply to masc from comment #6) > issue occurs on a sabayon box. just checked, and it does indeed block on my > gentoo system. is there an upstream bug for this or is it generally not > possible to have avahi support with mdnscompat enabled? Fabio, could you please check for sabayon?
We have USE=mdnsresponder-compat for net-dns/avahi and I'm not sure whether it's safe to disable it yet. To me, the bug is in netatalk, if it doesn't work with libdns_sd, it should not link against it to begin with.
Could you please report this bug to netatalk upstream? I searched for a solution, but didn't found any.
Any please attach the config file you are using.
I just recompiled avahi with mdnsresponder-compat and patched netatalk-3.1.6 to allow this useflag. netatalk works fine and does not crash on startup, but uses the old dns_sd library : Dec 14 12:01:01 krasus netatalk[22576]: *** WARNING *** The program 'netatalk' uses the Apple Bonjour compatibility layer of Avahi. Dec 14 12:01:01 krasus netatalk[22576]: *** WARNING *** Please fix your application to use the native API of Avahi! Dec 14 12:01:01 krasus netatalk[22576]: *** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=netatalk> I reported this upstream : https://sourceforge.net/p/netatalk/bugs/586/
So the resolution here is that netatalk should prefer the native avahi API instead of libdns_sd. The issue I have here is that packages that implement AirTunes/AirPlay support must use libdns_sd and the fact that the USE flag is explicitly blocked means that there's no way to have those applications installed at the same time as netatalk.
Created attachment 414178 [details] Flip the zeroconf support check to favor Avahi over mDNSResponder This change should do the check to make netatalk favor Avahi over mDNSResponder when both are available.
(In reply to Doug Goldstein from comment #12) > So the resolution here is that netatalk should prefer the native avahi API > instead of libdns_sd. > > The issue I have here is that packages that implement AirTunes/AirPlay > support must use libdns_sd and the fact that the USE flag is explicitly > blocked means that there's no way to have those applications installed at > the same time as netatalk. Looking more at zeroconf, my statement that AirTunes/AirPlay support needs libdns_sd is wrong. It just happens to be the two I stumbled on didn't support Avahi and need the mDNSResponder compat bits.
I've submitted the patch upstream and hopefully its included for 3.1.8.
(In reply to Doug Goldstein from comment #15) > I've submitted the patch upstream and hopefully its included for 3.1.8. Thanks for looking into the fix. Feel free to patch our ebuilds in the tree.
Thanks for the report. Fixed in http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ba99061687d61c49edd80ee1c4ec725d55fae7e9
