On Tue, 18 Mar 2025 14:14:02 +0000
Stuart Henderson <stu@spacehopper.org> wrote:

> On 2025/03/18 17:04, emulti@disroot.org wrote:
> > On Mon, 17 Mar 2025 19:53:39 +0000
> > Stuart Henderson <stu@spacehopper.org> wrote:
> > 
> > > adding port maintainer to CCs;
> > > 
> > > On 2025/03/18 00:35, emulti@disroot.org wrote:
> > > > I would like to try and enable the Bonjour/mDNS protocol for net/pidgin, to trial it as a serverless instant messaging solution for a deployment of diskless OpenBSD clients. 
> > > > 
> > > > Looking back through the archives, it seems Bonjour was disabled in the port as long ago as 2008 (when 2.4.2 was committed), though no reason was mentioned in the commit message.
> > > > 
> > > > I naively tried to remove the --disable-avahi line in the CONFIGURE_ARGS, and adding avahi-client and avahi-glib to WANTLIBS for libpurple, as this is what the configure script seems to look for:
> > > 
> > > WANTLIB updates are normally done based on "make port-lib-depends-check"
> > > but you'll need to take care of PLISTs fiiii.
> > > 
> > > > $ diff Makefile.orig Makefile 
> > > > 43c43
> > > > < WANTLIB-libpurple= crypto gadu meanwhile ssl silc silcclient ${WANTLIB}
> > > > ---
> > > > > , = avahi-glib avahi-client crypto gadu meanwhile ssl silc silcclient ${WANTLIB}
> > > > 64a65
> > > > >                       net/avahi \
> > > > 76,77c77
> > > > < CONFIGURE_ARGS+= --disable-avahi \
> > > > <                --disable-cap \
> > > > ---
> > > > > CONFIGURE_ARGS+= --disable-cap \
> > > > 
> > > > The Bonjour plugin gets built, and there are no build errors. But on launching Pidgin, and attempting to create a new account, Bonjour is absent from the list of protocols. Avahi is installed and avahi-daemon is running. 
> > > > 
> > > > No doubt this is because I have left out something essential in the Makefile due to lack of porting experience. Can anyone assist with advice on how to proceed?
> > > 
> > > A new plugin module is built, libbonjour.so, this needs adding to the
> > > relevant PLIST. "make uodate-plist" is the normal way to update this but
> > > it sometimes needs tweaking - in this case it ends up in the wrong PLIST
> > > by default. So you'd need to add
> > > 
> > > @so lib/purple-2/libbonjour.so
> > > 
> > > to PLIST-libpurple, and then update wantlib as mentioned above.
> > > 
> > > > Is there a particular reason for disabling Bonjour in Pidgin, such as security concerns? The protocol won't be used by Pidgin unless an account is added with that protocol, as I understand it. If it can be simply re-enabled and there are no blocking concerns, can Bonjour support be added back to the port?
> > > 
> > > Prior to that the port would have picked up avahi and built the extra
> > > plugin if avahi was present during configure, but it wouldn't be
> > > included in the package. This causes problems during bulk builds where
> > > other packages are added/removed all the time. So that commit didn't
> > > change anything for packages, just fix a sporadic problem.
> > > 
> > > Regarding adding it, the question would be about whether the extra
> > > runtime dependency is wanted. Over to the maintainer for that.
> > > 
> > > > thanks in advance for all assistance
> > > > 
> > > > -- 
> > > > Chris Billington 
> > > > 
> > 
> > Thanks for the help Stuart.
> > I added avahi-common avahiclient and avahi-glib to WANTLIB-libpurple
> > make port-lib-depends-check   gives:
> > 
> > libpurple-2.14.13p1(net/pidgin,-libpurple):
> > Bogus WANTLIB: avahi-glib.0 (/usr/local/lib/purple-2/libbonjour.so) (NOT REACHABLE)
> > *** Error 1 in target 'port-lib-depends-check' (ignored)
> > 
> > But if I remove avahi-glib from WANTLIB, it complains:
> > 
> > libpurple-2.14.13p1(net/pidgin,-libpurple):
> > Missing lib: avahi-glib.0 (/usr/local/lib/purple-2/libbonjour.so) (NOT REACHABLE)
> > *** Error 1 in target 'port-lib-depends-check' (ignored)
> > 
> > But the package avahi-glib is installed and is used in the build below.
> > I haven't been able to work out why this happens.
> > 
> > Trying to follow the steps in the Porters Guide, I made the manual changes to PLIST as described, then
> > 
> > make fake (libbonjour.so gets built)
> > 
> > make update-plist (and confirmed @so lib/purple-2/libbonjour.so still exists in pkg/PLIST-libpurple:
> > 
> > grep bonjour pkg/*                                                                           
> > pkg/PLIST-libpurple:@so lib/purple-2/libbonjour.so
> > pkg/PLIST-libpurple.orig:@so lib/purple-2/libbonjour.so
> > 
> > But doing amake clean,  'make build' followed by 'doas make install', libbonjour.so doesn't get installed in /usr/local/lib/purple-2, so there is still no bonjour protocol available when the application is run.
> > 
> > No doubt I am doing something silly...? But what?
> 
> Diff (with a little other cleanup) looks like this. Some people
> do have _opinions_ on avahi though.
> 
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/net/pidgin/Makefile,v
> diff -u -p -r1.167 Makefile
> --- Makefile	28 Jan 2025 14:49:51 -0000	1.167
> +++ Makefile	18 Mar 2025 14:12:54 -0000
> @@ -14,9 +14,9 @@ FULLPKGPATH$i= ${PKGPATH},$i${FLAVOR_EXT
>  CATEGORIES=	net
>  SITES=		${SITE_SOURCEFORGE:=pidgin/}
>  EXTRACT_SUFX=	.tar.bz2
> -REVISION-finch=	1
> -REVISION-libpurple= 2
> -REVISION-main=	1
> +REVISION-finch=	2
> +REVISION-libpurple= 3
> +REVISION-main=	2
>  
>  SHARED_LIBS=	jabber		0.0 \
>  		purple		7.1 \
> @@ -31,7 +31,7 @@ PERMIT_PACKAGE=	Yes
>  
>  COMPILER=	base-clang ports-gcc
>  
> -WANTLIB=	c dbus-1 dbus-glib-1 execinfo ffi gio-2.0 glib-2.0 gmodule-2.0 \
> +WANTLIB=	c dbus-1 dbus-glib-1 ffi gio-2.0 glib-2.0 gmodule-2.0 \
>  		gobject-2.0 gthread-2.0 iconv idn intl lzma m pcre2-8 pthread \
>  		xml2 z
>  WANTLIB-main=	X11 Xau Xdmcp ICE SM Xcomposite Xcursor Xdamage Xext Xfixes \
> @@ -40,7 +40,8 @@ WANTLIB-main=	X11 Xau Xdmcp ICE SM Xcomp
>  		gtk-x11-2.0 harfbuzz jpeg pango-1.0 pangocairo-1.0 \
>  		pangoft2-1.0 pixman-1 png purple xcb-render xcb-shm xcb \
>  		${COMPILER_LIBCXX} ${WANTLIB}
> -WANTLIB-libpurple= crypto gadu meanwhile ssl silc silcclient ${WANTLIB}
> +WANTLIB-libpurple= avahi-client avahi-common avahi-glib crypto gadu \
> +		meanwhile silc silcclient ssl ${WANTLIB}
>  WANTLIB-finch=	X11 curses gnt panel purple xcb ${WANTLIB}
>  
>  MODULES=	textproc/intltool \
> @@ -56,12 +57,12 @@ LIB_DEPENDS-main=	${LIB_DEPENDS} \
>  			x11/gtk+2
>  RUN_DEPENDS-finch=	# empty
>  LIB_DEPENDS-finch=	${LIB_DEPENDS} \
> -			${MODPY_LIB_DEPENDS} \
>  			devel/libgnt
>  RUN_DEPENDS-libpurple=	${MODGCONF2_RUN_DEPENDS}
>  LIB_DEPENDS-libpurple=	${LIB_DEPENDS} \
>  			devel/libidn \
>  			devel/silc-toolkit \
> +			net/avahi,-glib \
>  			net/meanwhile \
>  			net/libgadu
>  
> @@ -73,8 +74,7 @@ USE_GMAKE=	Yes
>  CONFIGURE_STYLE= autoreconf
>  AUTOCONF_VERSION= 2.71
>  AUTOMAKE_VERSION= 1.16
> -CONFIGURE_ARGS+= --disable-avahi \
> -		 --disable-cap \
> +CONFIGURE_ARGS+= --disable-cap \
>  		 --disable-doxygen \
>  		 --disable-farstream \
>  		 --disable-gevolution \
> Index: pkg/PLIST-libpurple
> ===================================================================
> RCS file: /cvs/ports/net/pidgin/pkg/PLIST-libpurple,v
> diff -u -p -r1.28 PLIST-libpurple
> --- pkg/PLIST-libpurple	11 Mar 2022 19:46:55 -0000	1.28
> +++ pkg/PLIST-libpurple	18 Mar 2025 14:12:54 -0000
> @@ -90,6 +90,7 @@ lib/libpurple.la
>  lib/pkgconfig/purple.pc
>  lib/purple-2/
>  @so lib/purple-2/autoaccept.so
> +@so lib/purple-2/libbonjour.so
>  @so lib/purple-2/buddynote.so
>  @so lib/purple-2/dbus-example.so
>  @so lib/purple-2/idle.so

thanks very much indeed Stuart.
+			net/avahi,-glib \
This was the missing piece. So avahi-glib is a "Multi-package" rather than something that exists in its own right?
make port-lib-depends-check still seems to suggest execinfo be in WANTLIB. This seems to be some sort of backtracing utility. By removing it, are you indicating that it's non-essential? Bonjour in Pidgin now works fine in my tests, without enabling Multicast. 
I also have my reservations about avahi (and complexity-adding things like gvfs, d-bus, and other Gnome-y stuff). In the current use case I am investigating, of Diskless clients running an Xfce desktop, it already gets pulled in by packages like cups-browsed, used to discover printer queues set up on the server in a configurationless manner. Similarly gvfs/dbus are required for the Trash support in file managers that basic-level users expect to have. My approach to this mDNS necessary evil is to confine it to the client network with pf.
Maybe the port could have a flavor added to include Bonjour, so that avahi-adverse folks can avoid it? But if a user has got as far as installing Pidgin, they probably have a load of desktop stuff anyway.
-- 
Chris Billington