Re: [NEW] Notmuch 0.29.1

2019-11-23 Thread Enric Caussa Morales
Here's an updated version of the port:

- it's now using the SUBDIR functionality again. The WIP name is "core"
since it's less ugly than having "notmuch/notmuch" in the path. Let me
know if you come up with a more appropriate name.

- I've incorporated your changes such as the LIBnotmuch... vars and
such.

- Before reading your mail, i was linking the gnu coreutils into the
port's bin dir so that the tests worked. I guess actually having and
OpenBSD lib like what you suggested is better so that it may be
upstreamed.

- The library (libnotmuch.so) is now versioned. However, I put the
library version in Makefile.inc so that it might be shared between the
python bindings and the main notmuch package. I was expecting that
including WANTLIB += notmuch in the py-notmuch Makefile would make it
possible to use LIBnotmuch_VERSION, but that is not the case (is there
another way?).

I've been using it for a day so far and nothing strange happened yet. After
sending this mail, I'll contact the devs about the use-after-free you
commented (it also happens on my machine, but only at the end of the
tests, I guess it's same as yours).

Thanks a lot for your feedback and your help on porting this.



notmuch-191123.tgz
Description: Binary data


[UPDATE] Awesome WM 4.2 -> 4.3

2019-10-10 Thread Enric Caussa Morales


Hi again ports@,

I have updated the Makefile for the Awesome WM port. For those who don't
know what it is, Awesome WM is a window manager that is configurable and
scriptable with the Lua language. It's very flexible and lightweight on
resources.

The 4.3 version comes with a huge number of changes (see [1]) and was
released last January. I contacted the maintainer but got no reply, so I
went ahead and made this update.

The update was pretty straightforward: version bump, applying the
patches and tweak them so they would apply cleanly. I took the liberty
of removing the code that prevented manpages from gzipping. They don't
get gzipped unless you tell them too. I also removed the hardcoded
CFLAGS that were patched in. IIRC, they should be already inherited by
whatever the system provides, right?

One thing though, to make the manpages, asciidoctor, a ruby package,
must be installed. It can be trivially created with portgen. Tomorrow
I'll post the generated Makefile.

Looking forward to feedback,

Enric

[1] https://github.com/awesomeWM/awesome/releases/tag/v4.3


Index: Makefile
===
RCS file: /cvs/ports/x11/awesome/Makefile,v
retrieving revision 1.110
diff -u -r1.110 Makefile
--- Makefile12 Jul 2019 20:51:08 -  1.110
+++ Makefile11 Oct 2019 00:12:42 -
@@ -2,7 +2,7 @@
 
 COMMENT=   highly configurable framework window manager
 
-VER=   4.2
+VER=   4.3
 DISTNAME=  awesome-${VER}
 REVISION=  1
 EXTRACT_SUFX=  .tar.xz
@@ -11,7 +11,7 @@
 HOMEPAGE=  https://awesomewm.org/
 
 # GPLv2+
-PERMIT_PACKAGE=Yes
+PERMIT_PACKAGE=Yes
 
 WANTLIB=   X11 c cairo dbus-1 execinfo \
gdk_pixbuf-2.0 glib-2.0 gobject-2.0 \
Index: distinfo
===
RCS file: /cvs/ports/x11/awesome/distinfo,v
retrieving revision 1.28
diff -u -r1.28 distinfo
--- distinfo5 Aug 2017 20:18:11 -   1.28
+++ distinfo11 Oct 2019 00:12:42 -
@@ -1,2 +1,2 @@
-SHA256 (awesome-4.2.tar.xz) = rF2hqZ9frQg4IZk9K1bRzZWUFk6vwL4r61QFmDRdl08=
-SIZE (awesome-4.2.tar.xz) = 987024
+SHA256 (awesome-4.3.tar.xz) = eCZNbwEjULNx4zkSespIUmC8Cqk17/V4unXOGgDhF1M=
+SIZE (awesome-4.3.tar.xz) = 1037816
Index: patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/x11/awesome/patches/patch-CMakeLists_txt,v
retrieving revision 1.19
diff -u -r1.19 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt5 Aug 2017 20:18:11 -   1.19
+++ patches/patch-CMakeLists_txt11 Oct 2019 00:12:42 -
@@ -1,15 +1,9 @@
-$OpenBSD: patch-CMakeLists_txt,v 1.19 2017/08/05 20:18:11 dcoppa Exp $
-
-These auto-generated (db2man.xsl) manpages contain a mixture of ISO
-latin-1 characters and numerical HTML entities that neither mandoc
-nor groff can fully understand: do not install them.
-
-Fix usage of -export-dynamic
+$OpenBSD$
 
 Index: CMakeLists.txt
 --- CMakeLists.txt.orig
 +++ CMakeLists.txt
-@@ -97,7 +97,6 @@ set(AWE_MAN_SRCS
+@@ -95,7 +95,6 @@ set(AWE_MAN_SRCS
  ${SOURCE_DIR}/manpages/awesome.1.txt
  ${SOURCE_DIR}/manpages/awesome-client.1.txt
  ${SOURCE_DIR}/manpages/awesomerc.5.txt)
@@ -17,192 +11,20 @@
  
  # Don't strip RPATH if compiling on Solaris
  if (${CMAKE_SYSTEM_NAME} MATCHES "SunOS")
-@@ -111,12 +110,11 @@ add_executable(${PROJECT_AWE_NAME}
- 
- # CFLAGS
- set(AWESOME_C_FLAGS
---O1 -std=gnu99 -ggdb3 -fno-strict-aliasing -Wall -Wextra
---Wchar-subscripts -Wundef -Wshadow -Wcast-align -Wwrite-strings
---Wsign-compare -Wunused -Wno-unused-parameter -Wuninitialized -Winit-self
---Wpointer-arith -Wformat-nonliteral
---Wno-format-zero-length -Wmissing-format-attribute -Wmissing-prototypes
---Wstrict-prototypes
-+-std=gnu99 -fgnu89-inline -fno-strict-aliasing
-+-Wchar-subscripts -Wcast-align -Wwrite-strings -Wsign-compare
-+-Wunused -Wno-unused-parameter -Wuninitialized -Wpointer-arith
-+-Wno-format-zero-length -Wmissing-format-attribute
-+-Wmissing-prototypes -Wstrict-prototypes
- CACHE STRING "CFLAGS used to compile ${PROJECT_AWE_NAME}")
- mark_as_advanced(AWESOME_C_FLAGS)
- target_compile_options(${PROJECT_AWE_NAME} PRIVATE ${AWESOME_C_FLAGS})
-@@ -124,23 +122,11 @@ target_compile_options(${PROJECT_AWE_NAME} PRIVATE ${A
- # Make sure awesomerc.lua is generated
- add_dependencies(${PROJECT_AWE_NAME} generate_awesomerc)
+@@ -134,11 +133,11 @@ if(DEFINED CMAKE_SHARED_LIBRARY_LINK_C_FLAGS AND
+ $<$,$>:-rdynamic>)
+ endif()
  
--# Linux w/ GCC requires -rdynamic to get backtrace to fully work.
--#
--# For "historical reasons", CMake adds the option to the linker flags
--# unnoticeably for Linux w/ GCC through its modules Linux-GNU.cmake
--# and Linux-GNU-C.cmake.  Our build system has counted on that.  But
--# just in case CMake should do 

Re: [NEW] Notmuch 0.28.3

2019-03-30 Thread Enric Caussa Morales
Thanks again for your help. I'll go for the second option since, from the top 
of my head, afew uses the 3.6 bindings and alot uses the 2.7 ones. I'll do it 
after dinner. 

Cheers

On 30 March 2019 20:04:22 GMT+01:00, Stuart Henderson  
wrote:
>On 2019/03/30 19:58, Enric Morales wrote:
>> On 2019-03-30 14:21, Stuart Henderson wrote:
>> > Tweaked tar attached;
>> > Still needs doing: SHARED_LIBS needs fixing to be under ports
>control
>> > (see comments next to SHARED_LIBS). We need to be able to bump
>these
>> > from the port if necessary.
>> > 
>> > Maybe also: drop the quite intrusive man gz patches and just run
>> > gunzip in post-install, it's a bit less efficient at build time,
>but
>> > avoids some pain for updates.
>> 
>> Hi Stuart,
>> 
>> Thank you very much for your feedback and tweaks to the port files!
>Attached
>> you'll find the progress:
>> 
>> * I have dropped the patch to the manpages and ungzip them in
>post-install,
>> it's cleaner as you've said.
>> * The SHARED_LIBS is also now version-controlled.
>> * I also am now not harcoding the versions. However I'm struggling
>with the
>> python bindings. The problem is that when generating the packages,
>both the
>> py and the py3 ones will have the py files. If I set the
>MODPY_VERSION to 3,
>> then it will be the opposite: both the py3 and the py package will
>have the
>> py3 files. I am out of ideas to avoid hardcoding the versions in the
>PLISTs.
>> 
>> I can't find any other package that builds both python bindings at
>the same
>> time. Could you please show me the way it should be done?
>
>Ah I didn't check the file contents ... OK - we don't really have a
>"how it should be done" as it's not a great fit for the Python setup in
>ports.  The two options that come to mind:
>
>- just pick one version (preferably py3) and forget about the other
>
>- have separate ports for notmuch and py-notmuch, using the normal
>FLAVOR mechanism to handle py/py3 for the latter

-- 
Sent from my phone.  Please excuse my brevity.