Re: Disable awesome-wm docs
lts_progressbar.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_defaults_separator.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_defaults_slider.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_defaults_textbox.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_graph_step.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_piechart_border_color.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_piechart_border_width.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_piechart_label.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_progressbar_bar_shape.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_progressbar_clip.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_progressbar_encapsulation.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_progressbar_shape.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_progressbar_text.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_progressbar_vertical.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_separator_border_color.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_separator_orientation.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_separator_shape.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_bar_border.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_bar_color.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_bar_height.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_bar_margins.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_bar_shape.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_handle_border.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_handle_color.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_handle_margins.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_handle_shape.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_handle_width.svg
-share/doc/awesome/doc/images/AUTOGEN_wibox_widget_slider_value.svg
-share/doc/awesome/doc/images/awful_widget_watch.png
-share/doc/awesome/doc/images/client_geo.svg
-share/doc/awesome/doc/images/mouse.svg
-share/doc/awesome/doc/images/tag_props.svg
-share/doc/awesome/doc/images/widgetlayout1.png
-share/doc/awesome/doc/images/widgetlayout2.png
-share/doc/awesome/doc/index.html
-share/doc/awesome/doc/ldoc.css
-share/doc/awesome/doc/libraries/
-share/doc/awesome/doc/libraries/awesome.html
-share/doc/awesome/doc/libraries/awful.client.html
-share/doc/awesome/doc/libraries/awful.completion.html
-share/doc/awesome/doc/libraries/awful.ewmh.html
-share/doc/awesome/doc/libraries/awful.hotkeys_popup.html
-share/doc/awesome/doc/libraries/awful.hotkeys_popup.widget.html
-share/doc/awesome/doc/libraries/awful.key.html
-share/doc/awesome/doc/libraries/awful.layout.html
-share/doc/awesome/doc/libraries/awful.menu.html
-share/doc/awesome/doc/libraries/awful.mouse.html
-share/doc/awesome/doc/libraries/awful.placement.html
-share/doc/awesome/doc/libraries/awful.prompt.html
-share/doc/awesome/doc/libraries/awful.rules.html
-share/doc/awesome/doc/libraries/awful.screen.html
-share/doc/awesome/doc/libraries/awful.spawn.html
-share/doc/awesome/doc/libraries/awful.tag.html
-share/doc/awesome/doc/libraries/awful.util.html
-share/doc/awesome/doc/libraries/awful.wibox.html
-share/doc/awesome/doc/libraries/beautiful.gtk.html
-share/doc/awesome/doc/libraries/beautiful.html
-share/doc/awesome/doc/libraries/dbus.html
-share/doc/awesome/doc/libraries/gears.color.html
-share/doc/awesome/doc/libraries/gears.debug.html
-share/doc/awesome/doc/libraries/gears.filesystem.html
-share/doc/awesome/doc/libraries/gears.geometry.html
-share/doc/awesome/doc/libraries/gears.math.html
-share/doc/awesome/doc/libraries/gears.protected_call.html
-share/doc/awesome/doc/libraries/gears.shape.html
-share/doc/awesome/doc/libraries/gears.sort.html
-share/doc/awesome/doc/libraries/gears.string.html
-share/doc/awesome/doc/libraries/gears.surface.html
-share/doc/awesome/doc/libraries/gears.table.html
-share/doc/awesome/doc/libraries/gears.wallpaper.html
-share/doc/awesome/doc/libraries/menubar.html
-share/doc/awesome/doc/libraries/menubar.menu_gen.html
-share/doc/awesome/doc/libraries/menubar.utils.html
-share/doc/awesome/doc/libraries/mouse.html
-share/doc/awesome/doc/libraries/mousegrabber.html
-share/doc/awesome/doc/libraries/naughty.dbus.html
-share/doc/awesome/doc/libraries/naughty.html
-share/doc/awesome/doc/libraries/root.html
-share/doc/awesome/doc/libraries/selection.html
-share/doc/awesome/doc/libraries/wibox.hierarchy.html
-share/doc/awesome/doc/sample files/
-share/doc/awesome/doc/sample files/rc.lua.html
-share/doc/awesome/doc/sample files/theme.lua.html
share/examples/awesome/
share/examples/awesome/rc.lua
@sample ${SYSCONFDIR}/xdg/
Thanks for updating this port, Rafael!
Cheers,
Enric Morales
Re: update mail/notmuch to 0.30
Hi Olivier, On 2020-08-09 12:01, Olivier Taïbi wrote: ping, I also added bash as a build dependency (for bash-completion) It's great that notmuch is in ports now! I am trying it out and it sure works a lot smoother than it used to when built with the -wip port. Thanks for the effort you put in it! - Enric
Re: [UPDATE] Awesome WM 4.2 -> 4.3
Hi @ports,
I rebuilt my machine and lost my updated port and instead of recovering
it from here, I went ahead and made a new one from scratch. I noticed
that I missed a couple files (awesome themes) that needed to be patched
to fix lookup paths. Here are some of the changes of this diff:
- it removes a patch related to manpages (they are not compressed by
default anymore, and the build works fine without that CFLAG). Instead
of doing the work of removing the translated documentation from the
CMakefiles, they are now removed with the port Makefile, since it will
ease maintenance.
- it builds with Lua 5.3 now
- the API documentation is now built and installed so it can be used
offline
- I also noticed that the pango library had to be explicitly listed in
the Makefile, it's (now?) a direct dependency of Awesome WM and it just
refuses to build without it:
[50/288] : && /usr/ports/pobj/awesome-4.3/bin/cc -O2 -pipe -DNDEBUG
CMakeFiles/test-gravity.dir/tests/test-gravity.c.o -o test-gravity
-L/usr/local/lib -L/usr/lib -L/usr/X11R6/lib -lxcb -L/usr/X11R6/lib
-lxcb -L/usr/local/lib -L/usr/X11R6/lib
-Wl,-rpath-link,/usr/X11R6/lib -lgdk_pixbuf-2.0 -lgobject-2.0
-lglib-2.0 -lintl -lX11 -lxcb-cursor -lxcb-randr -lxcb-xtest
-lxcb-xinerama -lxcb-shape -lxcb-util -lxcb-keysyms -lxcb-icccm
-lxcb-xkb -lxkbcommon-x11 -lxkbcommon -lcairo -lxcb-render
-lstartup-notification-1 -lxdg-basedir -lxcb-xrm -lxcb -lexecinfo
-lm -llua5.3 -lm -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl
-lX11 -lxcb-cursor -lxcb-randr -lxcb-xtest -lxcb-xinerama
-lxcb-shape -lxcb-util -lxcb-keysyms -lxcb-icccm -lxcb-xkb
-lxkbcommon-x11 -lxkbcommon -lcairo -lxcb-render
-lstartup-notification-1 -lxdg-basedir -lxcb-xrm -lexecinfo -lm
-llua5.3 -lm -Wl,-rpath-link,/usr/X11R6/lib:/usr/local/lib && :
[51/288] cd /usr/ports/pobj/awesome-4.3/build-amd64 &&
/usr/ports/pobj/awesome-4.3/build-amd64/lgi-check
FAILED: CMakeFiles/lgi-check-run
cd /usr/ports/pobj/awesome-4.3/build-amd64 &&
/usr/ports/pobj/awesome-4.3/build-amd64/lgi-check
Building for Lua 5.3.
Found lgi 0.9.1.
Error: /usr/local/share/lua/5.3/lgi/namespace.lua:151: Typelib file
for namespace 'Pango' (any version) not found
WARNING
===
The lgi check failed.
Awesome needs lgi to run.
Add AWESOME_IGNORE_LGI=1 to your environment to continue.
Could you please take a look at it?
Cheers,
EnricIndex: Makefile
===
RCS file: /cvs/ports/x11/awesome/Makefile,v
retrieving revision 1.110
diff -u -p -r1.110 Makefile
--- Makefile 12 Jul 2019 20:51:08 - 1.110
+++ Makefile 9 May 2020 15:03:33 -
@@ -2,9 +2,8 @@
COMMENT= highly configurable framework window manager
-VER= 4.2
+VER= 4.3
DISTNAME= awesome-${VER}
-REVISION= 1
EXTRACT_SUFX= .tar.xz
CATEGORIES= x11
@@ -15,7 +14,7 @@ PERMIT_PACKAGE= Yes
WANTLIB= X11 c cairo dbus-1 execinfo \
gdk_pixbuf-2.0 glib-2.0 gobject-2.0 \
- intl ${MODLUA_WANTLIB} m \
+ intl ${MODLUA_WANTLIB} m pango-1.0 \
startup-notification-1 xcb xcb-cursor \
xcb-icccm xcb-keysyms xcb-randr \
xcb-render xcb-shape xcb-util \
@@ -27,9 +26,10 @@ MASTER_SITES= https://github.com/awesom
MODULES= devel/cmake \
lang/lua
-MODLUA_VERSION= 5.2
+MODLUA_VERSION= 5.3
LIB_DEPENDS= devel/libexecinfo \
+ devel/pango \
devel/startup-notification \
graphics/cairo \
graphics/gdk-pixbuf2 \
@@ -41,38 +41,48 @@ LIB_DEPENDS= devel/libexecinfo \
MODLUA_BUILD_DEPENDS= devel/lua-lgi
BUILD_DEPENDS= devel/lualdoc \
- textproc/asciidoc>=8.4.5 \
- textproc/xmlto \
+ textproc/asciidoctor \
graphics/ImageMagick
MODLUA_RUN_DEPENDS= devel/lua-lgi
-RUN_DEPENDS= devel/pango \
- misc/rlwrap \
+RUN_DEPENDS= misc/rlwrap \
shells/bash
CONFIGURE_ARGS= -DCOMPRESS_MANPAGES=off \
- -DGENERATE_DOC=off \
-DSYSCONFDIR=${SYSCONFDIR}
NO_TEST= Yes
pre-configure:
${SUBST_CMD} ${WRKSRC}/awesomeConfig.cmake \
- ${WRKSRC}/docs/06-appearance.md.lua \
- ${WRKSRC}/lib/awful/completion.lua \
- ${WRKSRC}/lib/awful/util.lua \
- ${WRKSRC}/lib/beautiful/init.lua \
- ${WRKSRC}/lib/gears/filesystem.lua \
- ${WRKSRC}/lib/menubar/icon_theme.lua \
- ${WRKSRC}/lib/naughty/core.lua \
- ${WRKSRC}/themes/default/theme.lua \
- ${WRKSRC}/themes/xresources/theme.lua \
- ${WRKSRC}/utils/awesome-client
+ ${WRKSRC}/tests/examples/CMakeLists.txt \
+ ${WRKSRC}/lib/naughty/core.lua \
+ ${WRKSRC}/lib/menubar/utils.lua \
+ ${WRKSRC}/lib/menubar/icon_theme.lua \
+ ${WRKSRC}/lib/gears/filesystem.lua \
+ ${WRKSRC}/lib/beautiful/init.lua \
+ ${WRKSRC}/lib/awful/util.lua \
+ ${WRKSRC}/lib/awful/completion.lua \
+ ${WRKSRC}/docs/build_rules_index.lua \
+ ${WRKSRC}/docs/90-FAQ.md \
+ ${WRKSRC}/docs/07-my-first-awesome.md \
+ ${WRKSRC}/docs/06-appearance.md.lua \
+ ${WR
Re: wip: mail/notmuch
Hi Olivier, On 2020-04-10 20:21, Olivier Taïbi wrote: Here is further progress on this port, following versions by Enric Morales and Stuart Henderson. I hope that this does not duplicate your efforts. Thanks a lot for providing your effort. It's great that you are working on this too, since I haven't had the time lately nor the knowledge. How is it working on your end? Any unstability so far?
Re: openbsd-wip/mail/notmuch fails to compile
Hi Stuart, ports@, Carolyn, Sorry for the late reply. Thank you for working on this. The Notmuch devs fixed the use-after-free bug after you spotted it and also released 0.29.3 which I see you are already building in this new Makefile. I haven't had time to try it but will do tomorrow when I'll have the time. Enric Stuart Henderson writes: > On 2019/12/21 14:40, Carolyn Knight-Serrano wrote: >> Howdy! I'm trying to build mail/notmuch but it fails to build > > openbsd-wip is a place to work on ports (possibly collaboratively) > before submitting them when they're closer to being ready. Ports there > are often not expected to work properly. > > Enric Morales has sent a newer version to ports@, but there are still > some problems - some segfaults and hangs connected with the notmuch > code using zlib (which has been patched to work with OpenBSD's rather > old version of zlib - I don't trust these patches, in particular the > one relating to gzclose_w). There are some other problems which might > also be connected with zlib but might be something else. > > It builds and packages and some things work, but I don't think it's > ready for import until these problems are figured out. (I'm not > expecting a fully clear "make test" run, but the tests which currently > fail point at some problems that really want fixing first). > > Here's a version I've worked on a bit. Compared to the last one that > was sent to ports@, it's a newer version, simplifies some patching, > and gets more of the tests running correctly. >
Re: [UPDATE] Awesome WM 4.2 -> 4.3
Stuart Henderson writes:
> The @sample is now attached to the wrong file, it creates
> /etc/xdg/awesome/rc.lua from LICENSE.
It sure is! Thanks for having a look at it Stuart.
Here's the corrected diff.
? awesome.diff
Index: Makefile
===
RCS file: /cvs/ports/x11/awesome/Makefile,v
retrieving revision 1.110
diff -u -r1.110 Makefile
--- Makefile 12 Jul 2019 20:51:08 - 1.110
+++ Makefile 24 Nov 2019 00:02:04 -
@@ -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 \
@@ -55,7 +55,8 @@
-DGENERATE_DOC=off \
-DSYSCONFDIR=${SYSCONFDIR}
-NO_TEST= Yes
+NO_TEST= No
+TEST_TARGET= test
pre-configure:
${SUBST_CMD} ${WRKSRC}/awesomeConfig.cmake \
Index: distinfo
===
RCS file: /cvs/ports/x11/awesome/distinfo,v
retrieving revision 1.28
diff -u -r1.28 distinfo
--- distinfo 5 Aug 2017 20:18:11 - 1.28
+++ distinfo 24 Nov 2019 00:02:04 -
@@ -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_txt 5 Aug 2017 20:18:11 - 1.19
+++ patches/patch-CMakeLists_txt 24 Nov 2019 00:02:04 -
@@ -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 away with the convention suddenly...
--if(DEFINED CMAKE_SHARED_LIBRARY_LINK_C_FLAGS AND
--NOT CMAKE_SHARED_LIBRARY_LINK_C_FLAGS MATCHES "-rdynamic")
--target_link_libraries(${PROJECT_AWE_NAME}
--$<$,$>:-rdynamic>)
--endif()
--
-# FreeBSD requires dynamic linking
-if(${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
+-set_target_properties(${PROJECT_AWE_NAME}
+-PROPERTIES
+-LINK_FLAGS -export-dynamic)
+# FreeBSD and OpenBSD require dynamic linking
+if(CMAKE_SYSTEM_NAME MATCHES "FreeBSD" OR CMAKE_SYSTEM_NAME MATCHES "OpenBSD")
- set_target_properties(${PROJECT_AWE_NAME}
- PROPERTIES
--LINK_FLAGS -export-dynamic)
++ set_target_properties(${PROJECT_AWE_NAME}
++ PROPERTIES
+LINK_FLAGS -Wl,--export-dynamic)
endif()
target_link_libraries(${PROJECT_AWE_NAME}
-@@ -148,10 +13
Re: [UPDATE] Awesome WM 4.2 -> 4.3
I'd love it if someone had a look at this. Cheers.
Enric Caussa Morales writes:
> 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
> --- Makefile 12 Jul 2019 20:51:08 - 1.110
> +++ Makefile 11 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
> --- distinfo 5 Aug 2017 20:18:11 - 1.28
> +++ distinfo 11 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_txt 5 Aug 2017 20:18:11 - 1.19
> +++ patches/patch-CMakeLists_txt 11 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
Re: [NEW] Notmuch 0.29.1
Hi Stuart and ports! I am away from my workstation until late in the month. I will take a look at your feedback when I get back and further work on the port. Cheers
Re: [NEW] Notmuch 0.29.1
Forgot to attach the updated port port. Here it is. notmuch,5.tgz Description: GNU Zip compressed data
Re: [NEW] Notmuch 0.29.1
Stuart Henderson writes: > On 2019/10/17 03:57, Anthony J. Bentley wrote: >> I'm inclined to move the Python bits to a separate port, so you can >> use the Python module without running setup.py manually. > > That's definitely my preference. > > Enric did actually already do this but it seems to be lost from the current > tar... > > https://marc.info/?l=openbsd-ports&m=155449699431943&w=2 Hi Stuart, I think I'll end up doing two separate ports, but if you think that approach was a good idea, I'll do the subdir stuff instead. Cheers, Enric
Re: [NEW] Notmuch 0.29.1
Hi Stuart, Anthony and ports@ I guess I didn't run into any problem because I was building it in the same machine that i was running the program on. I created a VM to build packages and, indeed, I noticed some dependencies missing. Besides adding more build depends: - the libnotmuch.so library is now versioned. Sorry, I missed that last time :P - Test depends are taken care of - Tests are now running by default - HTTPS in the HOMEPAGE - Port still using lang/python since AFAIK it needs it for the documentation - The tests must be run with debugging symbols enabled, so I added that to the MAKE_FLAGS. They also need certain GNU coreutils functionality. Things that are weird: - portcheck suggests that the mail/gmime30 is not needed - generating the emacs binding fails unless emacs with gtk2 flavour is installed - The test #750 is the one that hangs halfway. If you switch to the tests directory and run the command that makes it hang you'll see why: NOTMUCH_CONFIG=/usr/ports/pobj/notmuch-0.29.1/notmuch-0.29.1/test/tmp.T750-gzip/notmuch-config ktrace -d ../notmuch show --format=raw id:msg-007@notmuch-test-suite Thank you so much for your help and comments, I love reading your feedback and learning so much. Enric
Re: [NEW] Notmuch 0.29.1
I checked what could be wrong with the tests failing, managing after some tweaks to get 90%+ of the test passing thanks to the GNU Coreutils and the GDB in ports. A couple of the tests that involve the zlib fail: Notmuch calls a zlib function and then i start seeing a repeated call to getentropy that heats up the system until I kill the program. I had to add the attached file to the tests/ dir so that the tests more or less worked. I still use notmuch daily (using the Emacs frontend right now) and it works fine for my usecase. Comments? test-lib-OPENBSD.sh Description: test-lib-OPENBSD.sh
[UPDATE] luaposix 33.4.0 -> 34.1.1
Hi ports@,
Here's the diff that updates luaposix from the 33.4.0 version,
from early 2006, to the latest version, 34.1.1, from July. The project,
a set of modules that makes it possible for Lua to use standard POSIX
system calls, has since added, fixed and improved the bindings.
The Makefile needed changes:
- The luke building system replaced autotools. The Makefile now uses it
for building.
- According to portcheck, ${FULLPKGNAME} is no longer allowed within
PLISTS so I've changed where the example scripts and the documentation
is changed (the folder name is, eg. named lua52-luaposix instead of
lua52posix-v34.1.1). I did account for different flavors installed at
once, which is taken care of with the MODLUA_DEP variable (it expands to
lua51, lua52 or lua53).
I portcheck'ed the build against the lua51, lua52 and lua53 flavors, and
then tested the three flavor's installations and they work fine when
running the example scripts.
Have a good weekend,
Enric
Index: Makefile
===
RCS file: /cvs/ports/devel/luaposix/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- Makefile12 Jul 2019 20:44:42 - 1.25
+++ Makefile11 Oct 2019 19:10:51 -
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.25 2019/07/12 20:44:42 sthen Exp $
COMMENT= posix library for the lua language
-V= 33.4.0
+V= 34.1.1
DISTNAME= luaposix-${V}
EPOCH= 0
REVISION= 1
@@ -14,9 +14,9 @@
# MIT
PERMIT_PACKAGE=Yes
-MODULES= lang/lua
+MODULES= lang/lua
-FLAVORS= lua52 lua53
+FLAVORS= lua52 lua53
FLAVOR?=
# lua51 needs the bit32 library
@@ -24,11 +24,20 @@
RUN_DEPENDS= devel/lua-bit32
.endif
-CONFIGURE_STYLE= gnu
-
-CONFIGURE_ENV+=LUA=${MODLUA_BIN}
+do-build:
+ @cd ${WRKDIR}/luaposix-release-v${V}/ && ${MODLUA_BIN} build-aux/luke \
+ LUA_INCDIR="${MODLUA_INCL_DIR}" version=${V} \
+ CFLAGS="${CFLAGS}" PREFIX=${PREFIX}
+
+do-install:
+ @cd ${WRKDIR}/luaposix-release-v${V}/ && ${MODLUA_BIN} build-aux/luke \
+ install PREFIX=${PREFIX}
post-install:
- mv ${PREFIX}/share/doc/luaposix ${MODLUA_DOCDIR}
+ mkdir ${PREFIX}/share/examples/${MODLUA_DEP}-luaposix
+ mv ${WRKDIR}/luaposix-release-v${V}/doc/examples/*.lua \
+ ${PREFIX}/share/examples/${MODLUA_DEP}-luaposix
+ mv ${WRKDIR}/luaposix-release-v${V}/doc \
+ ${PREFIX}/share/doc/${MODLUA_DEP}-luaposix
.include
Index: distinfo
===
RCS file: /cvs/ports/devel/luaposix/distinfo,v
retrieving revision 1.8
diff -u -r1.8 distinfo
--- distinfo31 Aug 2016 10:11:52 - 1.8
+++ distinfo11 Oct 2019 19:10:51 -
@@ -1,2 +1,2 @@
-SHA256 (luaposix-33.4.0.tar.gz) = 5mJi9bf+HDLGXxel71/7McTRh3AZtIcKXTc+KrZSaiE=
-SIZE (luaposix-33.4.0.tar.gz) = 643523
+SHA256 (luaposix-34.1.1.tar.gz) = Jz3y29lYGi8i5CZfFNDXWcSHwMmDD5Q5XX1pBHQ4KBA=
+SIZE (luaposix-34.1.1.tar.gz) = 177658
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/luaposix/pkg/PLIST,v
retrieving revision 1.5
diff -u -r1.5 PLIST
--- pkg/PLIST 17 Oct 2016 21:39:23 - 1.5
+++ pkg/PLIST 11 Oct 2019 19:10:51 -
@@ -1,59 +1,111 @@
-@comment $OpenBSD: PLIST,v 1.5 2016/10/17 21:39:23 jca Exp $
-lib/lua/${MODLUA_VERSION}/posix.a
-lib/lua/${MODLUA_VERSION}/posix.so
-share/doc/${FULLPKGNAME}/
-share/doc/${FULLPKGNAME}/examples/
-share/doc/${FULLPKGNAME}/examples/dir.lua.html
-share/doc/${FULLPKGNAME}/examples/fork.lua.html
-share/doc/${FULLPKGNAME}/examples/fork2.lua.html
-share/doc/${FULLPKGNAME}/examples/getopt.lua.html
-share/doc/${FULLPKGNAME}/examples/glob.lua.html
-share/doc/${FULLPKGNAME}/examples/limit.lua.html
-share/doc/${FULLPKGNAME}/examples/lock.lua.html
-share/doc/${FULLPKGNAME}/examples/netlink-uevent.lua.html
-share/doc/${FULLPKGNAME}/examples/ping.lua.html
-share/doc/${FULLPKGNAME}/examples/poll.lua.html
-share/doc/${FULLPKGNAME}/examples/signal.lua.html
-share/doc/${FULLPKGNAME}/examples/socket.lua.html
-share/doc/${FULLPKGNAME}/examples/termios.lua.html
-share/doc/${FULLPKGNAME}/examples/tree.lua.html
-share/doc/${FULLPKGNAME}/index.html
-share/doc/${FULLPKGNAME}/ldoc.css
-share/doc/${FULLPKGNAME}/modules/
-share/doc/${FULLPKGNAME}/modules/posix.ctype.html
-share/doc/${FULLPKGNAME}/modules/posix.dirent.html
-share/doc/${FULLPKGNAME}/modules/posix.errno.html
-share/doc/${FULLPKGNAME}/modules/posix.fcntl.html
-share/doc/${FULLPKGNAME}/modules/posix.fnmatch.html
-share/doc/${FULLPKGNAME}/modules/posix.getopt.html
-share/doc/${FULLPKGNAME}/modules/posix.glob.html
-share/doc/${FULLPKGNAME}/modules/posix.grp.html
-share/doc/${FULLPKGNAME}/modules/posix.html
-share/doc/${FULLPKGNAME}/modules/posix.libgen.html
-share/doc/${FULLPKGNAME}/modules/posix.poll.html
-share/doc/${FULLPKGNAME}/modules/p
[NEW] ruby-asciidoctor
Hi ports@ the attached port provides the files for building Asciidoctor. From their website[1], "Asciidoctor is a fast text processor and publishing toolchain for converting AsciiDoc content to HTML5, DocBook 5, EPUB3, PDF and other formats. Asciidoctor is the leading implementation of the AsciiDoc syntax, first introduced and implemented in the Python-based AsciiDoc project." This port was made with portgen. I only added a line to move /usr/local/bin/asciidoctor26 to /usr/local/bin/asciidoctor. This makes it possible for asciidoctor to be detected by, for example, the Awesome WM's build system. Let me know if this is not the correct approach. I guess the binary name could be left untouched and correct the Awesome WM's script to find asciidoctor. I tested this port when building Awesome WM and the manpages come out just fine. Let me know what you think, [1] https://asciidoctor.org/docs/what-is-asciidoctor/ Enric asciidoctor,1.tgz Description: the asciidoctor port
Re: [NEW] Notmuch 0.29.1
Hi ports@, the attached tarball updates the work-in-progress port to upstream notmuch 0.29.1. The notmuch project fixed some build-related issues, fixed bugs and improved the Emacs bindings, now distribute signed sha sums among other changes. See [1] for a detailed list of changes. I've dropped the mentions on Python 2.7 due to Python 2 being sunsetting. The port now builds the bindings for Python 3 and Emacs. I've been using the port for the last week on -CURRENT#366 (2019/10/9 snapshot) and it works fine (I am composing this mail using Emacs+Notmuch). Admittedly, the tests are broken, I might look into them though, as they could provide pointers on what to work on. Please let me know what I can do to improve this port. Cheers, Enric notmuch,4.tgz Description: Notmuch port milestone 4 [1]: https://notmuchmail.org/pipermail/notmuch/2019/028080.html
Re: [NEW] Notmuch 0.28.3
On 2019-03-30 20:04, Stuart Henderson wrote: 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 Hi again Stuart and ports@ I've looked at other ports and the SUBDIR mechanism looks perfect to keep things neat in this port, so I went ahead and created and modified the port so it now builds py3 and py versions as well as the emacs and main notmuch stuff. I've also used an .include so that I don't repeat the version in both the python Makefile and the main notmuch Makefile (one less thing to keep track of). Please let me know if that's a good idea. Thanks, Enric notmuch,3.tgz Description: GNU Zip compressed data
Re: [NEW] Notmuch 0.28.3
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? Thanks notmuch,3.tgz Description: GNU Zip compressed data
[NEW] Notmuch 0.28.3
Dear ports@, Attached you'll find the port for notmuch 0.28.3, a mail indexer similar to mu4e or sup. It also builds the bindings necessary for interfacing it with Emacs, Python 2.7 or 3.6 (only 3.6 tested with afewmail). With a few minor patches to fix some gz calls, to not compress the manpages and to call GNU Make instead of base Make, notmuch builds (build and portcheck log in the attachments) and runs perfectly in OpenBSD -CURRENT. I have been using it for the last 5 months. I am also volunteering for maintainership of this port, since I use notmuch daily and regularly follow the mailing lists. Please let me know if it lives up the ports standards, i want to learn to create good ports. Cheers, Enric notmuch.tar.gz Description: port files ===> Cleaning for notmuch-0.28.3 rm -f /usr/ports/packages/amd64/all/notmuch-0.28.3.tgz /usr/ports/packages/amd64/ftp/notmuch-0.28.3.tgz /usr/ports/packages/amd64/cdrom/notmuch-0.28.3.tgz /usr/ports/packages/amd64/all/notmuch-emacs-0.28.3.tgz /usr/ports/packages/amd64/ftp/notmuch-emacs-0.28.3.tgz /usr/ports/packages/amd64/cdrom/notmuch-emacs-0.28.3.tgz /usr/ports/packages/amd64/all/notmuch-python2.7-0.28.3.tgz /usr/ports/packages/amd64/ftp/notmuch-python2.7-0.28.3.tgz /usr/ports/packages/amd64/cdrom/notmuch-python2.7-0.28.3.tgz /usr/ports/packages/amd64/all/notmuch-python3.6-0.28.3.tgz /usr/ports/packages/amd64/ftp/notmuch-python3.6-0.28.3.tgz /usr/ports/packages/amd64/cdrom/notmuch-python3.6-0.28.3.tgz rm -f /usr/ports/update/amd64/notmuch-0.28.3 /usr/ports/update/amd64/notmuch-emacs-0.28.3 /usr/ports/update/amd64/notmuch-python2.7-0.28.3 /usr/ports/update/amd64/notmuch-python3.6-0.28.3 /usr/ports/packages/amd64/cache/notmuch-0.28.3.tgz /usr/ports/packages/amd64/cache/notmuch-emacs-0.28.3.tgz /usr/ports/packages/amd64/cache/notmuch-python2.7-0.28.3.tgz /usr/ports/packages/amd64/cache/notmuch-python3.6-0.28.3.tgz rm -f /usr/ports/plist/amd64/notmuch-0.28.3 rm -f /usr/ports/plist/amd64/notmuch-emacs-0.28.3 rm -f /usr/ports/plist/amd64/notmuch-python2.7-0.28.3 rm -f /usr/ports/plist/amd64/notmuch-python3.6-0.28.3 ===> notmuch-0.28.3 depends on: doxygen-* -> doxygen-1.8.14p0 ===> notmuch-0.28.3 depends on: xapian-core-* -> xapian-core-1.4.11p1 ===> notmuch-0.28.3 depends on: emacs-* -> emacs-26.1p4-gtk3 ===> notmuch-0.28.3 depends on: python->=3.6,<3.7 -> python-3.6.8p0 ===> notmuch-0.28.3 depends on: python->=2.7,<2.8 -> python-2.7.15p1 ===> notmuch-0.28.3 depends on: py-sphinx-* -> py-sphinx-1.4.8p0 ===> notmuch-0.28.3 depends on: gmake-* -> gmake-4.2.1p0 ===> notmuch-0.28.3 depends on: libtalloc-* -> libtalloc-2.1.14 ===> notmuch-0.28.3 depends on: gmime-* -> gmime-2.6.23p2 ===> Verifying specs: c c++ gio-2.0 glib-2.0 gmime-2.6 gobject-2.0 intl m pthread talloc z ===> found c.95.0 c++.2.1 gio-2.0.4200.8 glib-2.0.4201.1 gmime-2.6.0.2 gobject-2.0.4200.8 intl.6.0 m.10.1 pthread.26.1 talloc.1.1 z.5.0 ===> Checking files for notmuch-0.28.3 `/usr/ports/distfiles/notmuch-0.28.3.tar.gz' is up to date. >> (SHA256) notmuch-0.28.3.tar.gz: OK ===> Extracting for notmuch-0.28.3 ===> Patching for notmuch-0.28.3 ===> Applying OpenBSD patch patch-configure Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD$ |Index: configure |--- configure.orig |+++ configure -- Patching file configure using Plan A... Hunk #1 succeeded at 42. Hunk #2 succeeded at 534. Hunk #3 succeeded at 582. done ===> Applying OpenBSD patch patch-doc_Makefile_local Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD$ | |Index: doc/Makefile.local |--- doc/Makefile.local.orig |+++ doc/Makefile.local -- Patching file doc/Makefile.local using Plan A... Hunk #1 succeeded at 22. Hunk #2 succeeded at 34. Hunk #3 succeeded at 49. Hunk #4 succeeded at 75. Hunk #5 succeeded at 98. Hunk #6 succeeded at 131. done ===> Applying OpenBSD patch patch-emacs_Makefile_local Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD$ | |Index: emacs/Makefile.local |--- emacs/Makefile.local.orig |+++ emacs/Makefile.local -- Patching file emacs/Makefile.local using Plan A... Hunk #1 succeeded at 117. done ===> Applying OpenBSD patch patch-lib_Makefile_local Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD$ |Index: lib/Makefile.local |--- lib/Makefile.local.orig |+++ lib/Makefile.local -- Patching file lib/Makefile.local using Plan A... Hunk #1 succeeded at 15. Hunk #2 succeeded at 37. Hunk #3 succeeded at 78. done ===> Applying OpenBSD patch patch-notmuch-dump_c Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD$ | |Index: notmuch-dump.c |--- notmuch-dump.c.orig |+++ notmuch-dump.c
Re: [NEW] ibus-hangul v1.5.1
On 2018-10-11 23:02, Enric Morales wrote: [...] Attached you'll find the necessary build files. [...] I have been using this port as my main IME for the last weeks and it's been working fine, but I'd like to get some feedback on this port and know about the possibility of it being committed. Thanks in advance.
[NEW] ibus-hangul v1.5.1
Dear list, I've created a port for ibus-hangul, an input method for IBus that allows for composition of Korean and Hanja characters. I have been using it for the last hour and it works as expected. I see that there was a post on the list last year with an earlier version of the package, but I created this from scratch to learn to port and also receive valuable feedback. Attached you'll find the necessary build files. Cheers, Enric Morales ibus-hangul-v1.tar.gz Description: ibus-hangul 1.5.1 port build files
Re: firefox cursors are all different
On 09 Oct 2014 17:04, Stuart Henderson wrote: > On 2014/10/09 16:47, Stuart Henderson wrote: > > On 2014/10/08 22:23, Ted Unangst wrote: > > > However, now the "new" firefox has these great big honking stupid > > > cursors instead of the nice cursors it used to have. The arrow is > > > too > > > big, the I text cursor has an ugly outline, and the "hand" looks > > > more > > > like the poop emoji than a hand. How do I get the good cursors > > > back? > ...and it's still OK with the very latest packages. > Hi Ted and Stuart, I think the new cursors come from a GTK-related package. The issue with the "poop"-looking icon appears in gtk-demo and gimp. I started having this issue after a full update a couple days ago. The solution is really simple: # rm -rf /usr/local/share/icons/Adwaita/cursors/ Cheers, Enric Morales
Re: [NEW] x11/bspwm
Dear Brian, Stuart,
I have been out for some days, so sorry for the late reply. Thank
you for your comments, I hope I have improved the port.
On 20 Jun 2014 18:43, Brian Callahan wrote:
>
> On 06/20/14 18:31, Stuart Henderson wrote:
> >Quick comments from reading:
> >
> >examples should go in the standard directory layout i.e.
> >/usr/local/share/examples/bspwm (and get rid of MESSAGE)
Done.
> >
> >+CFLAGS += -std=c99 -pedantic -Wall -Wextra -I$(PREFIX)/include
> >-I/usr/X11R6/include
> >- don't hardcode usr/X11R6, use the X11BASE variable
Done.
> >
> >pkg/DESCR needs wrapping
Done.
> >
> >share/man/man1/ should be man/man1
OK!
> >
> >"2-Clause BSD License", just use "BSD"
Gotcha. Done.
> >
> >Makefile missing rcs id comment line
I think i got it right, as I'm not too sure on what to add here. Please
correct me if that's not right.
> >
> >post-install: use ${INSTALL_DATA_DIR} not mkdir
OK. I also did the do-install: target that Brian suggested.
> >
> >DISTFILES=0.8.8.tar.gz is bad, you can use something like
> >
> >V= 0.8.8
> >DISTNAME=bspwm-$V
> >DISTFILES= ${DISTNAME}{v$V}${EXTRACT_SUFX}
Good idea. Done.
> Few more comments:
> COMMENT should not start with "a"
Done.
>
> You don't need USE_GMAKE. Built just fine without it.
Yep, but had to remove an extra CFLAGS += '-Os', and an LDFLAGS += '-s'.
Should I keep the -Os? The extra LDFLAG is not necessary, as it's the
default for the ${INSTALL_PROGRAM} routine, isn't it?
>
> The install routine is a bunch of "mkdir -p" and "cp" - maybe it's better to
> use a do-install routine here.
Done.
>
> Your WANTLIB line is almost entirely bogus. I get this:
> WANTLIB += c m xcb xcb-ewmh xcb-icccm xcb-randr xcb-xinerama
> Run make port-lib-depends-check.
Strange, maybe I issued another depends-check. I got the same line as
yours now.
>
> You need NO_TEST=Yes
Added.
--
Enric Morales
bspwm.tar.gz
Description: application/tar-gz
Re: [NEW] x11/bspwm
Here is the attachment, I screwed up the file, so sorry for spamming the list. port-bspwm.tar.gz Description: Binary data
Re: [NEW] x11/bspwm (now with the attachment!)
The actual attachment. Dear list, I just created the x11/bspwm port. In the attachment you'll find the files necessary to build it. I have include a `post-install` rule that copies the example scripts so that the user who installs bspwm knows what to do next. Now I'll work on its companion program, sxhkd. Cheers, -- Enric Morales
[NEW] x11/bspwm
Dear list, I just created the x11/bspwm port. In the attachment you'll find the files necessary to build it. I have include a `post-install` rule that copies the example scripts so that the user who installs bspwm knows what to do next. The build was tested on 5.5 GENERIC.MP#215 amd64. Now I'll work on its companion program, sxhkd. Cheers, -- Enric Morales Dear list, I just created the x11/bspwm port. In the attachment you'll find the files necessary to build it. I have include a `post-install` rule that copies the example scripts so that the user who installs bspwm knows what to do next. Now I'll work on its companion program, sxhkd. Cheers, -- Enric Morales
Re: Anyone working on pandoc?
On 19 Jun 2014 15:23, Zé Loff wrote: > On Thu, Jun 19, 2014 at 10:22:17AM -0400, Ian Darwin wrote: > > On 2014-06-19, 9:42 AM, Zé Loff wrote: > > >Hi all > > > > > >Has anyone tried / started to port pandoc, or knows of any good reason > > >not to? I'd like to give it a shot, but I don't want do duplicate > > >efforts... > > > > > > > > Yes, I have it mostly done (a dozen or so new dependencies, of course), but > > it's on hold waiting for the annual churnover of Haskell GHC port. > > Nice, thanks. Let me know if I can help. > > Cheers > Zé > > -- > Hi Zé and Ian, I am also a pandoc user so I'll try the port when it's available. Meanwhile, the cabal version works fine. The only problem is that, every time pandoc has to be rebuilt, it might take at least one hour. Cheers!
