Re: Update libtool

2021-02-24 Thread Rafael Ávila de Espíndola
Stuart Henderson  writes:

> On 2021/02/23 17:17, Rafael Ávila de Espíndola wrote:
>> 
>> Stuart Henderson  writes:
>> 
>> > On 2021/02/23 15:25, Stuart Henderson wrote:
>> >> I'll do some testing, I'm using this updated diff
>> >
>> > Oh yuk, gnu m4 is now needed at runtime for libtoolize.
>> > Is there a way around that?
>> 
>> This is probably from
>> 
>>   - GNU M4 is required to run libtoolize in a directory with a
>> 'configure.ac' (or 'configure.in') that needs tracing to determine
>> what modes and directories have been specified.
>> 
>> But unfortunately I have no idea how to avoid it, sorry. Maybe
>> libtoolize could be on its own sub package and only that depends on m4?
>
> A subpackage for libtoolize makes no sense. libtoolize and the libtool.m4
> files are literally all that are used by most ports using devel/libtool.
> Perhaps it can be persuaded to run with /usr/bin/m4 though, it depends
> what it wants from gm4.

Scrap that then. It is the first time I hear about libtoolize and the
manual page made me think it was something that was run once when
starting a project that uses libtool:

DESCRIPTION
   Prepare a package to use libtool.

> Another problem showed up in the build,
>
> -
> configure.in:16: error: Autoconf version 2.62 or higher is required
>  
> /usr/local/share/aclocal/libtool.m4:96: LT_INIT is expanded from...
> /usr/local/share/aclocal/libtool.m4:100: AM_PROG_LIBTOOL is expanded from...
>  
> configure.in:16: the top level
>  
> autom4te-2.61: /usr/bin/m4 failed with exit status: 63
> aclocal-1.9: autom4te failed with exit status: 63
> -
>
> With this update everything that uses both devel/libtool and autoconf
> needs to use autoconf >= 2.62.
>
> $ grep devel/libtool /usr/local/share/ports-INDEX | grep autoconf | grep -v 
> 'autoconf/2\.6[2-9]' | cut -d'|' -f2

Interesting, so a project can depend on the gnu libtool both by depending
on devel/libtool or adding "USE_LIBTOOL = gnu"? I missed the first ones :-(

> audio/faad
> audio/fluidsynth
> audio/mp3blaster
> audio/swh-plugins
> audio/timidity
> audio/timidity,gtk2
> audio/timidity,xaw
> devel/ois
> emulators/x48
> games/numptyphysics
> games/numptyphysics,-npcomplete
> games/zangband
> games/zangband,no_x11
> graphics/agg
> graphics/geeqie
> misc/hfsplus
> net/ices2
> sysutils/colortail
> sysutils/inotify-tools

And given that it is better to just use the autoconf upstream uses, this
basically means waiting for these packages to change. Any idea how linux
distros handle this? I see, for example, that debian has many autoconf
versions, but only one version of libtool.

Cheers,
Rafael



Re: Update libtool

2021-02-23 Thread Rafael Ávila de Espíndola


Stuart Henderson  writes:

> On 2021/02/23 15:25, Stuart Henderson wrote:
>> I'll do some testing, I'm using this updated diff
>
> Oh yuk, gnu m4 is now needed at runtime for libtoolize.
> Is there a way around that?

This is probably from

  - GNU M4 is required to run libtoolize in a directory with a
'configure.ac' (or 'configure.in') that needs tracing to determine
what modes and directories have been specified.

But unfortunately I have no idea how to avoid it, sorry. Maybe
libtoolize could be on its own sub package and only that depends on m4?

Cheers,
Rafael



Re: Update libtool

2021-02-23 Thread Rafael Ávila de Espíndola


Stuart Henderson  writes:

> On 2021/02/23 07:44, Rafael Ávila de Espíndola wrote:
>> Thanks!
>> 
>> I see that you added
>> 
>>  touch -r .version Makefile.in aclocal.m4 m4/ltversion.m4 configure
>> 
>> Which I assume is to prevent make from trying to recreate those files. I
>> also see that you upgraded autoconf:
>
> Yes, it happens because the timestamps in the distfile were out of order.
> I added -dm to MAKE_FLAGS while I was figuring this out. None of the
> patches in the port touch autoconf/automake input files so this is ok.
>
>> AUTOCONF_VERSION= 2.69
>> 
>> But given the "touch", is autoconf still needed?
>
> It's needed for tests, I moved it to TEST_DEPENDS as well. (I made sure
> that those still work when libtool is configured/built with autoconf
> not present).
>
> Re AUTOCONF_VERSION, I checked the version of the bundled generated
> configure script and set the same, this is usually the best method for
> ports.

