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 

CVS: cvs.openbsd.org: ports

[Bjorn Ketelaars]

CVSROOT:/cvs
Module name:ports
Changes by: b...@cvs.openbsd.org2020/06/07 21:18:15

Modified files:
x11/herbstluftwm: Makefile distinfo 
x11/herbstluftwm/pkg: PLIST 

Log message:
Update to herbstluftwm-0.8.3

This version fixes several bugs, and adds some new commands and rules.
Changes: https://herbstluftwm.org/news.html.

>From Lucas  and
Florian Viehweger  who also take
maintainer.

CVS: cvs.openbsd.org: ports

[Thomas Frohwein]

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2020/06/07 17:33:15

Modified files:
audio/faudio   : Makefile distinfo 

Log message:
update to faudio 20.06; no dynamic export change; changelog: 
https://github.com/FNA-XNA/FAudio/releases

CVS: cvs.openbsd.org: ports

[Thomas Frohwein]

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2020/06/07 17:30:33

Modified files:
devel  : Makefile 

Log message:
+msbuild

CVS: cvs.openbsd.org: ports

[Thomas Frohwein]

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2020/06/07 17:29:33

Modified files:
www: Makefile 

Log message:
+ipynb-py-convert

CVS: cvs.openbsd.org: ports

[Thomas Frohwein]

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2020/06/07 17:28:15

Log message:
import msbuild

ok bket@

DESCR:
The Microsoft Build Engine is a platform for building applications. This 
engine,
which is also known as MSBuild, provides an XML schema for a project file 
that
controls how the build platform processes and builds software. Visual Studio
uses MSBuild, but MSBuild does not depend on Visual Studio. By invoking
msbuild.exe on your project or solution file, you can orchestrate and build
products in environments where Visual Studio isn't installed.

Status:

Vendor Tag: thfr
Release Tags:   thfr_20200607

N ports/devel/msbuild/Makefile
N ports/devel/msbuild/distinfo
N ports/devel/msbuild/patches/patch-build_build_sh
N ports/devel/msbuild/patches/patch-install-mono-prefix_sh
N ports/devel/msbuild/patches/patch-mono_build_install_proj
N 
ports/devel/msbuild/patches/patch-src_Build_OM_UnitTests_Definition_ProjectCollection_Tests_cs
N ports/devel/msbuild/pkg/DESCR
N ports/devel/msbuild/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Thomas Frohwein]

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2020/06/07 17:24:57

Log message:
import ipynb-py-convert

with additions and oks from bket@ and rsadowski@

DESCR:
Atom/Hydrogen or VSCode/Python allows creating a python files split into 
cells
with # %% separators with the ability to run cells via backend Jupyter 
session
and interactively show results back. ipynb-py-convert python module converts
files: .ipynb to .py and .py to .ipynb.

This can assist in version controlling ipynb projects, as .py doesn't 
include
output data.

Status:

Vendor Tag: thfr
Release Tags:   thfr_20200607

N ports/www/ipynb-py-convert/Makefile
N ports/www/ipynb-py-convert/distinfo
N ports/www/ipynb-py-convert/pkg/DESCR
N ports/www/ipynb-py-convert/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Kirill Bychkov]

CVSROOT:/cvs
Module name:ports
Changes by: ki...@cvs.openbsd.org   2020/06/07 15:25:24

Modified files:
net/seafile/client: Makefile distinfo 
net/seafile/seafile: Makefile distinfo 

Log message:
update to seafile-7.0.8

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 

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 

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
 
 

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 10:08:17

Modified files:
x11/gtk+3  : Makefile 

Log message:
Newer version require pango>=1.45

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 10:02:49

Modified files:
x11/virt-viewer: Makefile 

Log message:
Regen WANTLIB after recent sysutils/libvirt update.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 10:01:39

Modified files:
sysutils/virt-manager: Makefile distinfo 
sysutils/virt-manager/patches: patch-setup_py 
sysutils/virt-manager/pkg: PLIST 
Added files:
sysutils/virt-manager/patches: patch-virtinst_buildconfig_py 
Removed files:
sysutils/virt-manager/patches: patch-virtcli_cliconfig_py 

