games/dmagnetic release 0.22 -> 0.23

[dettus]

Hello.


dMagnetic just saw release 0.23, and I took the liberty of creating a 
new patch

for the OpenBSD ports. I attached it to this email, pending your approval.


Thomas


--- Makefile.orig	2020-06-08 08:03:15.018947037 +0200
+++ Makefile	2020-06-08 08:03:15.022919169 +0200
@@ -1,6 +1,6 @@
 # $OpenBSD: Makefile,v 1.10 2020/02/13 22:08:10 sthen Exp $
 
-V =		0.22
+V =		0.23
 COMMENT =	interpreter for Magnetic Scrolls games
 DISTNAME =	dMagnetic_${V}
 PKGNAME =	dmagnetic-${V}
@@ -32,23 +32,31 @@
 	cd ${WRKSRC}/testcode;  if [ `echo Hello | ../dMagnetic -ini ../dMagnetic.ini \
 		-mag minitest.mag -gfx minitest.gfx \
 		-vmode none -vecho -vcols 300 -vrows 300 | \
-		sha256 -b` == DOx7jAlyo+E1/MsBxGDzsEd6xGj5p6yZWZ3TuEsptuI= -a \
+		sha256 -b` == cK9FNnpq0bYSzqvTb+8wnUJYq6wnUoGlVBNCzPCnZc0= -a \
 		`echo Hello | ../dMagnetic -ini ../dMagnetic.ini \
 		-mag minitest.mag -gfx minitest.gfx \
 		-vmode monochrome -vecho -vcols 300 -vrows 300 | \
-		sha256 -b` == JH9v0Uh6jMvWt2XES85vcqqZiUwmktpiLENUZvM/8AY= -a \
+		sha256 -b` == seDxuft63ieWCyOgu/GV1rV3E7yROXeS+rC9cA6IL7Y= -a \
+		`echo Hello | ../dMagnetic -ini ../dMagnetic.ini \
+		-mag minitest.mag -gfx minitest.gfx \
+		-vmode monochrome_inv -vecho -vcols 300 -vrows 300 | \
+		sha256 -b` == MfppImDWbkyITNN49NVWlI+iysmToiJzW1D+d9XkL3Q= -a \
 		`echo Hello | ../dMagnetic -ini ../dMagnetic.ini \
 		-mag minitest.mag -gfx minitest.gfx \
 		-vmode low_ansi -vecho -vcols 300 -vrows 300 | \
-		sha256 -b` == 6DhbUg1shZBuSXIm3PNK1/fMfRQ5RIHCuLPik+IkeQM= -a \
+		sha256 -b` == AwX+FxRDEMR1mi/CP3jn85dWA9UltkoezHn7hmKFI8k= -a \
+		`echo Hello | ../dMagnetic -ini ../dMagnetic.ini \
+		-mag minitest.mag -gfx minitest.gfx \
+		-vmode low_ansi2 -vecho -vcols 300 -vrows 300 | \
+		sha256 -b` == 70oe3RMTJG3/R6nUTigntHXEg+/ORW0cNHW5sZ+P2Lc= -a \
 		`echo Hello | ../dMagnetic -ini ../dMagnetic.ini \
 		-mag minitest.mag -gfx minitest.gfx \
 		-vmode high_ansi -vecho -vcols 300 -vrows 300 | \
-		sha256 -b` == ShiqpQ8Ey8CSV2g3gMCCzSS89Ak6ZaNUQjaw11Tcj8k= -a \
+		sha256 -b` == kaRDtG5AyqOo8ikUStr+giD0RfRSyuZjLg99zZXgO58= -a \
 		`echo Hello | ../dMagnetic -ini ../dMagnetic.ini \
 		-mag minitest.mag -gfx minitest.gfx \
 		-vmode sixel -vecho -vcols 300 -vrows 300 | \
-		sha256 -b` == RLueDmrARhpkn8A9YOJz1OW2YLRDBlKCjlxY3Ef56ro= \
+		sha256 -b` == ad6zWhMj07AY0kn7DrkbM4cuRU2YbHU4kSq6PJHVWjI= \
 		]; \
 		then echo ok; else echo expected output not seen; exit 1; fi
 
--- distinfo.orig	2020-06-08 08:03:15.022919169 +0200
+++ distinfo	2020-06-08 08:03:15.026891301 +0200
@@ -1,2 +1,2 @@
-SHA256 (dMagnetic_0.22.tar.bz2) = U5BcihppxcaaevysXQNo7cbCFPxgPz12MT5PM/rrBDE=
-SIZE (dMagnetic_0.22.tar.bz2) = 61092
+SHA256 (dMagnetic_0.23.tar.bz2) = HlVbam71s6VNL+JayD+9EA499jQqleiDVKJSjOqo/w8=
+SIZE (dMagnetic_0.23.tar.bz2) = 60820

[update] dokuwiki hotfix releases

[Landry Breuil]

Hi,

even if dokuwiki itself doesnt see new feature releases, there's been
two hotfixes releases since the version we ship:
https://www.dokuwiki.org/changes#release_2018-04-22c_greebo

Hotfix 2018-04-22b
fix PHP 7.3 compatibility: https://github.com/splitbrain/dokuwiki/issues/2622
fix ACL check: https://github.com/splitbrain/dokuwiki/pull/2609

Hotfix 2018-04-22c
fix an XSS Vulnerability: https://github.com/splitbrain/dokuwiki/issues/3044

Maybe worth backporting to stable ?

Landry
Index: Makefile
===
RCS file: /cvs/ports/www/dokuwiki/Makefile,v
retrieving revision 1.34
diff -u -r1.34 Makefile
--- Makefile26 Sep 2019 21:59:30 -  1.34
+++ Makefile8 Jun 2020 06:12:05 -
@@ -2,12 +2,11 @@
 
 COMMENT =  standards compliant, simple to use Wiki
 
-VERSION =  2018-04-22a
+VERSION =  2018-04-22c
 DISTNAME = dokuwiki-${VERSION}
 PKGNAME =  dokuwiki-${VERSION:S/-/./g}
 CATEGORIES =   www
 HOMEPAGE = https://www.dokuwiki.org/dokuwiki
-REVISION = 2
 
 MAINTAINER =   Pierre-Emmanuel Andre 
 
Index: distinfo
===
RCS file: /cvs/ports/www/dokuwiki/distinfo,v
retrieving revision 1.16
diff -u -r1.16 distinfo
--- distinfo15 Jul 2018 20:53:02 -  1.16
+++ distinfo8 Jun 2020 06:12:05 -
@@ -1,2 +1,2 @@
-SHA256 (dokuwiki-2018-04-22a.tgz) = 
KE4TKfJzItqLQSD2kXGuj6EsYTRFP803ANKRTEenAgQ=
-SIZE (dokuwiki-2018-04-22a.tgz) = 3749191
+SHA256 (dokuwiki-2018-04-22c.tgz) = 
eP+XvlcU5H0N3TUxz/tEVlxBUsl7I0L+mgrC1Xe9+Ns=
+SIZE (dokuwiki-2018-04-22c.tgz) = 3745201

Re: [S-mailx] .nailrc and Gmail

[Predrag Punosevac]

Predrag Punosevac  wrote:

> 
> Predrag Punosevac  wrote:
> 
> > Hi Steffen,
> > 
> > I apologize for a direct email. I am not sure new mailing list will
> > allow me to post. 
> > 
> > I kept my own v14.8.12 copy of nail after few things got broken on
> > OpenBSD.  I didn't notice that you adopted OpenBSD port and updated it
> > to 14.9 branch until today. Old port was behind the version I was using.
> > 
> 
> 
> Hi Steffen,
> 
> I apologize for cross posting. After upgrading my laptop to 
> 
> predrag@oko-mobile$ uname -a
> OpenBSD oko-mobile.int.bagdala2.net 6.7 GENERIC.MP#2 amd64
> 
> I felt it was the time for me to jump the ship and finally go with
> s-nail from the official ports tree. 
> 
> predrag@oko-mobile$ pkg_info s-nail
> Information for inst:s-nail-14.9.17
> 
> I got to the bottom of all "issues" I originally reported 
> 
> https://www.mail-archive.com/s-mailx@lists.sdaoden.eu/msg00948.html
> 
> in the thread. I used quotation marks around issues as in the hindsight
> there was really only one. All other issues were due to the fact that I
> didn't realize that you have completely rewritten s-nail and there is
> really not much in common with the original Heirloom mailx
> 
> http://heirloom.sourceforge.net/mailx.html
> 
> which I used for at least 15 years. That is not to say that the things
> don't work or they are worse. They just work different. It took me two
> full days of dicking with it to get a to get a hang of it.
> 
> First thing first you really trough me off the board with Ctrl+D instead
> of next line and a dot to sent the email. I have not read the code, and

I am a total moron! I read carefully mail(1). Ctrl+D is of course
correct. What I didn't realize is that mail always reads

predrag@oko$ more /etc/mail.rc
set append dot save asksub
ignore Received Message-Id Resent-Message-Id Status Mail-From
Return-Path Via

s-nail of course has no access to that file.

set dot 

in my .s-nailrc and s-nail behaves as expected. As an upshot I
"backported" 14.9.19 to 6.7 stable branch. As you can see it works
as expected.

Cheers,
Predrag



> even if I did I don't have sufficient programming background to
> understand design decession but I am using dot to sent emails since
> circa 1989 and that is a hard pill to swallow. That is why I kept
> reporting that sending email doesn't work. 
> 
> I noticed that 14.9.17 on 6.7 doesn't report that annoying message
> 
> There are new messages in the error message ring (denoted by ERROR),
> nail:   which can be managed with the `errors' command
> ERROR# ? 
> 
> I really like new configuration grammar. This is my not so minimal
> working example
> 
> predrag@oko-mobile$ more .mailrc 
> set ask
> set crt
> ignore message-id received date fcc status resent-date resent-message-id
> resent-from in-reply-to
> 
> set mailx-extra-rc=~/.nailrc
> 
> and this is dotnailrc file
> 
> account gmail {
>   set inbox=imaps://usern...@imap.gmail.com
>   set imap-use-starttls
>   set password="secret"
>   set folder=imaps://usern...@imap.gmail.com record="+[Gmail]/Sent Mail"
>   set from="Predrag Punosevac " \
>   mta=smtp://usern...@smtp.gmail.com:587 \
>   set smtp-use-starttls 
>   set smtp-auth="login" 
> # IMAP SHORTCUTS SECTION for standard Gmail folders
>   shortcut allmail +[Gmail]/All\ Mail
>   shortcut sent +[Gmail]/Sent\ Mail
>   shortcut spam +[Gmail]/Spam
>   shortcut trash +[Gmail]/Trash
>   }
> account cmu {
>   set inbox=imaps://username%40andrew.cmu@imap.gmail.com
>   set imap-use-starttls
>   set password="secret"
>   set from="Predrag Punosevac " \
>   mta=smtp://username%40andrew.cmu@smtp.gmail.com:587 \
>   set smtp-use-starttls 
>   set smtp-auth="login" 
> # IMAP SHORTCUTS SECTION for standard Gmail folders
>   shortcut allmail +[Gmail]/All\ Mail
>   shortcut sent +[Gmail]/Sent\ Mail
>   shortcut spam +[Gmail]/Spam
>   shortcut trash +[Gmail]/Trash
>   }
> account hotmail {
>   set inbox=imaps://username%40hotmail@imap-mail.outlook.com
>   set folder=imaps://username%40hotmail@imap-mail.outlook.com
>   set imap-use-starttls
>   set password="secret"
>   set from="Predrag Punosevac " \
>   mta=smtp://username%40hotmail@smtp-mail.outlook.com:587
>   set smtp-use-starttls 
>   set smtp-auth="login"
>   }
> 
> 
> # Binary options
> set askattach
> set askcc
> set autocollapse
> set autosort=thread
> set junkdb=~/.junkdb
> set v15-compat
> set tls-verify=strict
> 
> # String Options
> set imap-keepalive=240
> set imap-list-depth=5
> 
> # Reading HTML mail
> set pipe-text/html="lynx -dump -force_html -stdin"
> 
> # Address Book
> alias   somebody   someb...@gmail.com
> 
> 
> For people who would be reading this email one comment. Without
> 
> set folder 
> 
> line you will not be able (not in a convenient way) to list your IMAP
> folders. I feel new grammar is nicer than the old. I have

Re: Go and portgen(1)

[Stuart Henderson]

> I can also generate a very large set of ports with it!

If you're interested in examples of things that don't work with this,
here are a couple I ran into.

github.com/tomnomnom/gron
github.com/gcla/termshark/v2

Re: [NEW] math/vtk8

[Stuart Henderson]

Attached new tgz, I haven't done anything about the internal copies
of libraries though.

On 2020/06/07 08:01, Charlie Burnett wrote:
> Thanks for all your help and extensive patience on this Stuart! I’ll try to
> ensure I follow your advice on other stuff here forward. In a similar vein,
> a dependency is part of a local version of a library for opencv (flann)- I
> need to poke around a little more, but would it be advisable to try to make
> that into its own port and point both packages to mark it as a dependency?

Not sure, I don't know enough about that library to say really, it looks
like it might be an atypical case.

Many of the things in vtk's ThirdParty directory look like they should be
switched though. There is a cmake flag VTK_USE_SYSTEM_LIBRARIES that would
have it use system versions of everything it can find by default (e.g. in
CONFIGURE_ARGS set -DVTK_USE_SYSTEM_LIBRARIES=on), or there are various
settings for individual libs which might be better to use (auto detect
is often a problem when new ports are added later).

VTK_USE_SYSTEM_DIY2
VTK_USE_SYSTEM_DOUBLECONVERSION
VTK_USE_SYSTEM_EIGEN
VTK_USE_SYSTEM_EXPAT
VTK_USE_SYSTEM_FREETYPE
VTK_USE_SYSTEM_GL2PS
VTK_USE_SYSTEM_GLEW
VTK_USE_SYSTEM_HDF5
VTK_USE_SYSTEM_JPEG
VTK_USE_SYSTEM_JSONCPP
VTK_USE_SYSTEM_KISSFFT
VTK_USE_SYSTEM_LIBHARU
VTK_USE_SYSTEM_LIBPROJ
VTK_USE_SYSTEM_LIBXML2
VTK_USE_SYSTEM_LZ4
VTK_USE_SYSTEM_LZMA
VTK_USE_SYSTEM_NETCDF
VTK_USE_SYSTEM_PEGTL
VTK_USE_SYSTEM_PNG
VTK_USE_SYSTEM_PUGIXML
VTK_USE_SYSTEM_SQLITE
VTK_USE_SYSTEM_THEORA
VTK_USE_SYSTEM_TIFF
VTK_USE_SYSTEM_UTF8
VTK_USE_SYSTEM_XDMF3
VTK_USE_SYSTEM_ZFP
VTK_USE_SYSTEM_ZLIB

Not all of these are in ports, and for some of them vtk may want different
versions than we have so they might not work, but we'd definitely want system
versions of these if at all possible: expat freetype zlib (in base),
jpeg jsoncpp libxml2 lz4 lzma ogg png tiff (in ports).

These are also in ports and I think we'd at least want to try to use system
versions: doubleconversion eigen gl2ps glew hdf5 libharu libproj netcdf pugixml
sqlite (really sqlite3) theora




vtk8.tgz
Description: application/tar-gz

Re: UPDATE x11/herbstluftwm 0.7.2 -> 0.8.3

[Lucas]

Lucas  wrote:
> hlwm installs autostart, panel.sh, restartpanels.sh and dmenu_run_hlwm
> to /etc/xdg/herbstluftwm. At the beginning, we were providing the 4 as
> @samples, but decided stop doing it for dmenu_run_hlwm last moment, but
> forgot to remove the mv from post-install. Good catch.
> 
> After some digging, dmenu_run_hlwm isn't referenced in the default
> config files but the FAQ[0] suggest to bind, and assumes it's somewhere
> in PATH. So check updated patch, adding x11/dmenu as RDEP and installing
> dmenu_run_hlwm to /usr/local/bin.
> 
> While there, turns out 0.8.3 got released yesterday with a fix for a
> race condition, so bump that too.
> 
> Thanks for checking it. No diff -w this time.
> 
> -Lucas
> 
> [0]: 
> https://herbstluftwm.org/faq.html#_q_how_can_i_keybind_a_simple_run_dialog

bket@ pointed out we forgot x11/dmenu as RDEP. Updated diff below.

Index: Makefile
===
RCS file: /home/cvs/ports/x11/herbstluftwm/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile17 Oct 2019 20:23:03 -  1.15
+++ Makefile7 Jun 2020 20:14:27 -
@@ -1,39 +1,53 @@
 # $OpenBSD: Makefile,v 1.15 2019/10/17 20:23:03 rsadowski Exp $
 
-COMMENT =  manual tiling window manager
-DISTNAME = herbstluftwm-0.7.2
-CATEGORIES =   x11
+COMMENT =  manual tiling window manager
+DISTNAME = herbstluftwm-0.8.3
+CATEGORIES =   x11
 
-HOMEPAGE = https://herbstluftwm.org/
+HOMEPAGE = https://herbstluftwm.org/
+
+MAINTAINER =   Lucas , \
+   Florian Viehweger 
 
 # BSD
 PERMIT_PACKAGE =   Yes
 
-WANTLIB += X11 Xext Xinerama c glib-2.0 intl m pthread ${COMPILER_LIBCXX}
+WANTLIB += X11 Xext Xinerama Xrandr c m pthread ${COMPILER_LIBCXX}
 
-MASTER_SITES = https://herbstluftwm.org/tarballs/
+MASTER_SITES = https://herbstluftwm.org/tarballs/
 
 # c++11
-COMPILER = base-clang ports-gcc
-
-LIB_DEPENDS += devel/glib2
+COMPILER = base-clang ports-gcc
 
-RUN_DEPENDS += devel/desktop-file-utils \
-   shells/bash \
-   x11/dzen2,-gadgets
-
-CPPFLAGS +=-I${LOCALBASE}/include
-USE_GMAKE =Yes
-MAKE_FLAGS =   LDFLAGS= VERBOSE= COLOR=0 CC='${CC}' LDXX='${CXX}' CXX='${CXX}'
-
-BASEDIR =  ${PREFIX}/share/examples/herbstluftwm
-FAKE_FLAGS =   SYSCONFDIR="${BASEDIR}" \
-   EXAMPLESDIR="${BASEDIR}" \
-   ZSHCOMPLETIONDIR="${BASEDIR}/zsh/functions/Completion/X" \
-   MANDIR="${PREFIX}/man" \
-   PREFIX="${PREFIX}" \
-   XSESSIONSDIR="${PREFIX}/share/applications"
+MODULES += devel/cmake
 
-NO_TEST =  Yes
+RUN_DEPENDS += devel/desktop-file-utils \
+   shells/bash \
+   x11/dmenu \
+   x11/dzen2,-gadgets
+
+# tarball already includes generated manpages
+# saves depend on asciidoc
+CONFIGURE_ARGS +=  -DWITH_DOCUMENTATION=NO
+
+# requires unported pyewmh, pytest-xvfb and maybe more
+NO_TEST =  Yes
+
+post-install:
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/herbstluftwm
+   ${INSTALL_SCRIPT} ${WRKINST}/etc/xdg/herbstluftwm/autostart \
+   ${PREFIX}/share/examples/herbstluftwm/
+   mv ${WRKINST}/etc/xdg/herbstluftwm/dmenu_run_hlwm \
+   ${PREFIX}/bin
+   ${INSTALL_SCRIPT} ${WRKINST}/etc/xdg/herbstluftwm/panel.sh \
+   ${PREFIX}/share/examples/herbstluftwm/
+   ${INSTALL_SCRIPT} ${WRKINST}/etc/xdg/herbstluftwm/restartpanels.sh \
+   ${PREFIX}/share/examples/herbstluftwm/
+   ${INSTALL_MAN} ${WRKSRC}/doc/herbstclient.1 \
+   ${PREFIX}/man/man1/herbstclient.1
+   ${INSTALL_MAN} ${WRKSRC}/doc/herbstluftwm.1 \
+   ${PREFIX}/man/man1/herbstluftwm.1
+   ${INSTALL_MAN} ${WRKSRC}/doc/herbstluftwm-tutorial.7 \
+   ${PREFIX}/man/man7/herbstluftwm-tutorial.7
 
 .include 
Index: distinfo
===
RCS file: /home/cvs/ports/x11/herbstluftwm/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo17 Oct 2019 20:23:03 -  1.5
+++ distinfo7 Jun 2020 15:12:30 -
@@ -1,2 +1,2 @@
-SHA256 (herbstluftwm-0.7.2.tar.gz) = 
3/YT/G14g+ogETGO+KexW5L3hk6vYyKd+c4OmaRCgc0=
-SIZE (herbstluftwm-0.7.2.tar.gz) = 245506
+SHA256 (herbstluftwm-0.8.3.tar.gz) = 
oU47fgwcP2oxigqc9jGkq1cubeIshMd2A8844eQlq+I=
+SIZE (herbstluftwm-0.8.3.tar.gz) = 379052
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/x11/herbstluftwm/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST
--- pkg/PLIST   4 Jan 2019 00:25:47 -   1.5
+++ pkg/PLIST   6 Jun 2020 14:09:57 -
@@ -1,56 +1,56 @@
 @comment $OpenBSD: PLIST,v 1.5 2019/01/04 00:25:47 jca Exp $
+@tag update-desktop-database
+@sample ${SYSCONFDIR}/xdg/
+@sample ${SYSC

Re: [S-mailx] .nailrc and Gmail

[Predrag Punosevac]

Predrag Punosevac  wrote:

> Hi Steffen,
> 
> I apologize for a direct email. I am not sure new mailing list will
> allow me to post. 
> 
> I kept my own v14.8.12 copy of nail after few things got broken on
> OpenBSD.  I didn't notice that you adopted OpenBSD port and updated it
> to 14.9 branch until today. Old port was behind the version I was using.
> 


Hi Steffen,

I apologize for cross posting. After upgrading my laptop to 

predrag@oko-mobile$ uname -a
OpenBSD oko-mobile.int.bagdala2.net 6.7 GENERIC.MP#2 amd64

I felt it was the time for me to jump the ship and finally go with
s-nail from the official ports tree. 

predrag@oko-mobile$ pkg_info s-nail
Information for inst:s-nail-14.9.17

I got to the bottom of all "issues" I originally reported 

https://www.mail-archive.com/s-mailx@lists.sdaoden.eu/msg00948.html

in the thread. I used quotation marks around issues as in the hindsight
there was really only one. All other issues were due to the fact that I
didn't realize that you have completely rewritten s-nail and there is
really not much in common with the original Heirloom mailx

http://heirloom.sourceforge.net/mailx.html

which I used for at least 15 years. That is not to say that the things
don't work or they are worse. They just work different. It took me two
full days of dicking with it to get a to get a hang of it.

First thing first you really trough me off the board with Ctrl+D instead
of next line and a dot to sent the email. I have not read the code, and
even if I did I don't have sufficient programming background to
understand design decession but I am using dot to sent emails since
circa 1989 and that is a hard pill to swallow. That is why I kept
reporting that sending email doesn't work. 

I noticed that 14.9.17 on 6.7 doesn't report that annoying message

There are new messages in the error message ring (denoted by ERROR),
nail:   which can be managed with the `errors' command
ERROR# ? 

I really like new configuration grammar. This is my not so minimal
working example

predrag@oko-mobile$ more .mailrc 
set ask
set crt
ignore message-id received date fcc status resent-date resent-message-id
resent-from in-reply-to

set mailx-extra-rc=~/.nailrc

and this is dotnailrc file

account gmail {
set inbox=imaps://usern...@imap.gmail.com
set imap-use-starttls
set password="secret"
set folder=imaps://usern...@imap.gmail.com record="+[Gmail]/Sent Mail"
set from="Predrag Punosevac " \
mta=smtp://usern...@smtp.gmail.com:587 \
set smtp-use-starttls 
set smtp-auth="login" 
# IMAP SHORTCUTS SECTION for standard Gmail folders
shortcut allmail +[Gmail]/All\ Mail
shortcut sent +[Gmail]/Sent\ Mail
shortcut spam +[Gmail]/Spam
shortcut trash +[Gmail]/Trash
}
account cmu {
set inbox=imaps://username%40andrew.cmu@imap.gmail.com
set imap-use-starttls
set password="secret"
set from="Predrag Punosevac " \
mta=smtp://username%40andrew.cmu@smtp.gmail.com:587 \
set smtp-use-starttls 
set smtp-auth="login" 
# IMAP SHORTCUTS SECTION for standard Gmail folders
shortcut allmail +[Gmail]/All\ Mail
shortcut sent +[Gmail]/Sent\ Mail
shortcut spam +[Gmail]/Spam
shortcut trash +[Gmail]/Trash
}
account hotmail {
set inbox=imaps://username%40hotmail@imap-mail.outlook.com
set folder=imaps://username%40hotmail@imap-mail.outlook.com
set imap-use-starttls
set password="secret"
set from="Predrag Punosevac " \
mta=smtp://username%40hotmail@smtp-mail.outlook.com:587
set smtp-use-starttls 
set smtp-auth="login"
}


# Binary options
set askattach
set askcc
set autocollapse
set autosort=thread
set junkdb=~/.junkdb
set v15-compat
set tls-verify=strict

# String Options
set imap-keepalive=240
set imap-list-depth=5

# Reading HTML mail
set pipe-text/html="lynx -dump -force_html -stdin"

# Address Book
alias   somebody   someb...@gmail.com


For people who would be reading this email one comment. Without

set folder 

line you will not be able (not in a convenient way) to list your IMAP
folders. I feel new grammar is nicer than the old. I have been using
s-nail now for three days. I really, really like what you have done with
search options. The only time in my life I contemplated switching to nmh

https://www.nongnu.org/nmh/

was for its integration with standard shell tools (of course MH format
is really a big plus).

I see that you are planning to remove IMAP support and that would be a
tough thing for me to swallow.

I also noticed that you put a lot of time into documentation. Most of
the stuff is there but it feels a bit disorganized for my taste. I wish,
I was younger and less busy. I know that you could use a helping hand.

Really good job!

Cheers,
Predrag




> I just installed v14.9.15 but my configuration files seems to be bro

Re: curl with libidn

[Stuart Henderson]

On 2020/06/07 16:18, f.holop wrote:
> Stuart Henderson - Fri, 05 June 2020 at 00:03:04
> > Adding it would add more code to something that is quite a common
> > dependency. Maybe it's useful enough to be worth it (being from a
> > country with mostly 7-bit charset I don't get much of a vote in this ;)
> > but along with the upside of support IDNs, there is a downside to
> > pulling in (historically a bit buggy) code to all ports using the
> > library.
> 
> I agree, it is marginally useful...  Is that margin worth it?
> 
> In my case i needed this to troubleshoot quickly an RSS feed on such a
> domain.
> 
> It would be nice to have a curl and curl-idn package without me having
> to hand roll one. But then where is the limit for a "swiss army knife"
> tool?  Some linux distro packages come with everything curl can support
> compiled in down to gopher...

It could be possible to do a static-linked build of the curl binary in
a different port, that would avoid the problems with other ports depending
on the library.

It is possible to use curl like this, though:

$ curl -I https://`idn2 рнидс.срб`/

It's not quite as easy as internal support but doesn't seem too bad.

Re: boost-md: build on sparc64

[Stuart Henderson]

On 2020/06/07 14:18, Klemens Nanni wrote:
> On Sun, Jun 07, 2020 at 02:13:50PM +0200, Otto Moerbeek wrote:
> > Looking a bit closes I can see that the userland context switching
> > primitives are not there in
> > /usr/ports/pobj/boost_1_66_0/boost_1_66_0/libs/context/src so that
> > part is not going to fly. There might be other parts though that are
> > interesting and make boost-md worthwhile to build for sparc64.
> Cool, thanks for looking.  I'm making progress with a port using boost-md
> every now and then, eventually I'll most likely run into this and can
> test/report.
> 
> Meanwhile, I committed the diff such that sparc64 builds boost-md now.
> 

I don't really like providing a library that is known to be broken.

Maybe boost-md should be split into multiple packages. Otherwise we should
disable build of the other dependent ports (kicad, icinga2, pdns_recursor,
all of which want boost-context) but it seems wrong to do it in the dependent
ports rather than the port where the problem is.

Re: UPDATE x11/herbstluftwm 0.7.2 -> 0.8.3

[Lucas]

Hi Bjorn,

Bjorn Ketelaars  wrote:
> > - We aren't sure if we should add x11/dmenu to RUN_DEPENDS. One of the
> >   4 scripts it installs to /etc/xdg/herbstluftwm needs it, but that
> >   script isn't referenced by the others, unlike the case x11/dzen2.
> >   Advice is welcome in here, too.
> 
> After installation of this update I only see 3 scripts in
> /etc/xdg/herbstluftwm. None of them use dmenu. As such, I see no reason
> to add x11/dmenu as RDEP.
> 
> $ ls -l /etc/xdg/herbstluftwm/
> total 40
> -rwxr-xr-x  1 root  wheel  5365 Jun  6 11:44 autostart
> -rwxr-xr-x  1 root  wheel  6210 Jun  6 11:44 panel.sh
> -rwxr-xr-x  1 root  wheel   379 Jun  6 11:44 restartpanels.sh
> 
> [...]
> >   - dmenu_run_hlwm was being installed to bin/; now resides in
> > share/examples/herbstluftwm/
> 
> Odd, I would expect that having dmenu_run_hlwm in /usr/local/bin/ is a
> good reason for adding dmenu as RDEP. Guess this is not relevant as you
> propose to move this script. However, I have a question: is moving this
> script going to break existing installations?
> 
> Other question: why is dmenu_run_hlwm moved in the post-install phase?

hlwm installs autostart, panel.sh, restartpanels.sh and dmenu_run_hlwm
to /etc/xdg/herbstluftwm. At the beginning, we were providing the 4 as
@samples, but decided stop doing it for dmenu_run_hlwm last moment, but
forgot to remove the mv from post-install. Good catch.

After some digging, dmenu_run_hlwm isn't referenced in the default
config files but the FAQ[0] suggest to bind, and assumes it's somewhere
in PATH. So check updated patch, adding x11/dmenu as RDEP and installing
dmenu_run_hlwm to /usr/local/bin.

While there, turns out 0.8.3 got released yesterday with a fix for a
race condition, so bump that too.

Thanks for checking it. No diff -w this time.

-Lucas

[0]: https://herbstluftwm.org/faq.html#_q_how_can_i_keybind_a_simple_run_dialog


Index: Makefile
===
RCS file: /home/cvs/ports/x11/herbstluftwm/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile17 Oct 2019 20:23:03 -  1.15
+++ Makefile7 Jun 2020 15:12:05 -
@@ -1,39 +1,52 @@
 # $OpenBSD: Makefile,v 1.15 2019/10/17 20:23:03 rsadowski Exp $
 
-COMMENT =  manual tiling window manager
-DISTNAME = herbstluftwm-0.7.2
-CATEGORIES =   x11
+COMMENT =  manual tiling window manager
+DISTNAME = herbstluftwm-0.8.3
+CATEGORIES =   x11
 
-HOMEPAGE = https://herbstluftwm.org/
+HOMEPAGE = https://herbstluftwm.org/
+
+MAINTAINER =   Lucas , \
+   Florian Viehweger 
 
 # BSD
 PERMIT_PACKAGE =   Yes
 
-WANTLIB += X11 Xext Xinerama c glib-2.0 intl m pthread ${COMPILER_LIBCXX}
+WANTLIB += X11 Xext Xinerama Xrandr c m pthread ${COMPILER_LIBCXX}
 
-MASTER_SITES = https://herbstluftwm.org/tarballs/
+MASTER_SITES = https://herbstluftwm.org/tarballs/
 
 # c++11
-COMPILER = base-clang ports-gcc
-
-LIB_DEPENDS += devel/glib2
+COMPILER = base-clang ports-gcc
 
-RUN_DEPENDS += devel/desktop-file-utils \
-   shells/bash \
-   x11/dzen2,-gadgets
-
-CPPFLAGS +=-I${LOCALBASE}/include
-USE_GMAKE =Yes
-MAKE_FLAGS =   LDFLAGS= VERBOSE= COLOR=0 CC='${CC}' LDXX='${CXX}' CXX='${CXX}'
-
-BASEDIR =  ${PREFIX}/share/examples/herbstluftwm
-FAKE_FLAGS =   SYSCONFDIR="${BASEDIR}" \
-   EXAMPLESDIR="${BASEDIR}" \
-   ZSHCOMPLETIONDIR="${BASEDIR}/zsh/functions/Completion/X" \
-   MANDIR="${PREFIX}/man" \
-   PREFIX="${PREFIX}" \
-   XSESSIONSDIR="${PREFIX}/share/applications"
+MODULES += devel/cmake
 
-NO_TEST =  Yes
+RUN_DEPENDS += devel/desktop-file-utils \
+   shells/bash \
+   x11/dzen2,-gadgets
+
+# tarball already includes generated manpages
+# saves depend on asciidoc
+CONFIGURE_ARGS +=  -DWITH_DOCUMENTATION=NO
+
+# requires unported pyewmh, pytest-xvfb and maybe more
+NO_TEST =  Yes
+
+post-install:
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/herbstluftwm
+   ${INSTALL_SCRIPT} ${WRKINST}/etc/xdg/herbstluftwm/autostart \
+   ${PREFIX}/share/examples/herbstluftwm/
+   mv ${WRKINST}/etc/xdg/herbstluftwm/dmenu_run_hlwm \
+   ${PREFIX}/bin
+   ${INSTALL_SCRIPT} ${WRKINST}/etc/xdg/herbstluftwm/panel.sh \
+   ${PREFIX}/share/examples/herbstluftwm/
+   ${INSTALL_SCRIPT} ${WRKINST}/etc/xdg/herbstluftwm/restartpanels.sh \
+   ${PREFIX}/share/examples/herbstluftwm/
+   ${INSTALL_MAN} ${WRKSRC}/doc/herbstclient.1 \
+   ${PREFIX}/man/man1/herbstclient.1
+   ${INSTALL_MAN} ${WRKSRC}/doc/herbstluftwm.1 \
+   ${PREFIX}/man/man1/herbstluftwm.1
+   ${INSTALL_MAN} ${WRKSRC}/doc/herbstluftwm-tutorial.7 \
+   ${PREFIX}/man/man7/herbstluftwm-tutorial.7
 
 .includ

Re: [update] net/go-ipfs -> 0.5.1

[Klemens Nanni]

On Thu, Jun 04, 2020 at 08:47:23PM -0600, Aaron Bieber wrote:
> - Switches to MODGO_MODNAME.
Can you document this variable in port-modules(5)?

> I am not super experienced with IPFS yet, but I now have a few nodes
> running and I am mirroring the OpenBSD signify keys here:
> https://ipfs.io/ipfs/QmdTKFSHNRKP56sNBSyMkVzPbSFwXVMiXDM7DUPJjPE5QA/OpenBSD
Same here, light usage works as expected.

OK kn with updated PLIST:

diff -u pkg/PLIST.orig pkg/PLIST
--- pkg/PLIST.orig  Tue Dec 18 12:58:21 2018
+++ pkg/PLIST   Sun Jun  7 16:53:16 2020
@@ -10,4 +10,6 @@
 @owner
 @group
 @bin bin/ipfs
+@bin bin/ipfswatch
+@bin bin/seccat
 share/doc/pkg-readmes/${PKGSTEM}

Re: curl with libidn

[f.holop]

Stuart Henderson - Fri, 05 June 2020 at 00:03:04
> Adding it would add more code to something that is quite a common
> dependency. Maybe it's useful enough to be worth it (being from a
> country with mostly 7-bit charset I don't get much of a vote in this ;)
> but along with the upside of support IDNs, there is a downside to
> pulling in (historically a bit buggy) code to all ports using the
> library.

I agree, it is marginally useful...  Is that margin worth it?

In my case i needed this to troubleshoot quickly an RSS feed on such a
domain.

It would be nice to have a curl and curl-idn package without me having
to hand roll one. But then where is the limit for a "swiss army knife"
tool?  Some linux distro packages come with everything curl can support
compiled in down to gopher...

-f
-- 

[new] audio/gonic a music streaming server (subsonic compat)

[Aaron Bieber]

Hi,

Here is a port of gonic ( https://github.com/sentriz/gonic ). It's a
simple (single binary, minimal config) streaming server that can talk
SubSonic. This means existing SubSonic apps work with gonic!

Running it is pretty easy:
  $ gonic -music-path ~/Music -listen-addr 127.0.0.1:4747

Then open your browser and hit up:
  http://localhost:4747

Default username/pw is: admin/admin

I have tested with a few apps on my iDevices, seems to work well!

Clue stick? OK?

Cheers,
Aaron



gonic.tgz
Description: Binary data

-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE

Re: [NEW] math/vtk8

[Charlie Burnett]

Thanks for all your help and extensive patience on this Stuart! I’ll try to
ensure I follow your advice on other stuff here forward. In a similar vein,
a dependency is part of a local version of a library for opencv (flann)- I
need to poke around a little more, but would it be advisable to try to make
that into its own port and point both packages to mark it as a dependency?

On Sun, Jun 7, 2020 at 7:47 AM Stuart Henderson  wrote:

> I have cleaned things up a little locally but I haven't built it yet,
> might send a new tarball in a bit.
>
> It has many internal copies of libraries which are available in other
> ports, it should be changed to use those from ports instead (as is also
> done in the FreeBSD port).
>
> On 2020/06/06 15:58, Charlie Burnett wrote:
> > Hi Stuart,
> >
> > Is this better? I believe I covered all the bases you mentioned, thanks
> for
> > the help!
> >
> > On 2020-06-05 4:27 PM, Stuart Henderson wrote:
> > > On 2020/06/05 14:44, Charlie Burnett wrote:
> > > > Howdy,
> > > >
> > > > I'm starting to work through and add the dependencies for FreeCAD,
> attached
> > > > you'll find the patch adding the Visual Toolkit Library 8.2.0 to
> ports.
> > > > There's a version 9 available but 8.2 is what's required for FreeCAD.
> > > >
> > > > Development page is here: https://gitlab.kitware.com/vtk/vtk
> > > >
> > > > Let me know if there's anything I missed!
> > > >
> > > quick review, sorry for brevity:
> > >
> > > - send new ports as a tar.gz of the port directory, not of a diff
> > >
> > > - add the rcsid line at the top of the file
> > >
> > > # $OpenBSD$
> > >
> > > - PKG_ARCH=* means "the produced package works on all arches" which
> isn't
> > > the case for anything with binaries
> > >
> > > - SHARED_LIBS version numbers should use the "major.minor" format and
> start
> > > from 0.0, however with the huge number of libraries it's going to be
> insane
> > > to analyse and figure out which individual ones need bumps in future I
> think
> > > you can just do it like this, so all the versions can be updated in
> one go
> > >
> > > LIBVER =0.0
> > > SHARED_LIBS +=  vtkChartsCore   ${LIBVER}
> > > SHARED_LIBS +=  vtkCommonColor  ${LIBVER}
> > > SHARED_LIBS +=  vtkCommonComputationalGeometry  ${LIBVER}
> > > SHARED_LIBS +=  vtkCommonCore   ${LIBVER}
> > > etc.
> > >
> > > - the following are set by default when cmake is used, please drop the
> lines:
> > > SEPARATE_BUILD
> > > USE_NINJA
> > >
> > > - PKGNAME=${DISTNAME} is set by default and normally should be dropped,
> > > though we generally prefer lowercase package names so for this I'd use
> > > PKGNAME=${DISTNAME:L} to do that
> > >
> > > - DESCR should be word-wrapped
> > >
> > > - was there a particular reason for the patches that rename the
> libraries?
> > > e.g.
> > > +-  qt5_wrap_cpp(PluginMocSrcs ${PluginMocHeaders} TARGET
> QVTKWidgetPlugin)
> > > ++  qt5_wrap_cpp(PluginMocSrcs ${PluginMocHeaders} TARGET
> QVTKWidgetPlugin-${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION})
> > >
> > > doing this usually causes problems (and causes the library names to
> not match
> > > your SHARED_LIBS lines which results in the version numbers not being
> set
> > > properly). Probably want to drop those patches and rerun "make plist"
> which
> > > with the SHARED_LIBS changes should result in replacing
> > >
> > > lib/libvtkChartsCore-8.2.so.1
> > > lib/libvtkCommonColor-8.2.so.1
> > >
> > > with
> > >
> > > @so lib/libvtkChartsCore.so.${LIBvtkChartsCore_VERSION}
> > > @so lib/libvtkCommonColor.so.${LIBvtkCommonColor_VERSION}
> > >
> > > etc.
> > >
> > > There will be some other things but it will be easier to look at
> > > them with the above changed.
> > >
>
>
>

Re: [NEW] math/vtk8

[Stuart Henderson]

I have cleaned things up a little locally but I haven't built it yet,
might send a new tarball in a bit.

It has many internal copies of libraries which are available in other
ports, it should be changed to use those from ports instead (as is also
done in the FreeBSD port).

On 2020/06/06 15:58, Charlie Burnett wrote:
> Hi Stuart,
> 
> Is this better? I believe I covered all the bases you mentioned, thanks for
> the help!
> 
> On 2020-06-05 4:27 PM, Stuart Henderson wrote:
> > On 2020/06/05 14:44, Charlie Burnett wrote:
> > > Howdy,
> > > 
> > > I'm starting to work through and add the dependencies for FreeCAD, 
> > > attached
> > > you'll find the patch adding the Visual Toolkit Library 8.2.0 to ports.
> > > There's a version 9 available but 8.2 is what's required for FreeCAD.
> > > 
> > > Development page is here: https://gitlab.kitware.com/vtk/vtk
> > > 
> > > Let me know if there's anything I missed!
> > > 
> > quick review, sorry for brevity:
> > 
> > - send new ports as a tar.gz of the port directory, not of a diff
> > 
> > - add the rcsid line at the top of the file
> > 
> > # $OpenBSD$
> > 
> > - PKG_ARCH=* means "the produced package works on all arches" which isn't
> > the case for anything with binaries
> > 
> > - SHARED_LIBS version numbers should use the "major.minor" format and start
> > from 0.0, however with the huge number of libraries it's going to be insane
> > to analyse and figure out which individual ones need bumps in future I think
> > you can just do it like this, so all the versions can be updated in one go
> > 
> > LIBVER =0.0
> > SHARED_LIBS +=  vtkChartsCore   ${LIBVER}
> > SHARED_LIBS +=  vtkCommonColor  ${LIBVER}
> > SHARED_LIBS +=  vtkCommonComputationalGeometry  ${LIBVER}
> > SHARED_LIBS +=  vtkCommonCore   ${LIBVER}
> > etc.
> > 
> > - the following are set by default when cmake is used, please drop the 
> > lines:
> > SEPARATE_BUILD
> > USE_NINJA
> > 
> > - PKGNAME=${DISTNAME} is set by default and normally should be dropped,
> > though we generally prefer lowercase package names so for this I'd use
> > PKGNAME=${DISTNAME:L} to do that
> > 
> > - DESCR should be word-wrapped
> > 
> > - was there a particular reason for the patches that rename the libraries?
> > e.g.
> > +-  qt5_wrap_cpp(PluginMocSrcs ${PluginMocHeaders} TARGET QVTKWidgetPlugin)
> > ++  qt5_wrap_cpp(PluginMocSrcs ${PluginMocHeaders} TARGET 
> > QVTKWidgetPlugin-${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION})
> > 
> > doing this usually causes problems (and causes the library names to not 
> > match
> > your SHARED_LIBS lines which results in the version numbers not being set
> > properly). Probably want to drop those patches and rerun "make plist" which
> > with the SHARED_LIBS changes should result in replacing
> > 
> > lib/libvtkChartsCore-8.2.so.1
> > lib/libvtkCommonColor-8.2.so.1
> > 
> > with
> > 
> > @so lib/libvtkChartsCore.so.${LIBvtkChartsCore_VERSION}
> > @so lib/libvtkCommonColor.so.${LIBvtkCommonColor_VERSION}
> > 
> > etc.
> > 
> > There will be some other things but it will be easier to look at
> > them with the above changed.
> > 

Re: [NEW] devel/libarea

[Stuart Henderson]

On 2020/06/07 13:44, Stuart Henderson wrote:
> On 2020/06/06 21:25, Charlie Burnett wrote:
> > Howdy,
> > 
> > For your porting pleasure see attached for a port of libarea, a small
> > library for computer assisted machining, also required for FreeCAD.
> > 
> > Best regards
> > 
> 
> Here it is with a cleaned up Makefile following the standard ordering
> from /usr/ports/infrastructure/templates/Makefile.template, fixing some
> of the problems in upstream's CMakeFile, and not mixing python 2 and 3.
> 
> It is not super-clean because I can't figure out how to cleanly get
> the python module built directly as area.so and the shared library as
> libarea.so.0.0 so it's building the python module under a different name
> and moving it into place in the port Makefile. This would probably need
> a CMake wizard to fix properly.
> 

oops, missed attachment.

Also I moved it from devel/ to cad/.


libarea.tgz
Description: application/tar-gz

Re: [NEW] devel/libarea

[Stuart Henderson]

On 2020/06/06 21:25, Charlie Burnett wrote:
> Howdy,
> 
> For your porting pleasure see attached for a port of libarea, a small
> library for computer assisted machining, also required for FreeCAD.
> 
> Best regards
> 

Here it is with a cleaned up Makefile following the standard ordering
from /usr/ports/infrastructure/templates/Makefile.template, fixing some
of the problems in upstream's CMakeFile, and not mixing python 2 and 3.

It is not super-clean because I can't figure out how to cleanly get
the python module built directly as area.so and the shared library as
libarea.so.0.0 so it's building the python module under a different name
and moving it into place in the port Makefile. This would probably need
a CMake wizard to fix properly.

Re: boost-md: build on sparc64

[Otto Moerbeek]

On Sun, Jun 07, 2020 at 02:18:51PM +0200, Klemens Nanni wrote:

> On Sun, Jun 07, 2020 at 02:13:50PM +0200, Otto Moerbeek wrote:
> > Looking a bit closes I can see that the userland context switching
> > primitives are not there in
> > /usr/ports/pobj/boost_1_66_0/boost_1_66_0/libs/context/src so that
> > part is not going to fly. There might be other parts though that are
> > interesting and make boost-md worthwhile to build for sparc64.
> Cool, thanks for looking.  I'm making progress with a port using boost-md
> every now and then, eventually I'll most likely run into this and can
> test/report.
> 
> Meanwhile, I committed the diff such that sparc64 builds boost-md now.
> 

And indeed, powerdns_recursor confure fails with:

checking what context library to use for MTasker... configure: error:
neither boost::context nor System V ucontexts available


-Otto

Re: boost-md: build on sparc64

[Klemens Nanni]

On Sun, Jun 07, 2020 at 02:13:50PM +0200, Otto Moerbeek wrote:
> Looking a bit closes I can see that the userland context switching
> primitives are not there in
> /usr/ports/pobj/boost_1_66_0/boost_1_66_0/libs/context/src so that
> part is not going to fly. There might be other parts though that are
> interesting and make boost-md worthwhile to build for sparc64.
Cool, thanks for looking.  I'm making progress with a port using boost-md
every now and then, eventually I'll most likely run into this and can
test/report.

Meanwhile, I committed the diff such that sparc64 builds boost-md now.

Re: boost-md: build on sparc64

[Otto Moerbeek]

On Sun, Jun 07, 2020 at 08:14:14AM +0200, Otto Moerbeek wrote:

> On Sun, Jun 07, 2020 at 07:57:09AM +0200, Otto Moerbeek wrote:
> 
> > On Sat, Jun 06, 2020 at 08:29:38PM +0100, Stuart Henderson wrote:
> > 
> > > +CC otto@, do you remember the status of context/coroutine on sparc64?
> > > I think they were crashing weren't they?
> > 
> > I think they were fixed with a compiler patch.
> 
> Looking back I might have mixed things up. The conpiler patch fixed
> exception handling on sparc64. pdns_recursor is a heavy user of
> boost-md. I can try to build it and see how things go.
> 

Looking a bit closes I can see that the userland context switching
primitives are not there in
/usr/ports/pobj/boost_1_66_0/boost_1_66_0/libs/context/src so that
part is not going to fly. There might be other parts though that are
interesting and make boost-md worthwhile to build for sparc64.

-Otto

Re: [NEW] devel/rebar3

[niamkik]

Hi everyone,

Sorry for the same message. I just updated devel/rebar3 to the last version 
(3.13.2).


‐‐‐ Original Message ‐‐‐
On Sunday, June 7, 2020 6:13 AM, niamkik  wrote:

> Hi everyone,
>
> Please find in attachment the port for rebar3[1] stable version. Here the 
> package description:
>
> Rebar3 is an Erlang tool that makes it easy to create, develop, and
> release Erlang libraries, applications, and systems in a repeatable
> manner.
>
> This package was tested on OpenBSD-6.6, and OpenBSD-current. This package was 
> initially sent to openbsd-wip on github[2].
>
> Regards,
> Mathieu
>
> [1] https://www.rebar3.org/
> [2] https://github.com/jasperla/openbsd-wip/pull/134




rebar3.tar.gz
Description: application/gzip

Re: Making a FreeCAD Port

[Justin Noor]

Thanks for the effort. So basically almost everything is already in ports.
I haven’t decided which package to start with. I should know by today.

A lot of the dependencies in your list are not in FreeCAD’s dependency
list. They must be sub-dependencies, or part of FreeCAD’s modules?

New:
OpenNI2
libspanv
flann
pcl

In Ports:
OpenSCAD
OpenMPI?
orocos_kd1
Netgen
flann
qhul
libusb1
hdf5

Your list:
https://github.com/burne251/freecad-wip/blob/master/README.md

FreeCAD's dependency list:
https://wiki.freecadweb.org/Third_Party_Libraries



On Sat, Jun 6, 2020 at 6:43 PM Charlie Burnett  wrote:

> Here's the link,  let me know
> if there's a specific package you're working on so I avoid it!
> On 2020-06-06 8:26 AM, Justin Noor wrote:
>
> Stuart are referring to this WIP here?
> https://github.com/jasperla/openbsd-wip/tree/master/cad/freecad
>
>
> Paco your WIP seems like a better building block
> https://git.e1e0.net/openbsd-wip/
>
>
> Charlie which dependencies have you built so far? Do you have a WIP repo as
> well?
>
>
>
> On Fri, Jun 5, 2020 at 4:04 AM Stuart Henderson  
>  wrote:
>
>
> On 2020/06/04 21:04, Justin Noor wrote:
>
> Hi @ports,
>
> Is there anyone working on FreeCAD? It's not in /usr/ports/cad, and I
> searched the mailing list and did not find anything fruitful. If not,
>
> would
>
> like to give it a shot if possible - this would be my first port. If
>
> there
>
> is anyone working on it, please let me know how I can contribute.
>
> Thank you
>
> I haven't seen any indication that anyone's working on it. There is
> a first attempt in openbsd-wip but it's nowhere near a working port
> (just downloads the distfile and runs cmake which then fails due to
> lack of dependencies) and hasn't been touched after the initial
> addition in 2015.
>
> The starting point is to map out what's needed with the dependencies.
> There's a list at https://wiki.freecadweb.org/Third_Party_Libraries
> which is hopefully up-to-date enough to be useful. Some are available
> in ports already (pkglocate will help find them) - may be a suitable
> version already or may need updating. Others (including OpenCASCADE,
> Coin3d, PySide) will need porting first (and some of these will have
> their own chain of dependencies).
>
>
>
>

Re: [new] databases/pgtap (and databases/p5-TAP-Parser-SourceHandler-pgTAP dep)

[Landry Breuil]

On Tue, Jun 02, 2020 at 06:24:41PM -0400, Chris Bennett wrote:
> On Sat, May 23, 2020 at 10:46:00AM +0200, Landry Breuil wrote:
> > Hi,
> > 
> Looking over pgtap. I am seeing some strange (to me) issues.
> 
> It uses gmake and it's a perl port.
> It comes with the Perl Makefile already built. Never seen that yet.

Well you see many crazy things in ports.

> It also wants to pull in files from itself that are already installed
> outside of the ports tree in order to run tests. Otherwise the tests
> stop at:
> ERROR:  could not open extension control file
> "/usr/local/share/postgresql/extension/pgtap.control": No such file or
> directory
> 
> cp pgtap.control to /usr/local/share/postgresql/extension/pgtap.control
> moved things along a little further, so it is looking there.

No need for that - TEST_DEPENDS =${BUILD_PKGPATH} takes care of it.

> The above errors Landry had (and I also had) only occur if pgtap is
> installed first. The ports documentation suggests an easy fix for that
> by setting PGUSER=postgres this way: gmake installcheck PGUSER=postgres

Yeah, but that doesnt work - have you read the testing framework in
postgresql.port.mk ? Setting PGUSER=postgres (or USER!=whoami and then
PGUSER=${USER} in TEST_ENV doesnt help, the db will still belong to
${USER} (because that's how the testing framework work) and afaict the
tests hardcode 'postgres'.

> I tried a variety of configure and modules, but that did not work,
> erroring out almost right away. (cpan, modbuild, perl).
> 
> Looking upstream, this is how they have the Makefile in package and on
> git.

Sorry but i dont really understand what you meant by that - did you try
the port i sent, or that was a port you were working on separately ?

Anyway, besides those annoyances about test user, all other tests works,
and id like to import both ports to move forward with pgrouting - any
oks to import from developers ?

Reattaching ports for convenience.

Thanks for looking.

Landry


pgtap-1.1.0.tgz
Description: application/tar-gz


p5-TAP-Parser-SourceHandler-pgTAP-3.35.tgz
Description: application/tar-gz

[NEW] devel/rebar3

[niamkik]

Hi everyone,

Please find in attachment the port for rebar3[1] stable version. Here the 
package description:

Rebar3 is an Erlang tool that makes it easy to create, develop, and
release Erlang libraries, applications, and systems in a repeatable
manner.

This package was tested on OpenBSD-6.6, and OpenBSD-current. This package was 
initially sent to openbsd-wip on github[2].

Regards,
Mathieu

[1] https://www.rebar3.org/
[2] https://github.com/jasperla/openbsd-wip/pull/134


rebar3.tar.gz
Description: application/gzip

Re: [NEW] lang/mercury

[niamkik]

Hi James,

> A couple issues right off the bat. You don't need a REVISION marker
> since this would be the initial import. It also looks like 20.01.2 was
> release on May 3rd.

Yes, I was working on this port in February/March, so, I forgot to check if a 
new version was available. I corrected it.

> pkg/PLIST seems to be empty, so not sure how this port/pkg would even
> install anything. You also have CONFIGURE_ENV set CC=egcc but don't
> depend on ports gcc anywhere. You might want to look into the COMPILER
> option if you really need to depend on ports gcc.

It seems I send this port in hurry without checking everything. My bad. I give 
you the PLIST file generated for the last release (20.01.2).

Thanks for the review.




mercury.tar.gz
Description: application/gzip

UPDATE sysutils/borgbackup-1.1.13

[Bjorn Ketelaars]

Enclosed a simple diff for updating borgbackup to 1.1.13, which fixes
some small issues. Nothing big or exciting. Changes:
https://github.com/borgbackup/borg/blob/1.1.13/docs/changes.rst#version-1113-2020-06-06

Testing:
- 'make test' runs successful
- Run tested on several machines (all amd64) by creating, restoring and
  pruning backups
- Lightly run tested with its only consumer: sysutils/borgmatic

Comments/OK?


Index: Makefile
===
RCS file: /cvs/ports/sysutils/borgbackup/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- Makefile8 Mar 2020 14:52:29 -   1.33
+++ Makefile7 Jun 2020 05:59:20 -
@@ -2,7 +2,7 @@
 
 COMMENT =  deduplicating backup program
 
-MODPY_EGG_VERSION =1.1.11
+MODPY_EGG_VERSION =1.1.13
 DISTNAME = borgbackup-${MODPY_EGG_VERSION}
 
 CATEGORIES =   sysutils
Index: distinfo
===
RCS file: /cvs/ports/sysutils/borgbackup/distinfo,v
retrieving revision 1.20
diff -u -p -r1.20 distinfo
--- distinfo8 Mar 2020 14:52:29 -   1.20
+++ distinfo7 Jun 2020 05:59:20 -
@@ -1,2 +1,2 @@
-SHA256 (borgbackup-1.1.11.tar.gz) = 
NgkJkrp5WlpQkfzUB7Z76b8m0OiAIIktMdesgfqXD6Q=
-SIZE (borgbackup-1.1.11.tar.gz) = 3718055
+SHA256 (borgbackup-1.1.13.tar.gz) = 
FkqGZqYQcc4vpsYGJ8dkbxLjqOdM048Ea+cvXqkbOCE=
+SIZE (borgbackup-1.1.13.tar.gz) = 3754457