Makes sense. Thanks for the tips.

Cheers,
Rafael



Re: Update libtool

2021-02-23 Thread Rafael Ávila de Espíndola
Thanks!

I see that you added

 touch -r .version Makefile.in aclocal.m4 m4/ltversion.m4 configure

Which I assume is to prevent make from trying to recreate those files. I
also see that you upgraded autoconf:

AUTOCONF_VERSION= 2.69

But given the "touch", is autoconf still needed?

Thanks,
Rafael

Stuart Henderson  writes:

> I'll do some testing, I'm using this updated diff
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/libtool/Makefile,v
> retrieving revision 1.85
> diff -u -p -r1.85 Makefile
> --- Makefile  12 Jul 2019 20:44:40 -  1.85
> +++ Makefile  23 Feb 2021 15:22:13 -
> @@ -3,12 +3,10 @@
>  COMMENT-main=generic shared library support script
>  COMMENT-ltdl=GNU libtool system independent dlopen wrapper
>  
> -VERSION= 2.4.2
> +VERSION= 2.4.6
>  DISTNAME=libtool-${VERSION}
>  PKGNAME-main=${DISTNAME}
>  PKGNAME-ltdl=libltdl-${VERSION}
> -REVISION-main=   0
> -REVISION-ltdl=   1
>  CATEGORIES=  devel
>  MASTER_SITES=${MASTER_SITE_GNU:=libtool/}
>  
> @@ -21,8 +19,9 @@ MAINTAINER= Brad Smith   # GPLv2+
>  PERMIT_PACKAGE=  Yes
>  
> -AUTOCONF_VERSION= 2.67
> -BUILD_DEPENDS=   ${MODGNU_AUTOCONF_DEPENDS}
> +AUTOCONF_VERSION= 2.69
> +BUILD_DEPENDS=   devel/m4
> +TEST_DEPENDS=${MODGNU_AUTOCONF_DEPENDS}
>  
>  MAKE_ENV+= ${_lt_libs}
>  MAKE_FLAGS+= ${_lt_libs}
> @@ -45,6 +44,8 @@ RUN_DEPENDS-main=   devel/libtool,-ltdl
>  
>  pre-configure:
>   @cd ${WRKDIR}/bin && ln -sf /usr/bin/true g77
> + cd ${WRKSRC}; \
> + touch -r .version Makefile.in aclocal.m4 m4/ltversion.m4 configure
>  
>  do-test:
>   @cd ${WRKDIR}/bin && ln -sf \
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/libtool/distinfo,v
> retrieving revision 1.16
> diff -u -p -r1.16 distinfo
> --- distinfo  18 Jan 2015 03:13:17 -  1.16
> +++ distinfo  23 Feb 2021 15:22:13 -
> @@ -1,2 +1,2 @@
> -SHA256 (libtool-2.4.2.tar.gz) = s43kSGKphyk809jfrhxAnVFLbE55TryTZI/r+a/DiRg=
> -SIZE (libtool-2.4.2.tar.gz) = 2632347
> +SHA256 (libtool-2.4.6.tar.gz) = 471NXT0CWjbCHdavfqgYoq/NTfwepaF7OdeFS80MBuM=
> +SIZE (libtool-2.4.6.tar.gz) = 1806697
> Index: patches/patch-doc_libtool_texi
> ===
> RCS file: /cvs/ports/devel/libtool/patches/patch-doc_libtool_texi,v
> retrieving revision 1.4
> diff -u -p -r1.4 patch-doc_libtool_texi
> --- patches/patch-doc_libtool_texi22 Sep 2011 21:10:19 -  1.4
> +++ patches/patch-doc_libtool_texi23 Feb 2021 15:22:13 -
> @@ -1,11 +1,12 @@
>  $OpenBSD: patch-doc_libtool_texi,v 1.4 2011/09/22 21:10:19 jasper Exp $
>  doc/libtool.texi.origWed Jun  8 11:04:53 2011
> -+++ doc/libtool.texi Wed Jun  8 11:05:44 2011
> -@@ -11,16 +11,16 @@
> - @set MAILLIST the Libtool mailing list @email{libtool@@gnu.org}
> - @set objdir .libs
> +Index: doc/libtool.texi
> +--- doc/libtool.texi.orig
>  doc/libtool.texi
> +@@ -30,15 +30,15 @@ and with no Back-Cover Texts.  A copy of the license i
> + the section entitled ``GNU Free Documentation License''.
> + @end copying
>   
> --@dircategory GNU programming tools
> +-@dircategory Software development
>  +@dircategory Programming & development tools
>   @direntry
>   * Libtool: (libtool).   Generic shared library support script.
> @@ -13,11 +14,10 @@ $OpenBSD: patch-doc_libtool_texi,v 1.4 2
>   
>   @dircategory Individual utilities
>   @direntry
> --* libtool-invocation: (libtool)Invoking libtool.
> -+* libtool-invocation: (libtool) Invoking libtool.
> - Running the @code{libtool} 
> script.
> --* libtoolize: (libtool)Invoking libtoolize. Adding libtool support.
> -+* libtoolize: (libtool) Invoking libtoolize. Adding libtool support.
> +-* libtool-invocation: (libtool)Invoking libtool. Running the @code{libtool} 
> script.
> +-* libtoolize: (libtool)Invoking libtoolize.  Adding libtool support.
> ++* libtool-invocation: (libtool) Invoking libtool. Running the 
> @code{libtool} script.
> ++* libtoolize: (libtool) Invoking libtoolize.  Adding libtool 
> support.
>   @end direntry
>   
> - @ifnottex
> + @titlepage
> Index: patches/patch-libltdl_config_ltmain_sh
> ===
> RCS file: /cvs/ports/devel/libtool/patches/patch-libltdl_config_ltmain_sh,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-libltdl_config_ltmain_sh
> --- patches/patch-libltdl_config_ltmain_sh1 Nov 2011 16:07:31 -   
> 1.2
> +++ patches/patch-libltdl_config_ltmain_sh23 Feb 2021 15:22:13 -
> @@ -1,9 +1,11 @@
> -$OpenBSD: patch-libltdl_config_ltmain_sh,v 1.2 2011/11/01 16:07:31 jasper 
> Exp $
>  libltdl/config/ltmain.sh.origMon Oct 17 06:19:35 2011
> -+++ libltdl/config/ltmain.sh Sat Oct 29 07:05:47 2011
> -@@ -2714,51 