Log message:
Update to virt-manager-2.2.1 but mark BROKEN for now because it needs
py3-libxml2 (textproc/libxml,python${MODPY_FLAVOR}) which we don't provide.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 10:00:16

Modified files:
devel/quirks   : Makefile 
devel/quirks/files: Quirks.pm 

Log message:
'py-libvirt' => 'py3-libvirt'

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 10:00:04

Modified files:
sysutils/ruby-libvirt: Makefile 

Log message:
Regen WANTLIB.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 09:59:49

Modified files:
sysutils/p5-Sys-Virt: Makefile distinfo 
sysutils/p5-Sys-Virt/pkg: PLIST 
Removed files:
sysutils/p5-Sys-Virt/patches: patch-perl-Sys-Virt_spec_PL 

Log message:
Update to p5-Sys-Virt-6.3.0.
Take maintainer.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 09:59:18

Modified files:
sysutils/libvirt-python: Makefile distinfo 
sysutils/libvirt-python/pkg: PLIST 

Log message:
Update to version 6.4.0 and move to python3.
Not sure why MODPY_TEST_TARGET doesn't work anymore and needs
TEST_TARGET appended but the python MODULE is black magic...

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 09:57:49

Modified files:
sysutils/collectd: Makefile 

Log message:
Regen WANTLIB.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 09:57:11

Modified files:
sysutils/libvirt: Makefile distinfo 
sysutils/libvirt/patches: patch-src_remote_remote_driver_h 
  patch-src_rpc_virnettlscontext_c 
sysutils/libvirt/pkg: PLIST 
Added files:
sysutils/libvirt/patches: patch-configure 
Removed files:
sysutils/libvirt/patches: patch-src_Makefile_in 

Log message:
Major update to libvirt-6.4.0.
Committing early in the release cycle to catch regressions.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 09:57:34

Modified files:
devel/libvirt-glib: Makefile 

Log message:
Regen WANTLIB after recent sysutils/libvirt update.

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/06/07 09:56:09

Modified files:
x11/kde-applications/minuet: Makefile 

Log message:
Remove multimedia/phonon as dependency

CVS: cvs.openbsd.org: ports

[Aaron Bieber]

CVSROOT:/cvs
Module name:ports
Changes by: abie...@cvs.openbsd.org 2020/06/07 09:36:11

Modified files:
net/go-ipfs: Makefile distinfo 
net/go-ipfs/pkg: PLIST 
Removed files:
net/go-ipfs/patches: 
 patch-vendor_golang_org_x_xerrors_adaptor_go 
 
patch-vendor_golang_org_x_xerrors_adaptor_go1_12_go 
 
patch-vendor_golang_org_x_xerrors_adaptor_go1_13_go 
 patch-vendor_golang_org_x_xerrors_format_go 
 patch-vendor_golang_org_x_xerrors_format_go1_12_go 
 patch-vendor_golang_org_x_xerrors_format_go1_13_go 
 patch-vendor_golang_org_x_xerrors_frame_go 
 patch-vendor_golang_org_x_xerrors_frame_go1_12_go 

Log message:
Update go-ipfs to 0.5.1

- Switch to MODGO_MODNAME.
- Updates the license (now Apache 2 + MIT)
- Adds me as maintainer.
- Remove patches.
- Include ipfswatch / seccat.

OK and fixes from kn@

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}

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/06/07 08:49:59

Modified files:
x11/kde-applications/kolf: Makefile 

Log message:
Remove multimedia/phonon as dependency

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

CVS: cvs.openbsd.org: ports

[Bjorn Ketelaars]

CVSROOT:/cvs
Module name:ports
Changes by: b...@cvs.openbsd.org2020/06/07 07:28:25

Modified files:
sysutils/borgbackup: Makefile distinfo 

Log message:
Update to borgbackup-1.1.13

Changes:
https://github.com/borgbackup/borg/blob/1.1.13/docs/changes.rst#version-1113-2020-06-06

OK sthen@

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.
> > >
>
>
>

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/06/07 06:55:00

Modified files:
graphics/clutter/cogl: Makefile distinfo 

