Re: update net/profanity

On Tue Sep 03, 2019 at 10:38:17PM +0000, Lucas wrote:
> Stuart Henderson <stu@spacehopper.org> wrote:
> > Please only use GH_* if using github's autogenerated tarball. If you are
> > setting MASTER_SITES anyway then it's not wanted/needed - for this it should
> > just have DISTNAME/MASTER_SITES/HOMEPAGE.
>
> Fixed. There are some other packages that define both GH_* and
> MASTER_SITES and could be fixed. If there is interest, I can send a
> different email addressing that.
>
> Maybe it should be added to bsd.port.mk(5)?

First of all thanks for your work here. Please just replace the out-dated URL:

Index: Makefile
===================================================================
RCS file: /cvs/ports/net/profanity/Makefile,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 Makefile
--- Makefile 12 Jul 2019 20:48:44 -0000 1.10
+++ Makefile 3 Sep 2019 19:41:22 -0000
@@ -1,22 +1,21 @@
# $OpenBSD: Makefile,v 1.10 2019/07/12 20:48:44 sthen Exp $

COMMENT = console based XMPP client
-DISTNAME = profanity-0.6.0
+DISTNAME = profanity-0.7.0
CATEGORIES = net
-REVISION = 0

-HOMEPAGE = http://www.profanity.im/
+HOMEPAGE = https://profanity-im.github.io/
MAINTAINER = Rafael Sadowski <rsadowski@openbsd.org>

# GPLv3+
PERMIT_PACKAGE = Yes

-MASTER_SITES = http://www.profanity.im/
+MASTER_SITES = https://profanity-im.github.io/


>
> > This is because of the post-patch target using a sed -i on configure.ac,
> > causing it to have a newer timestamp than the generated files. This
> > can be fixed by removing that post-patch target (it doesn't make sense
> > anyway), the AUTO* lines, and change to CONFIGURE_STYLE=gnu.
>
> Thanks for pointing this. As you said, removing that target and setting
> CONFIGURE_STYLE=gnu builds, passes the tests and runs fine. Also we can
> drop BUILD_DEPENDS+=${MODGNU_AUTO*} because of it.
>
> That line was changed from /usr/local to ${TRUEPREFIX} in r1.4, and I
> think it tries to address a hardcoded /usr/local in the project's
> configure.ac, line 190:
>
> [test "x$PLATFORM" = xopenbsd],
> [AC_CHECK_FILE([/usr/local/include/ereadline],
> [LIBS="-lereadline $LIBS"
> AM_CPPFLAGS="-I/usr/local/include/ereadline $AM_CPPFLAGS"
> AM_LDFLAGS="-L/usr/local/lib $AM_LDFLAGS"
> AC_SUBST(AM_LDFLAGS)])],

Exactly, that was the idea.

>
> I think that using ${TRUEPREFIX} in that line is a mistake, but I'm not
> sure (out of ignorance) if such replacement doesn't make sense. Maybe
> the correct approach is to try to upstream a fix for it, relying on
> pkg_info -qe devel/readline.

This was my solution better diffs welcome. I think pkg_info is not the
right way.

>
> > > WANTLIB += assuan c crypto curl curses ereadline expat ffi gcrypt
> > > WANTLIB += gio-2.0 glib-2.0 gmodule-2.0 gobject-2.0 gpg-error
> > > WANTLIB += gpgme iconv intl m mesode nghttp2 otr pcre pthread
> > > -WANTLIB += ${MODPY_WANTLIB} ssl util z
> > > +WANTLIB += ${MODPY_WANTLIB} signal-protocol-c ssl util z
> >
> > "make port-lib-depends-check" says this:
> >
> > profanity-0.7.0(net/profanity):
> > Extra: python3.7m.0 util.13
> >
> > This isn't new but from what I see it's not building any of the python
> > parts. rsadowski, any idea what's going on there?

I don't have the problem, because placed the links:

ln -sf /usr/local/bin/python3.7 /usr/local/bin/python
ln -sf /usr/local/bin/python3.7-config /usr/local/bin/python-config
ln -sf /usr/local/bin/pydoc3.7 /usr/local/bin/pydoc

on my system.

>
> Dunno if it helps, but configure shows
>
> checking for python-config... no
> configure: Python development package not found, Python plugin support disabled.
>
> This happens on line 83 of configure.ac, which just check for
> python-config instead of python[23]-config. I went back to autoconf
> configure and added
>
> sed -i s,python-config,python${MODPY_VERSION}-config, \
> ${WRKSRC}/configure.ac

This works for me without my placed links.

>
> to post-configure. It correctly detects python support and builds fine,
> passes the tests, runs and can load and use python plugins, thing that
> didn't happen before.
>
> Now, I don't know if patching configure.ac in post-configure target is
> the right thing(TM). Is it correct to override pre-configure instead?

I think if you do this in post-configure your are to late and the party
is over but I'm not very familiar with the GNU autotools.

> Should I use patch target and write a proper patch for configure.ac?
>
> After we have consensus about all this I'll send an updated patch.
>
> Thanks for all the input!
>
> -Lucas
>