Re: Update libtool

2021-02-20 Thread Rafael Ávila de Espíndola
Rafael Ávila de Espíndola  writes:

>>> lang/rust:
>>> LLVM ERROR: invalid sh_type for string table section [index 34]: expected 
>>> SHT_STRTAB, but got SHT_NULL
>>
>> Could you try with the following diff on lang/rust ? It removes the
>> dependency on libtool. It build fine on -current tree.
>
> Will try it tonight after work.

It passes with your patch. I found that odd and tried it again without
the your patch and the build finished fine.

I guess it was just a reliability issue with my laptop.

So in the end I was able to build every package with

USE_LIBTOOL =   gnu

Cheers,
Rafael



Re: Update libtool

2021-02-19 Thread Rafael Ávila de Espíndola
Sebastien Marie  writes:

> On Wed, Feb 17, 2021 at 01:55:45PM -0800, Rafael Ávila de Espíndola wrote:
>> Stuart Henderson  writes:
>> >
>> > And there are ports with USE_LIBTOOL=gnu:
>> 
>> Cool. I have been able to build most of them, and the errors I got don't
>> look libtool related:
>> 
>> lang/mono:
>> Fatal: /usr/ports/pobj must be on a wxallowed filesystem (in lang/mono)
>>
>> x11/mate/pluma:
>> Fatal: /usr/ports/pobj must be on a wxallowed filesystem (in x11/mate/pluma)
>
> These are configuration problem on builder side :)
>
> The partition were /usr/ports/pobj lives needs to be mounted with
> wxallowed (at least during the build. you could remove the mount
> options after if you don't regulary need it).
>
> See mount(8) man page for what is "wxallowed".

Done. Both mono and pluma finished building overnight.

>> lang/rust:
>> LLVM ERROR: invalid sh_type for string table section [index 34]: expected 
>> SHT_STRTAB, but got SHT_NULL
>
> Could you try with the following diff on lang/rust ? It removes the
> dependency on libtool. It build fine on -current tree.

Will try it tonight after work.

Thanks,
Rafael

> ---
> commit 11215898cc759216b6b57348134a8659e5544e32 (master, apollo/master)
> from: Sébastien Marie 
> date: Wed Feb 17 05:31:19 2021 UTC
>  
>  remove libtool, as libbacktrace was gone
>  
> diff e9c8bbdecc75c1f145efa05a99c3022863e01962 
> b0ac097d7243f0ed373100d9534d3d4a2bceab6b
> blob - 9fa9d60bc79d1376c06dbc7495afb51354599654
> blob + c82abb7488e7aa381b4d722e03cfde2894ee7039
> --- Makefile
> +++ Makefile
> @@ -173,9 +173,6 @@ PATCHORIG =   .openbsd.orig
>  SEPARATE_BUILD = Yes
>  USE_GMAKE =  Yes
>  
> -# need for libbacktrace
> -USE_LIBTOOL =gnu
> -
>  TEST_DEPENDS +=  devel/git \
>   sysutils/ggrep
>  
>
> Thanks.
> -- 
> Sebastien Marie



Re: Update libtool

2021-02-17 Thread Rafael Ávila de Espíndola
Stuart Henderson  writes:

> On 2021/02/16 10:09, Marc Espie wrote:
>> On Mon, Feb 15, 2021 at 01:45:40PM -0800, Rafael Ávila de Espíndola wrote:
>> > The last release of libtool is 2.4.6, which is from 2015. We currently
>> > have 2.4.2. I don't expect projects to actually require 2.4.6, but given
>> > how old 2.4.6 is, some check for that version.
>> > 
>> > Given that libtool is not being developed, the one time pain of updating
>> > to 2.4.6 might be worth it.
>> > 
>> > This is the first time I try to change anything in ports. What would be
>> > the best way to test this?
>> > 
>> > Cheers,
>> > Rafael
>> 
>> For some base stuff like this, the best way to test this is to rebuild
>> most of everything... so someone who does full builds regularly should test
>> it.
>> 
>> As for runtime, there are not that many ports depending on ltdl
>> 
>> GraphicsMagick seems like it would be the least painful to check.
>> 
>
> And there are ports with USE_LIBTOOL=gnu:

Cool. I have been able to build most of them, and the errors I got don't
look libtool related:

lang/mono:
Fatal: /usr/ports/pobj must be on a wxallowed filesystem (in lang/mono)

lang/rust:
LLVM ERROR: invalid sh_type for string table section [index 34]: expected 
SHT_STRTAB, but got SHT_NULL

x11/mate/pluma:
Fatal: /usr/ports/pobj must be on a wxallowed filesystem (in x11/mate/pluma)

Cheers,
Rafael



Re: Update libtool

2021-02-16 Thread Rafael Ávila de Espíndola
Marc Espie  writes:

> On Mon, Feb 15, 2021 at 01:45:40PM -0800, Rafael Ávila de Espíndola wrote:
>> The last release of libtool is 2.4.6, which is from 2015. We currently
>> have 2.4.2. I don't expect projects to actually require 2.4.6, but given
>> how old 2.4.6 is, some check for that version.
>> 
>> Given that libtool is not being developed, the one time pain of updating
>> to 2.4.6 might be worth it.
>> 
>> This is the first time I try to change anything in ports. What would be
>> the best way to test this?
>> 
>> Cheers,
>> Rafael
>
> For some base stuff like this, the best way to test this is to rebuild
> most of everything... so someone who does full builds regularly should test
> it.
>
> As for runtime, there are not that many ports depending on ltdl
>
> GraphicsMagick seems like it would be the least painful to check.

I was able to build GraphicsMagick with the new libtool and ltdl and at
least "gm display foo.jpg" works. I only have OpenBSD on a laptop, so
"most of everything" might take too long :-)