Log message:
update to cogl-1.22.8

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.

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/06/07 06:41:09

Modified files:
sysutils/borgmatic: Makefile distinfo 

Log message:
update to borgmatic-1.5.6

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

CVS: cvs.openbsd.org: ports

[Klemens Nanni]

CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2020/06/07 06:03:44

Modified files:
devel/boost: Makefile 

Log message:
Build boost-md on sparc64

OK rsadwoski
"go ahead" plus comment fix from Brad

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

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/06/07 05:41:05

Modified files:
games/tuxpaint : Makefile 
games/tuxpaint/patches: patch-Makefile 
games/tuxpaint/pkg: PLIST 

Log message:
Unbreak packaging and add missing files.
Add DEBUG_PACKAGES.

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).
>
>
>
>

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/06/07 05:25:31

Modified files:
www/minitube   : Makefile 

Log message:
Remove multimedia/phonon module

Phonon support is long gone
https://github.com/flaviotordini/minitube/commit/2bfc0dee3820a66d3107f678ead969f8fb257efd

CVS: cvs.openbsd.org: ports

[Martin Reindl]

CVSROOT:/cvs
Module name:ports
Changes by: mar...@cvs.openbsd.org  2020/06/07 05:26:07

Modified files:
archivers/blosc: Makefile distinfo 

Log message:
Update c-blosc to 1.19.0.

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/06/07 05:22:37

Log message:
import ports/net/termshark, ok landry@

Termshark is a terminal UI for tshark, inspired by Wireshark.

- Read pcap files or sniff live interfaces
- Use Wireshark's display filters
- Reassemble TCP and UDP streams
- View conversations by protocol

Status:

Vendor Tag: sthen
Release Tags:   sthen_20200607

N ports/net/termshark/Makefile
N ports/net/termshark/distinfo
N ports/net/termshark/pkg/DESCR
N ports/net/termshark/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/06/07 05:23:03

Modified files:
net: Makefile 

Log message:
+termshark

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

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2020/06/07 03:36:15

Modified files:
devel/py-buildbot: Makefile.inc 
devel/py-buildbot/buildbot: distinfo 
devel/py-buildbot/buildbot/pkg: PLIST 
devel/py-buildbot/console-view: distinfo 
devel/py-buildbot/grid-view: distinfo 
devel/py-buildbot/pkg: distinfo 
devel/py-buildbot/waterfall-view: distinfo 
devel/py-buildbot/www: distinfo 
devel/py-buildslave: Makefile distinfo 

Log message:
Update to buildbot/buildslave 2.8.1

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/06/07 03:05:24

Modified files:
textproc   : Makefile 

Log message:
+codesearch

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

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/06/07 02:06:42

Log message:
import textproc/codesearch, ok semarie@

Code Search is a tool for indexing and then performing regular
expression searches over large bodies of source code. It is a set of
command-line programs written in Go.

For background and an overview of the commands, see
http://swtch.com/~rsc/regexp/regexp4.html.

Status:

Vendor Tag: sthen
Release Tags:   sthen_20200607

N ports/textproc/codesearch/Makefile
N ports/textproc/codesearch/distinfo
N ports/textproc/codesearch/pkg/DESCR
N ports/textproc/codesearch/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/06/07 02:05:42

Modified files:
security/minisign: Makefile distinfo 

Log message:
update to minisign-0.9

Re: boost-md: build on sparc64

[Otto Moerbeek]

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.

-Otto


> > 
> > On 2020/06/06 01:54, Brad Smith wrote:
> > > On 6/6/2020 1:32 AM, Rafael Sadowski wrote:
> > > 
> > > > On Fri Jun 05, 2020 at 11:55:21PM +0200, Klemens Nanni wrote:
> > > > > I thought I had already sent out (or even committed) this diff...
> > > > > 
> > > > > For another WIP port, boost-md is required is required.
> > > > > I've been building and linking against it just fine on sparc64.
> > > > > 
> > > > > OK?
> > > > If it works on sparc64, sure!
> > > 
> > > I was under the impression that this did not build with there being some
> > > missing MD code, but if it does then go ahead.
> >  
> > 
>