On Tue Sep 03, 2019 at 10:38:17PM +0000, Lucas wrote:
> Stuart Henderson <s...@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 <rsadow...@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
> 

Reply via email to