Cheers,
Rafael



Update libtool

2021-02-15 Thread Rafael Ávila de Espíndola
The last release of libtool is 2.4.6, which is from 2015. We currently
have 2.4.2. I don't expect projects to actually require 2.4.6, but given
how old 2.4.6 is, some check for that version.

Given that libtool is not being developed, the one time pain of updating
to 2.4.6 might be worth it.

This is the first time I try to change anything in ports. What would be
the best way to test this?

Cheers,
Rafael

commit aa84897eb8840f32739b1d61fa5ae230ec8f232e
Author: Rafael Ávila de Espíndola 
Date:   Tue Sep 22 22:27:59 2020 -0700

Update libtool

Building sane-backends from git requires libtool 2.4.6. Given that
libtool 2.4.6 was released in 2015, it seems better to update it in
ports than try change sane-backends.

Warning: There was quite a bit of cargo cult involved in this. For
example, I have blindly update the patches and don't know if they are
still relevant in 2.4.6.

diff --git devel/libtool/Makefile devel/libtool/Makefile
index 0ac0f7a7c0e..5df984bde20 100644
--- devel/libtool/Makefile
+++ devel/libtool/Makefile
@@ -3,7 +3,7 @@
 COMMENT-main=	generic shared library support script
 COMMENT-ltdl=	GNU libtool system independent dlopen wrapper
 
