On Tue, 18 Mar 2025 14:14:02 +0000
Stuart Henderson <s...@spacehopper.org> wrote:
> On 2025/03/18 17:04, emu...@disroot.org wrote:
> > On Mon, 17 Mar 2025 19:53:39 +0000
> > Stuart Henderson <s...@spacehopper.org> wrote:
> >
> > > adding port maintainer to CCs;
> > >
> > > On 2025/03/18 00:35, emu...@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