-VERSION=	2.4.2
+VERSION=	2.4.6
 DISTNAME=	libtool-${VERSION}
 PKGNAME-main=	${DISTNAME}
 PKGNAME-ltdl=	libltdl-${VERSION}
@@ -22,7 +22,8 @@ MAINTAINER=	Brad Smith 
 PERMIT_PACKAGE=	Yes
 
 AUTOCONF_VERSION= 2.67
-BUILD_DEPENDS=	${MODGNU_AUTOCONF_DEPENDS}
+AUTOMAKE_VERSION= 1.15
+BUILD_DEPENDS=	${MODGNU_AUTOCONF_DEPENDS} ${MODGNU_AUTOMAKE_DEPENDS} devel/m4
 
 MAKE_ENV+= ${_lt_libs}
 MAKE_FLAGS+= ${_lt_libs}
diff --git devel/libtool/distinfo devel/libtool/distinfo
index 3c3ff5143ee..051bc346304 100644
--- devel/libtool/distinfo
+++ devel/libtool/distinfo
@@ -1,2 +1,2 @@
-SHA256 (libtool-2.4.2.tar.gz) = s43kSGKphyk809jfrhxAnVFLbE55TryTZI/r+a/DiRg=
-SIZE (libtool-2.4.2.tar.gz) = 2632347
+SHA256 (libtool-2.4.6.tar.gz) = 471NXT0CWjbCHdavfqgYoq/NTfwepaF7OdeFS80MBuM=
+SIZE (libtool-2.4.6.tar.gz) = 1806697
diff --git devel/libtool/patches/patch-libltdl_config_ltmain_sh devel/libtool/patches/patch-build-aux_ltmain_sh
similarity index 77%
rename from devel/libtool/patches/patch-libltdl_config_ltmain_sh
rename to devel/libtool/patches/patch-build-aux_ltmain_sh
index 848d5a0278e..684c09fe360 100644
--- devel/libtool/patches/patch-libltdl_config_ltmain_sh
+++ devel/libtool/patches/patch-build-aux_ltmain_sh
@@ -1,9 +1,11 @@
-$OpenBSD: patch-libltdl_config_ltmain_sh,v 1.2 2011/11/01 16:07:31 jasper Exp $
 libltdl/config/ltmain.sh.orig	Mon Oct 17 06:19:35 2011
-+++ libltdl/config/ltmain.sh	Sat Oct 29 07:05:47 2011
-@@ -2714,51 +2714,6 @@ func_mode_finish ()
+$OpenBSD$
+
+Index: build-aux/ltmain.sh
+--- build-aux/ltmain.sh.orig
 build-aux/ltmain.sh
+@@ -4033,51 +4033,6 @@ func_mode_finish ()
  # Exit here if they wanted silent mode.
- $opt_silent && exit $EXIT_SUCCESS
+ $opt_quiet && exit $EXIT_SUCCESS
  
 -if test -n "$finish_cmds$finish_eval" && test -n "$libdirs"; then
 -  echo "--"
@@ -14,27 +16,27 @@ $OpenBSD: patch-libltdl_config_ltmain_sh,v 1.2 2011/11/01 16:07:31 jasper Exp $
 -  echo
 -  echo "If you ever happen to want to link against installed libraries"
 -  echo "in a given directory, LIBDIR, you must either use libtool, and"
--  echo "specify the full pathname of the library, or use the \`-LLIBDIR'"
+-  echo "specify the full pathname of the library, or use the '-LLIBDIR'"
 -  echo "flag during linking and do at least one of the following:"
 -  if test -n "$shlibpath_var"; then
--	echo "   - add LIBDIR to the \`$shlibpath_var' environment variable"
+-	echo "   - add LIBDIR to the '$shlibpath_var' environment variable"
 -	echo " during execution"
 -  fi
 -  if test -n "$runpath_var"; then
--	echo "   - add LIBDIR to the \`$runpath_var' environment variable"
+-	echo "   - add LIBDIR to the '$runpath_var' environment variable"
 -	echo " during linking"
 -  fi
 -  if test -n "$hardcode_libdir_flag_spec"; then
 -	libdir=LIBDIR
 -	eval flag=\"$hardcode_libdir_flag_spec\"
 -
--	$ECHO "   - use the \`$flag' linker flag"
+-	$ECHO "   - use the '$flag' linker flag"
 -  fi
 -  if test -n "$admincmds"; then
 -	$ECHO "   - have your system administrator run these commands:$admincmds"
 -  fi
 -  if test -f /etc/ld.so.conf; then
--	echo "   - have your system administrator add LIBDIR to \`/etc/ld.so.conf'"
+-	echo "   - have your system administrator add LIBDIR to '/etc/ld.so.conf'"
 -  fi
 -  echo
 -
@@ -53,7 +55,7 @@ $OpenBSD: patch-libltdl_config_ltmain_sh,v 1.2 2011/11/01 16:07:31 jasper Exp $
  exit $EXIT_

brlaser stopped working with a DCP-L2540DW

2020-11-14 Thread Rafael Ávila de Espíndola
I am not sure what changed in the current packages, but brlaser stopped
working for me.

Cups thinks it was able to print, and the printer LCD still says it is
receiving data, but nothing is actually printed.

I have tried setting LogLevel to debug in cupsd.conf, but found nothing
interesting in the logs.

The first two filters were pdftopdf and gstoraster. I tried running both
manually and got readable pdf and raster files (according to
https://github.com/michaelrsweet/rasterview.git).

Not sure how to debug the output of rastertobrlaser.

I was able to get the printer working by changing the driver to "Generic
PCL 6/PCL XL Printer Foomatic/pxlmono".

The printer description is at:

https://support.brother.com/g/b/spec.aspx?c=us=en=dcpl2540dw_us_as

Cheers,
Rafael



Re: UPDATE mail/notmuch-0.31.2

2020-11-09 Thread Rafael Ávila de Espíndola
Nice to see that these local patches are not needed anymore!

I was able to build and install the package, but during the build I got
this odd error:


touch docstring.stamp
sphinx-build-3 -b man -d doc/_build/man_doctrees -q ./doc doc/_build/man
/usr/ports/pobj/notmuch-0.31.2/notmuch-0.31.2/doc/python-bindings.rst:4: 
WARNING: autodoc: failed to import module 'notmuch2'; the following exception 
was raised:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/sphinx/ext/autodoc.py", line 
519, in import_object
__import__(self.modname)
ModuleNotFoundError: No module named 'notmuch2'


I got the same two test failures.

I am replying from notmuch-0.31.2 and so far everything seems to work.

Thanks for the update.

Cheers,
Rafael

Bjorn Ketelaars  writes:

> Diff below updates notmuch to 0.31.2. Changes:
> https://git.notmuchmail.org/git?p=notmuch;a=blob;f=NEWS;h=677c507dc6d90a84d5c7392dbd5b8537224a8dd7;hb=02a7b026d938f53d9fd9b183ca2b3c44c92489f2
>
> Changes to the port:
> - Drop several patches as the underlying issues has been addressed
>   upstream
> - Sync WANTLIB-main
>
> 'make test' fails two test (Yen-test), which were already failing.
>
> OK?
>
>
> Index: Makefile.inc
> ===
> RCS file: /cvs/ports/mail/notmuch/Makefile.inc,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile.inc
> --- Makefile.inc  1 Nov 2020 09:48:48 -   1.3
> +++ Makefile.inc  8 Nov 2020 19:00:12 -
> @@ -1,6 +1,6 @@
>  # $OpenBSD: Makefile.inc,v 1.3 2020/11/01 09:48:48 bket Exp $
>  
> -V =  0.31
> +V =  0.31.2
>  DISTNAME =   notmuch-$V
>  EXTRACT_SUFX =   .tar.xz
>  
> Index: notmuch/Makefile
> ===
> RCS file: /cvs/ports/mail/notmuch/notmuch/Makefile,v
> retrieving revision 1.6
> diff -u -p -r1.6 Makefile
> --- notmuch/Makefile  1 Nov 2020 09:48:48 -   1.6
> +++ notmuch/Makefile  8 Nov 2020 19:00:12 -
> @@ -13,8 +13,8 @@ DEBUG_PACKAGES =-main
>  
>  COMPILER=base-clang ports-gcc
>  
> -WANTLIB-main +=  ${COMPILER_LIBCXX} c glib-2.0 gmime-3.0
> -WANTLIB-main +=  gobject-2.0 intl m pthread talloc xapian z
> +WANTLIB-main +=  ${COMPILER_LIBCXX} c glib-2.0 gmime-3.0 
> gobject-2.0
> +WANTLIB-main +=  talloc xapian z
>  
>  LIB_DEPENDS =databases/xapian-core \
>   devel/libtalloc \
> @@ -67,10 +67,8 @@ post-extract:
>   cd ${WRKSRC}/test; [ -r test-lib-OPENBSD.sh ] || \
>   cp test-lib-FREEBSD.sh test-lib-OPENBSD.sh
>  
> -# Avoid conflict with C++20 , also see patches
>  pre-configure:
> - cd ${WRKSRC}; mv version version.txt; \
> - ${SUBST_CMD} lib/Makefile.local
> + cd ${WRKSRC}; ${SUBST_CMD} lib/Makefile.local
>   ln -s ${PREFIX}/bin/sphinx-build${MODPY_BIN_SUFFIX} 
> ${WRKDIR}/bin/sphinx-build
>  
>  post-install:
> Index: notmuch/distinfo
> ===
> RCS file: /cvs/ports/mail/notmuch/notmuch/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- notmuch/distinfo  1 Nov 2020 09:48:48 -   1.3
> +++ notmuch/distinfo  8 Nov 2020 19:00:12 -
> @@ -1,2 +1,2 @@
> -SHA256 (notmuch-0.31.tar.xz) = Vx+g4VOchmErHyssgKOY4I7P71LifvfkjPjjuE+hg5Q=
> -SIZE (notmuch-0.31.tar.xz) = 713144
> +SHA256 (notmuch-0.31.2.tar.xz) = FFa2PgRjcJTu/n5vmkWBLtQZOSoDIv6LD0Ut0GpM++8=
> +SIZE (notmuch-0.31.2.tar.xz) = 713388
> Index: notmuch/patches/patch-Makefile_global
> ===
> RCS file: notmuch/patches/patch-Makefile_global
> diff -N notmuch/patches/patch-Makefile_global
> --- notmuch/patches/patch-Makefile_global 1 Nov 2020 09:48:48 -   
> 1.2
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,14 +0,0 @@
> -$OpenBSD: patch-Makefile_global,v 1.2 2020/11/01 09:48:48 bket Exp $
> -
> -Index: Makefile.global
>  Makefile.global.orig
> -+++ Makefile.global
> -@@ -17,7 +17,7 @@ else
> - DATE:=$(shell date +%F)
> - endif
> - 
> --VERSION:=$(shell cat ${srcdir}/version)
> -+VERSION:=$(shell cat ${srcdir}/version.txt)
> - ELPA_VERSION:=$(subst ~,_,$(VERSION))
> - ifeq ($(filter release release-message pre-release 
> update-versions,$(MAKECMDGOALS)),)
> - ifeq ($(IS_GIT),yes)
> Index: notmuch/patches/patch-Makefile_local
> ===
> RCS file: notmuch/patches/patch-Makefile_local
> diff -N notmuch/patches/patch-Makefile_local
> --- notmuch/patches/patch-Makefile_local  15 May 2020 08:58:14 -  
> 1.1.1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,14 +0,0 @@
> -$OpenBSD: patch-Makefile_local,v 1.1.1.1 2020/05/15 08:58:14 sthen Exp $
> -
> -Index: Makefile.local
>  Makefile.local.orig
> -+++ 

Re: UPDATE mail/notmuch-0.31

2020-10-26 Thread Rafael Ávila de Espíndola


Bjorn Ketelaars  writes:

> Diff below brings notmuch to 0.31. From NEWS [0]:
> - notmuch now supports Emacs 27.1
> - add support for moving between threads after
>   notmuch-tree-from-search-thread
>
> The test suite completes with 4 failing tests, test.log attached:
>
> 1210/1219 tests passed.
> 3 broken tests failed as expected.
> 4 tests failed.
> 2 tests skipped.
> All tests in 1 file skipped.

I have applied the patch locally and I am at least able to find and
reply to this email with the new notmuch :-)

I got the same test summary.

I thought of doing a git bisect on the upstream repo to pinpoint the test
freeze, but that is hard because of the local patches.

Thanks,
Rafael