CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/08/03 23:11:07

Modified files:
net/znc: Makefile distinfo 
net/znc/pkg: PLIST 

Log message:
SECURITY update to znc-1.7.1.
CVE-2018-14055, CVE-2018-14056

from Brad (maintainer)

Re: Qt5Webkit -> USE_WXNEEDED

[Antoine Jacoutot]

On Fri, Aug 03, 2018 at 10:55:55PM +0100, Stuart Henderson wrote:
> On 2018/08/03 21:39, Antoine Jacoutot wrote:
> > On Fri, Aug 03, 2018 at 10:56:06AM +0100, Stuart Henderson wrote:
> > > On 2018/08/03 10:34, Vadim Zhukov wrote:
> > > > чт, 2 авг. 2018 г. в 12:40, Stuart Henderson :
> > > > >
> > > > > On 2018/08/02 07:17, Rafael Sadowski wrote:
> > > > > > If no concerns I would like to commit the patch.
> > > > >
> > > > > I'm a bit confused about this because:
> > > > >
> > > > > 1. we have a patch described as "Enable W^X in QtWebkit's JIT"
> > > > > in x11/qt5/qtwebkit/patches/patch-Source_JavaScriptCore_jsc_pro
> > > > 
> > > > Unfortunately, it QtWebKit still crashes due to W^X violations, even
> > > > with those patches. And there's really no point in polishing it
> > > > nowadays, it's community-maintained (read: it gets only very minor
> > > > updates to make it build work with newer Qt versions, as nobody in
> > > > good mind is willing/able to fully maintain it).
> > > > 
> > > > Yes, you don't want to run QtWebkit-based browsers for real.
> > > 
> > > So, OK for the USE_WXNEEDED diff, but I think it might be better to do
> > > the following to reduce the chance of running into more cases where it's
> > > missing:
> > > 
> > > - have portcheck complain if webkit is listed in WANTLIB and USE_WXNEEDED
> > > is not set
> > 
> > Hmm. I don't like that approach.
> > Most ports with webkit in WANTLIB work just fine without having USE_WXNEEDED
> > set.
> 
> Only because of the cmake/pkg-config hacks though, and it's partly for
> self-documentation besides actually changing the build, this way you
> can just do 'select fullpkgpath from ports where use_wxneeded=1' to find
> them.

Don't forget overlinking. We probably have some webkit WANTLIBs that are because
of an dependency of the port that itself depends on webkit.
Also not every port use cmake :-)

Unless you are talking about qtwebkit specifically.

> OTOH I'd probably feel differently if I maintained a bunch of ports using
> webkit, so...
> 

-- 
Antoine

Re: Qt5Webkit -> USE_WXNEEDED

[Stuart Henderson]

On 2018/08/03 21:39, Antoine Jacoutot wrote:
> On Fri, Aug 03, 2018 at 10:56:06AM +0100, Stuart Henderson wrote:
> > On 2018/08/03 10:34, Vadim Zhukov wrote:
> > > чт, 2 авг. 2018 г. в 12:40, Stuart Henderson :
> > > >
> > > > On 2018/08/02 07:17, Rafael Sadowski wrote:
> > > > > If no concerns I would like to commit the patch.
> > > >
> > > > I'm a bit confused about this because:
> > > >
> > > > 1. we have a patch described as "Enable W^X in QtWebkit's JIT"
> > > > in x11/qt5/qtwebkit/patches/patch-Source_JavaScriptCore_jsc_pro
> > > 
> > > Unfortunately, it QtWebKit still crashes due to W^X violations, even
> > > with those patches. And there's really no point in polishing it
> > > nowadays, it's community-maintained (read: it gets only very minor
> > > updates to make it build work with newer Qt versions, as nobody in
> > > good mind is willing/able to fully maintain it).
> > > 
> > > Yes, you don't want to run QtWebkit-based browsers for real.
> > 
> > So, OK for the USE_WXNEEDED diff, but I think it might be better to do
> > the following to reduce the chance of running into more cases where it's
> > missing:
> > 
> > - have portcheck complain if webkit is listed in WANTLIB and USE_WXNEEDED
> > is not set
> 
> Hmm. I don't like that approach.
> Most ports with webkit in WANTLIB work just fine without having USE_WXNEEDED
> set.

Only because of the cmake/pkg-config hacks though, and it's partly for
self-documentation besides actually changing the build, this way you
can just do 'select fullpkgpath from ports where use_wxneeded=1' to find
them.

OTOH I'd probably feel differently if I maintained a bunch of ports using
webkit, so...

Re: security update: www/cgit 1.1 to 1.2.1

[Klemens Nanni]

Typo in the subject, sorry.

security update: www/git 1.1 to 1.2.1

[Klemens Nanni]

1.2.1 fixes a directory traversal bug:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1627

While here:

* in README refer to an installed manual page instead of the
online version
* use simpler and AF agnostic httpd.conf(5) syntax in our example

I'd be happy to hear feedback from regular cgit users.

Index: Makefile
===
RCS file: /cvs/ports/www/cgit/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile5 Jan 2018 08:31:26 -   1.23
+++ Makefile3 Aug 2018 20:32:26 -
@@ -2,12 +2,11 @@
 
 COMMENT =  web frontend for git repositories
 
-DISTNAME = cgit-1.1
+DISTNAME = cgit-1.2.1
 CATEGORIES =   www devel
-REVISION = 0
 
-DISTFILES =${DISTNAME}.tar.gz:0 \
-   git-2.10.2.tar.gz:1
+DISTFILES =${DISTNAME}.tar.xz:0 \
+   git-2.18.0.tar.gz:1
 
 MASTER_SITES0 =https://git.zx2c4.com/cgit/snapshot/
 MASTER_SITES1 =https://www.kernel.org/pub/software/scm/git/
Index: distinfo
===
RCS file: /cvs/ports/www/cgit/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- distinfo22 Mar 2017 20:23:52 -  1.11
+++ distinfo3 Aug 2018 20:32:37 -
@@ -1,4 +1,4 @@
-SHA256 (cgit-1.1.tar.gz) = 9A3soz5VbJohi73Ce9nEd62ZxwhjkjCWhtIWkB3RDTs=
-SHA256 (git-2.10.2.tar.gz) = PX7yddgLl6qmHztr6dPcUWIC5vb12IXywJtZ66WS3MQ=
-SIZE (cgit-1.1.tar.gz) = 105738
-SIZE (git-2.10.2.tar.gz) = 6065116
+SHA256 (cgit-1.2.1.tar.xz) = PFR8FGNA+xbUE0Mm51JL+yj/poEoTx45FL3hwnqRgr8=
+SHA256 (git-2.18.0.tar.gz) = lPrywLAqeSCwtG9JYdjpytCOgUGGFBAomKVfmA+j5+Q=
+SIZE (cgit-1.2.1.tar.xz) = 89648
+SIZE (git-2.18.0.tar.gz) = 7498807
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/www/cgit/patches/patch-Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 patch-Makefile
--- patches/patch-Makefile  22 Mar 2017 20:23:52 -  1.8
+++ patches/patch-Makefile  3 Aug 2018 20:10:00 -
@@ -1,9 +1,10 @@
 $OpenBSD: patch-Makefile,v 1.8 2017/03/22 20:23:52 landry Exp $
 Makefile.orig  Thu Feb 23 10:40:08 2017
-+++ Makefile   Thu Feb 23 10:42:15 2017
+Index: Makefile
+--- Makefile.orig
 Makefile
 @@ -2,11 +2,11 @@ all::
  
- CGIT_VERSION = v1.1
+ CGIT_VERSION = v1.2.1
  CGIT_SCRIPT_NAME = cgit.cgi
 -CGIT_SCRIPT_PATH = /var/www/htdocs/cgit
 -CGIT_DATA_PATH = $(CGIT_SCRIPT_PATH)
@@ -18,7 +19,7 @@ $OpenBSD: patch-Makefile,v 1.8 2017/03/2
  libdir = $(prefix)/lib
  filterdir = $(libdir)/cgit/filters
  docdir = $(prefix)/share/doc/cgit
-@@ -84,8 +84,6 @@ install: all
+@@ -90,8 +90,6 @@ install: all
$(INSTALL) -m 0644 cgit.png $(DESTDIR)$(CGIT_DATA_PATH)/cgit.png
$(INSTALL) -m 0644 favicon.ico $(DESTDIR)$(CGIT_DATA_PATH)/favicon.ico
$(INSTALL) -m 0644 robots.txt $(DESTDIR)$(CGIT_DATA_PATH)/robots.txt
Index: patches/patch-filter_c
===
RCS file: /cvs/ports/www/cgit/patches/patch-filter_c,v
retrieving revision 1.2
diff -u -p -r1.2 patch-filter_c
--- patches/patch-filter_c  14 Jan 2016 22:09:15 -  1.2
+++ patches/patch-filter_c  3 Aug 2018 20:10:00 -
@@ -1,8 +1,9 @@
 $OpenBSD: patch-filter_c,v 1.2 2016/01/14 22:09:15 sthen Exp $
 Wtf.
 filter.c.orig  Thu Jan 14 14:43:54 2016
-+++ filter.c   Thu Jan 14 14:53:04 2016
-@@ -148,12 +148,13 @@ static struct cgit_filter *current_write_filter = NULL
+Index: filter.c
+--- filter.c.orig
 filter.c
+@@ -149,12 +149,13 @@ static struct cgit_filter *current_write_filter = NULL
  
  void cgit_init_filters(void)
  {
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/cgit/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST   5 Jan 2018 08:31:26 -   1.4
+++ pkg/PLIST   3 Aug 2018 20:35:53 -
@@ -8,5 +8,5 @@ cgit/cgit.png
 cgit/favicon.ico
 cgit/robots.txt
 @cwd ${LOCALBASE}
-share/doc/pkg-readmes/${FULLPKGNAME}
 @man man/man5/cgitrc.5
+share/doc/pkg-readmes/${FULLPKGNAME}
Index: pkg/README
===
RCS file: /cvs/ports/www/cgit/pkg/README,v
retrieving revision 1.3
diff -u -p -r1.3 README
--- pkg/README  22 Mar 2017 20:23:52 -  1.3
+++ pkg/README  3 Aug 2018 20:38:56 -
@@ -7,16 +7,15 @@ $OpenBSD: README,v 1.3 2017/03/22 20:23:
 Cgit config
 ===
 By default, the cgitrc config file is searched in ${PREFIX}/conf/cgitrc.
-Refer to http://git.zx2c4.com/cgit/tree/cgitrc.5.txt for the syntax.
+Refer to cgitrc(5) for the syntax.
 
 Webserver config
 
 
 OpenBSD httpd
 -
-ext_ip="0.0.0.0"
 server "default" {
-   listen on $ext_ip port 80
+   listen on egress port 80
 
# don't serve static files from cgit CGI: cgit.css and cgit.png
location "/cgit.*" {

Re: Qt5Webkit -> USE_WXNEEDED

[Antoine Jacoutot]

On Fri, Aug 03, 2018 at 10:56:06AM +0100, Stuart Henderson wrote:
> On 2018/08/03 10:34, Vadim Zhukov wrote:
> > чт, 2 авг. 2018 г. в 12:40, Stuart Henderson :
> > >
> > > On 2018/08/02 07:17, Rafael Sadowski wrote:
> > > > If no concerns I would like to commit the patch.
> > >
> > > I'm a bit confused about this because:
> > >
> > > 1. we have a patch described as "Enable W^X in QtWebkit's JIT"
> > > in x11/qt5/qtwebkit/patches/patch-Source_JavaScriptCore_jsc_pro
> > 
> > Unfortunately, it QtWebKit still crashes due to W^X violations, even
> > with those patches. And there's really no point in polishing it
> > nowadays, it's community-maintained (read: it gets only very minor
> > updates to make it build work with newer Qt versions, as nobody in
> > good mind is willing/able to fully maintain it).
> > 
> > Yes, you don't want to run QtWebkit-based browsers for real.
> 
> So, OK for the USE_WXNEEDED diff, but I think it might be better to do
> the following to reduce the chance of running into more cases where it's
> missing:
> 
> - have portcheck complain if webkit is listed in WANTLIB and USE_WXNEEDED
> is not set

Hmm. I don't like that approach.
Most ports with webkit in WANTLIB work just fine without having USE_WXNEEDED
set.

> - possibly remove the hack from cmake?


-- 
Antoine

Re: [NEW] gzdoom-3.5.0

[lea.chescotta]

Yes i experience the same slow starting even when i compiled from source 
without the port, its something i didnt encounter in linux or windows using 
gzdoom, theres something related to openbsd that is causing it, but right now i 
dont have my openbsd install :(


3. Ago 2018 15:03 por sol...@perso.pw :


> timo.my...@bittivirhe.fi >  (Timo Myyrä) 
> wrote:
>> timo.my...@bittivirhe.fi >>  (Timo Myyrä) 
>> writes:
>>
>> > Solene Rapenne <>> sol...@perso.pw >> > writes:
>> >
>> >> >> timo.my...@bittivirhe.fi >>  (Timo 
>> >> >> Myyrä) wrote:
>> >>
>> >>> Hi,
>> >>> 
>> >>> Here's a updated port for latest gzdoom version.
>> >>> Merged the stuff from Solene's port into my old gzdoom port and bumped 
>> >>> it to
>> >>> latest version. Tested on amd64 and quick gameplay test seems to work and
>> >>> installing soundfont and tuning the ini file, the fluidsynth playback 
>> >>> works.
>> >>> 
>> >>> - added patch to fix the fluidsynth library name
>> >>> 
>> >>> - dropped old linker args from Makefile, these don't seem to be needed 
>> >>> at all
>> >>> 
>> >>> - Added flag to disable GTK dialogs from building so no need for Gtk 
>> >>> dependency
>> >>> 
>> >>> - fluidsynth is detected at build time so add it as build_depends. At 
>> >>> run time
>> >>>   it needs to be installed but gzdoom can use other midi players as well 
>> >>> so I
>> >>>   didn't add it to run_depends. 
>> >>> 
>> >>> - Dropped previous gxmessage dependy, the game tries kdialog, gxmessage 
>> >>> and
>> >>>   finally xmessage to show crash log.
>> >>> 
>> >>> - OpenAL needs to be installed to have audio.
>> >>> 
>> >>> 
>> >>> Timo
>> >>
>> >> Your port is way better than the one I submitted last month, good work! 
>> >> Still
>> >> when using mods, I only have music and no other sound, do you have the 
>> >> same
>> >> issue? Doom1 and Doom2 runs fine, so it may be related to the mods...
>> >
>> > I tested Doom One mod and only got sound in menu and no gameplay sounds or 
>> > music
>> > at all. Got bunch of errors in console so I guess the mods are to blame.
>> >
>> > Timo
>>
>> Actually its the problem in library loading. There was wrong library names 
>> for
>> libmpg123, libsndfile in the code. I've patched those and the sounds seem to
>> work now after quick test.
>>
>> Updated port attached.
>>
>> timo
>
> Indeed this fixed the sound issue in at least one mod for me. I wonder
> if you also experience a very slow startup?
>
> ok for import

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2018/08/03 12:24:10

Modified files:
net/icinga/web2: Makefile distinfo 

Log message:
update to icinga-web2-2.6.1

Re: [NEW] gzdoom-3.5.0

[Solene Rapenne]

timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
> timo.my...@bittivirhe.fi (Timo Myyrä) writes:
> 
> > Solene Rapenne  writes:
> >
> >> timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
> >>
> >>> Hi,
> >>> 
> >>> Here's a updated port for latest gzdoom version.
> >>> Merged the stuff from Solene's port into my old gzdoom port and bumped it 
> >>> to
> >>> latest version. Tested on amd64 and quick gameplay test seems to work and
> >>> installing soundfont and tuning the ini file, the fluidsynth playback 
> >>> works.
> >>> 
> >>> - added patch to fix the fluidsynth library name
> >>> 
> >>> - dropped old linker args from Makefile, these don't seem to be needed at 
> >>> all
> >>> 
> >>> - Added flag to disable GTK dialogs from building so no need for Gtk 
> >>> dependency
> >>> 
> >>> - fluidsynth is detected at build time so add it as build_depends. At run 
> >>> time
> >>>   it needs to be installed but gzdoom can use other midi players as well 
> >>> so I
> >>>   didn't add it to run_depends. 
> >>> 
> >>> - Dropped previous gxmessage dependy, the game tries kdialog, gxmessage 
> >>> and
> >>>   finally xmessage to show crash log.
> >>> 
> >>> - OpenAL needs to be installed to have audio.
> >>> 
> >>> 
> >>> Timo
> >>
> >> Your port is way better than the one I submitted last month, good work! 
> >> Still
> >> when using mods, I only have music and no other sound, do you have the same
> >> issue? Doom1 and Doom2 runs fine, so it may be related to the mods...
> >
> > I tested Doom One mod and only got sound in menu and no gameplay sounds or 
> > music
> > at all. Got bunch of errors in console so I guess the mods are to blame.
> >
> > Timo
> 
> Actually its the problem in library loading. There was wrong library names for
> libmpg123, libsndfile in the code. I've patched those and the sounds seem to
> work now after quick test.
> 
> Updated port attached.
> 
> timo

Indeed this fixed the sound issue in at least one mod for me. I wonder
if you also experience a very slow startup?

ok for import

Re: [NEW/WIP] Qflow porting // [2/7] Yosys

[Alessandro DE LAURENZIS]

Hi Stuart,

On 08/03/18 13:21, Stuart Henderson wrote:


On 2018/08/03 12:23, Alessandro DE LAURENZIS wrote:

I think we need the line:

FAKE_FLAGS =PREFIX="${LOCALBASE}"

since PREFIX is explicitly set to /usr/local in upstream Makefile when
undefined.


That should probably be PREFIX="${TRUEPREFIX}"


Fixed



Finally, portcheck gives the following message:

Python module without compiled version, consider using ${MODPY_BIN}
${MODPY_LIBDIR}/compileall.py: share/yosys/python3/smtio.py
cad/yosys

I don't know if it's acceptable (and, if not, how to remove it...)


Python normally creates pyc files for imported modules if the directory
is writable. We pre-create these so that if e.g. someone runs the program
as root, we don't get stray pyc files left behind after uninstall.
You can remove it by using ${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py
to create the pyc file.


Added it in post-install target:

post-install:
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py \
${PREFIX}/share/yosys/python3



- compiler name forced to eg++;


Don't hardcode this, use MAKE_FLAGS= CXX="${CXX}" etc.


Fixed



Different story for kernel/yosys.cc:
- we need to include sys/wait.h;
- code requires the process executable base path; Linux has /proc/self/exe
and I see that there are solutions for APPLE and WIN32 too; OpenBSD doesn't
have a ready-to-use function; this is the closest thing that comes to my
mind:

std::string proc_self_dirname()
{
 // No direct way to get the process executable base path
char path[PATH_MAX];
ssize_t buflen = sizeof(path);
 char *res = realpath(getenv("_"), path);
 if (!res) {
log_error("getenv(\"_\") failed: %s\n",strerror(errno));
 }
*(strrchr(path, '/')+1) = '\0';
while (buflen > 0 && path[buflen-1] != '/')
buflen--;
return std::string(path, buflen);
}

If you think that's acceptable, I'll submit the patch upstream.


IMO hardcoding the path is the most sensible way for ports.


As discussed (thanks for your explanation), I patched to use ${PREFIX} 
and then added:


pre-build:
${SUBST_CMD} ${WRKSRC}/kernel/yosys.cc



pdflatex is used to compile manual, application notes and presentations
during build; it's part of print/texlive_base, which is a large port; should
we stay with it or do you have alternatives to suggest?


That's not really a problem. If it needs pdflatex, list the dependency.
>> pdflatex is used to compile manual, application notes and presentations

during build; it's part of print/texlive_base, which is a large port; should
we stay with it or do you have alternatives to suggest?


That's not really a problem. If it needs pdflatex, list the dependency.


Actually I noticed that the corresponding target isn't run by default. 
Should I force it? I mean, is the extra documentation normally installed 
in other ports?


New tarball attached.

--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis


yosys.tar.gz
Description: application/gzip

CVS: cvs.openbsd.org: ports

[Ingo Feinerer]

CVSROOT:/cvs
Module name:ports
Changes by: feine...@cvs.openbsd.org2018/08/03 06:20:06

Modified files:
telephony/baresip/baresip: Makefile distinfo 
telephony/baresip/baresip/patches: patch-modules_zrtp_module_mk 
   patch-src_config_c 
telephony/baresip/baresip/pkg: PLIST-main 

Log message:
Update to baresip 0.5.10

Re: [NEW/WIP] Qflow porting // [2/7] Yosys

[Stuart Henderson]

On 2018/08/03 13:57, Alessandro DE LAURENZIS wrote:
> Hi Stuart,
> 
> On 08/03/18 13:21, Stuart Henderson wrote:
> > > std::string proc_self_dirname()
> > > {
> > >  // No direct way to get the process executable base path
> > >   char path[PATH_MAX];
> > >   ssize_t buflen = sizeof(path);
> > >  char *res = realpath(getenv("_"), path);
> > >  if (!res) {
> > >   log_error("getenv(\"_\") failed: %s\n",strerror(errno));
> > >  }
> > >   *(strrchr(path, '/')+1) = '\0';
> > >   while (buflen > 0 && path[buflen-1] != '/')
> > >   buflen--;
> > >   return std::string(path, buflen);
> > > }
> > > 
> > > If you think that's acceptable, I'll submit the patch upstream.
> > IMO hardcoding the path is the most sensible way for ports.
> > 
> 
> Do you mean something like this?
> 
> std::string proc_self_dirname()
> {
>   return "/usr/local/bin/";
> }
> 
> How does it play with a different $LOCALBASE?
> 
> -- 
> Alessandro DE LAURENZIS
> [mailto:jus...@atlantide.t28.net]
> Web: http://www.atlantide.t28.net
> LinkedIn: http://it.linkedin.com/in/delaurenzis
> 

Either patch to use ${PREFIX} and use ${SUBST_CMD} on the file
after patching, or use /usr/local and "sed -i s,/usr/local,${PREFIX},"

(PREFIX relates to "where this port installs", LOCALBASE relates to
"where other ports on the system are found").

Re: [NEW/WIP] Qflow porting // [2/7] Yosys

[Alessandro DE LAURENZIS]

Hi Stuart,

On 08/03/18 13:21, Stuart Henderson wrote:

std::string proc_self_dirname()
{
 // No direct way to get the process executable base path
char path[PATH_MAX];
ssize_t buflen = sizeof(path);
 char *res = realpath(getenv("_"), path);
 if (!res) {
log_error("getenv(\"_\") failed: %s\n",strerror(errno));
 }
*(strrchr(path, '/')+1) = '\0';
while (buflen > 0 && path[buflen-1] != '/')
buflen--;
return std::string(path, buflen);
}

If you think that's acceptable, I'll submit the patch upstream.

IMO hardcoding the path is the most sensible way for ports.



Do you mean something like this?

std::string proc_self_dirname()
{
return "/usr/local/bin/";
}

How does it play with a different $LOCALBASE?

--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis

Re: [update] editors/neovim 0.3.1

[Landry Breuil]

On Fri, Aug 03, 2018 at 11:04:10AM +0100, Edd Barrett wrote:
> Hi Jon,
> 
> On Sat, Jul 28, 2018 at 02:44:44PM -0400, Jon Bernard wrote:
> > Hello,
> > 
> > Here is an update to neovim for version 0.3.1.  The new release contains
> > mostly bugfixes and nothing major.  As such, the diff is just a version
> > bump and everything else remains the same.
> > 
> > OK?
> 
> This looks good.
> 
> One small item, after running 'make update-plist' i see that there are
> some new Japanese manuals included.
> 
> +man/ja_JP.EUC/cat3f/
> +man/ja_JP.EUC/man3f/
> +man/ja_JP.EUC/man3p/
> 
> Do we want to include those? If not, we want to @comment those lines.

You system is not up to date, this is related to the fake.mtree changes.

Re: [PATCH] sysutils/screenfetch

[Charlène]

Hi, 

On Thu, 2 Aug 2018 18:07:33 -0400
Brian Callahan wrote:

> Hi Charlène --
> 
> On 08/01/18 16:06, Charlène wrote:
> > Hi,
> >
> > I'm joining a new diff after Brian's comments.
> >
> > On Wed, 1 Aug 2018 02:17:37 -0400
> > Brian Callahan wrote:
> >
> >> Hi Charlène --
> >>
> >> On 07/30/18 14:22, Charlène wrote:
> >>> Hi,
> >>>
> >>> I'm proposing several changes to this port:
> >>>
> >>> Makefile:
> >>>   
> >>>   * cleaned extra tabs after '='
> >>>   * use INSTALL_MAN instead of INSTALL_SCRIPT for the
> >>> manpage
> >>>   * added myself as MAINTAINER, currently it's "orphaned"
> >>>   * incremented REVISION
> >>>   * added braces for variables
> >> Some of these I'm OK with, some I'm not super sure about.
> >> Yes, I think it's worthwhile to use INSTALL_MAN.
> >> Glad to see you taking MAINTAINER.
> >> Glad to see the updated patches.
> >>
> >> Braces around variables are not strictly needed in this case; it
> >> becomes a matter of style in this particular instance. But it might
> >> be even better to change PKGNAME to ${DISTNAME:L} and change
> >> GH_TAGNAME to v3.8.0 -- that would completely eliminate the need
> >> for a V variable in the first place.
> > I changed to what you recommend. You made me finally understand
> > that bsd.port.mk is a great source of documentation by itself,
> > thanks!
> 
> Since it looks like we're going this route, Makefile.template says 
> CATEGORIES comes after PKGNAME.
> So the first block should be:
> COMMENT
> PKGNAME
> REVISION
> 
> Makefile.template also says that CATEGORIES comes after the GH_* 
> variables, though I see plenty of ports that put CATEGORIES directly 
> under DISTNAME/PKGNAME, as it would be if there were no GH_*
> variables. According to your diff, CATEGORIES was placed according to 
> Makefile.template and be kept there.
> 
> ~Brian

I reordered the Makefile according to Makefile.template.

Charlène. 

> >> I'm more inclined to leave extra tabs in once a port has been
> >> imported, unless you're otherwise changing the line anyway, which
> >> you're not here. Especially in this case, where things are aligned
> >> anyway, I'm not sure removing the extra tabs improves readability.
> >> But I guess if you're going to do this, now would be the time.
> > I was advised to do so for sysutils/neofetch, so i applied the same
> > thing for this port. I entirely agree about the fact that it doesn't
> > improve (or worsen) readability here. I've let it as-is for this
> > time, but i take note for future works.
> >
> > Charlène.
> >
> >> ~Brian
> >>
> >>> patches, already in upstream's master branch but not in a release:
> >>>
> >>>   * fixed "awk: cannot open /proc/fb" [1]
> >>>   * fixed "unary operator expected" when no GPU is detected
> >>> [2]
> >>>
> >>> Testing:
> >>>
> >>> It has been successfully tested using proot, but you'll need to
> >>> copy /var/run/dmesg.boot in your chroot to check the output of the
> >>> program, as it uses this file for OS detection.
> >>>
> >>> Comments and OK are welcome!
> >>>
> >>> Charlène.
> >>>
> >>> [1]
> >>> https://github.com/KittyKatt/screenFetch/commit/dc72b5932e86ba9c4e36110408690abeb2004070
> >>> [2]
> >>> https://github.com/KittyKatt/screenFetch/commit/8346a75068323692243805fa702d02ec7538f3b9
> >>>
> >>>
> 


screenfetch.diff
Description: Binary data

Re: [NEW/WIP] Qflow porting // [2/7] Yosys

[Stuart Henderson]

On 2018/08/03 12:23, Alessandro DE LAURENZIS wrote:
> I think we need the line:
> 
> FAKE_FLAGS =  PREFIX="${LOCALBASE}"
> 
> since PREFIX is explicitly set to /usr/local in upstream Makefile when
> undefined.

That should probably be PREFIX="${TRUEPREFIX}"

> Also, in order to avoid python3 setup errors, I needed to set
> 
> CONFIGURE_STYLE = none

Yep, long-known problem with python.port.mk

> Finally, portcheck gives the following message:
> 
> Python module without compiled version, consider using ${MODPY_BIN}
> ${MODPY_LIBDIR}/compileall.py: share/yosys/python3/smtio.py
> cad/yosys
> 
> I don't know if it's acceptable (and, if not, how to remove it...)

Python normally creates pyc files for imported modules if the directory
is writable. We pre-create these so that if e.g. someone runs the program
as root, we don't get stray pyc files left behind after uninstall.
You can remove it by using ${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py
to create the pyc file.

> - compiler name forced to eg++;

Don't hardcode this, use MAKE_FLAGS= CXX="${CXX}" etc.

> Different story for kernel/yosys.cc:
> - we need to include sys/wait.h;
> - code requires the process executable base path; Linux has /proc/self/exe
> and I see that there are solutions for APPLE and WIN32 too; OpenBSD doesn't
> have a ready-to-use function; this is the closest thing that comes to my
> mind:
> 
> std::string proc_self_dirname()
> {
> // No direct way to get the process executable base path
>   char path[PATH_MAX];
>   ssize_t buflen = sizeof(path);
> char *res = realpath(getenv("_"), path);
> if (!res) {
>   log_error("getenv(\"_\") failed: %s\n",strerror(errno));
> }
>   *(strrchr(path, '/')+1) = '\0';
>   while (buflen > 0 && path[buflen-1] != '/')
>   buflen--;
>   return std::string(path, buflen);
> }
> 
> If you think that's acceptable, I'll submit the patch upstream.

IMO hardcoding the path is the most sensible way for ports.

> pdflatex is used to compile manual, application notes and presentations
> during build; it's part of print/texlive_base, which is a large port; should
> we stay with it or do you have alternatives to suggest?

That's not really a problem. If it needs pdflatex, list the dependency.

[NEW/WIP] Qflow porting // [2/7] Yosys

[Alessandro DE LAURENZIS]

Dear ports@ readers,

Yosys [1] is the second port required by Qflow [2]:

From DESCR:

[... snip ...]
Yosys Open SYnthesis Suite

Yosys is a framework for Verilog RTL synthesis. It currently has 
extensive Verilog-2005 support and provides a basic set of synthesis 
algorithms for various application domains. Selected features and 
typical applications:


- Process almost any synthesizable Verilog-2005 design
- Converting Verilog to BLIF / EDIF/ BTOR / SMT-LIB / simple RTL Verilog
- Built-in formal methods for checking properties and equivalence
- Mapping to ASIC standard cell libraries (in Liberty File Format)
- Mapping to Xilinx 7-Series and Lattice iCE40 FPGAs
- Foundation and/or front-end for custom flows

Yosys can be adapted to perform any synthesis job by combining the 
existing passes (algorithms) using synthesis scripts and adding 
additional passes as needed by extending the Yosys C++ code base.

[... snip ...]

It requires abc [3] to run (porting still under discussion).

Some highlights follow.

It doesn't compile at all using base-gcc; with base-clang, compile phase 
reaches the end, but I see a couple of segmentation faults during 
regression tests (should I investigate deeper?). With ports-gcc, it 
compiles and runs as expected.


I think we need the line:

FAKE_FLAGS =PREFIX="${LOCALBASE}"

since PREFIX is explicitly set to /usr/local in upstream Makefile when 
undefined.


Also, in order to avoid python3 setup errors, I needed to set

CONFIGURE_STYLE =   none

Finally, portcheck gives the following message:

Python module without compiled version, consider using ${MODPY_BIN} 
${MODPY_LIBDIR}/compileall.py: share/yosys/python3/smtio.py

cad/yosys

I don't know if it's acceptable (and, if not, how to remove it...)


Patches
===

Makefile requires minimal adjustments:
- PRETTY = 0 for verbose logging during build;
- -ggdb removed;
- compiler name forced to eg++;
- added -lcurses and removed -lrt and -ldl from LDLIBS;

Test suite scripts' shebangs are wrong (#!/bin/bash), but actually they 
are all called as arguments of test/tools/autotest.sh, so I patched only 
the latter.


Different story for kernel/yosys.cc:
- we need to include sys/wait.h;
- code requires the process executable base path; Linux has 
/proc/self/exe and I see that there are solutions for APPLE and WIN32 
too; OpenBSD doesn't have a ready-to-use function; this is the closest 
thing that comes to my mind:


std::string proc_self_dirname()
{
// No direct way to get the process executable base path
char path[PATH_MAX];
ssize_t buflen = sizeof(path);
char *res = realpath(getenv("_"), path);
if (!res) {
log_error("getenv(\"_\") failed: %s\n",strerror(errno));
}
*(strrchr(path, '/')+1) = '\0';
while (buflen > 0 && path[buflen-1] != '/')
buflen--;
return std::string(path, buflen);
}

If you think that's acceptable, I'll submit the patch upstream.


Dependencies


pdflatex is used to compile manual, application notes and presentations 
during build; it's part of print/texlive_base, which is a large port; 
should we stay with it or do you have alternatives to suggest?


abc is required for both running some yosys' commands and to complete 
regression tests.


I would love to switch from bash to sh in all scripts, but this requires 
time and I think it would be better to involve the author, so for the 
moment I would accept the dependency.


Tarball attached.


[1] http://www.clifford.at/yosys/
[2] https://marc.info/?l=openbsd-ports=153270090320035=2
[3] https://marc.info/?l=openbsd-ports=153270072519966=2

--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis


yosys.tar.gz
Description: application/gzip

Re: [update] editors/neovim 0.3.1

[Edd Barrett]

Hi Jon,

On Sat, Jul 28, 2018 at 02:44:44PM -0400, Jon Bernard wrote:
> Hello,
> 
> Here is an update to neovim for version 0.3.1.  The new release contains
> mostly bugfixes and nothing major.  As such, the diff is just a version
> bump and everything else remains the same.
> 
> OK?

This looks good.

One small item, after running 'make update-plist' i see that there are
some new Japanese manuals included.

+man/ja_JP.EUC/cat3f/
+man/ja_JP.EUC/man3f/
+man/ja_JP.EUC/man3p/

Do we want to include those? If not, we want to @comment those lines.

Otherwise OK.


Index: Makefile
===
RCS file: /cvs/ports/editors/neovim/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile1 Jul 2018 14:16:29 -   1.9
+++ Makefile3 Aug 2018 09:57:29 -
@@ -4,7 +4,7 @@ COMMENT =   continuation and extension of 
 
 GH_ACCOUNT =   neovim
 GH_PROJECT =   neovim
-GH_TAGNAME =   v0.3.0
+GH_TAGNAME =   v0.3.1
 
 CATEGORIES =   editors devel
 HOMEPAGE = http://neovim.org
Index: distinfo
===
RCS file: /cvs/ports/editors/neovim/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo1 Jul 2018 14:16:29 -   1.3
+++ distinfo3 Aug 2018 09:57:29 -
@@ -1,2 +1,2 @@
-SHA256 (neovim-0.3.0.tar.gz) = 96y2GxbT9SGQfZnEhrep8eUF6LKhjJ72mm1/GPKfdLg=
-SIZE (neovim-0.3.0.tar.gz) = 8903630
+SHA256 (neovim-0.3.1.tar.gz) = vF45LUwHZAeQbM7LwoPhpEt4MsL0hsrYGqBMwplzrSI=
+SIZE (neovim-0.3.1.tar.gz) = 8937900
Index: pkg/PLIST
===
RCS file: /cvs/ports/editors/neovim/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST
--- pkg/PLIST   1 Jul 2018 14:16:29 -   1.5
+++ pkg/PLIST   3 Aug 2018 09:59:35 -
@@ -1,5 +1,8 @@
 @comment $OpenBSD: PLIST,v 1.5 2018/07/01 14:16:29 edd Exp $
 @bin bin/nvim
+man/ja_JP.EUC/cat3f/
+man/ja_JP.EUC/man3f/
+man/ja_JP.EUC/man3p/
 @man man/man1/nvim.1
 share/applications/nvim.desktop
 share/doc/pkg-readmes/${FULLPKGNAME}

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Qt5Webkit -> USE_WXNEEDED

[Stuart Henderson]

On 2018/08/03 10:34, Vadim Zhukov wrote:
> чт, 2 авг. 2018 г. в 12:40, Stuart Henderson :
> >
> > On 2018/08/02 07:17, Rafael Sadowski wrote:
> > > If no concerns I would like to commit the patch.
> >
> > I'm a bit confused about this because:
> >
> > 1. we have a patch described as "Enable W^X in QtWebkit's JIT"
> > in x11/qt5/qtwebkit/patches/patch-Source_JavaScriptCore_jsc_pro
> 
> Unfortunately, it QtWebKit still crashes due to W^X violations, even
> with those patches. And there's really no point in polishing it
> nowadays, it's community-maintained (read: it gets only very minor
> updates to make it build work with newer Qt versions, as nobody in
> good mind is willing/able to fully maintain it).
> 
> Yes, you don't want to run QtWebkit-based browsers for real.

So, OK for the USE_WXNEEDED diff, but I think it might be better to do
the following to reduce the chance of running into more cases where it's
missing:

- have portcheck complain if webkit is listed in WANTLIB and USE_WXNEEDED
is not set

- possibly remove the hack from cmake?

Re: Qt5Webkit -> USE_WXNEEDED

[Vadim Zhukov]

чт, 2 авг. 2018 г. в 12:40, Stuart Henderson :
>
> On 2018/08/02 07:17, Rafael Sadowski wrote:
> > If no concerns I would like to commit the patch.
>
> I'm a bit confused about this because:
>
> 1. we have a patch described as "Enable W^X in QtWebkit's JIT"
> in x11/qt5/qtwebkit/patches/patch-Source_JavaScriptCore_jsc_pro

Unfortunately, it QtWebKit still crashes due to W^X violations, even
with those patches. And there's really no point in polishing it
nowadays, it's community-maintained (read: it gets only very minor
updates to make it build work with newer Qt versions, as nobody in
good mind is willing/able to fully maintain it).

Yes, you don't want to run QtWebkit-based browsers for real.

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/08/03 01:19:39

Modified files:
print/poppler-data: Makefile 

Log message:
obey LOCALBASE

Re: aarch64 bulk build report

[Landry Breuil]

On Fri, Aug 03, 2018 at 08:37:34AM +0200, Peter Hessler wrote:
> On 2018 Aug 03 (Fri) at 11:50:59 +1000 (+1000), Jonathan Gray wrote:
> :On Thu, Aug 02, 2018 at 05:33:09PM -0600, phess...@openbsd.org wrote:
> :> bulk build on arm64.ports.openbsd.org
> :> started on  Tue Jul 31 03:03:08 MDT 2018
> :> finished at Thu Aug 2 17:30:25 MDT 2018
> :> lasted 03D07h27m
> :> done with kern.version=OpenBSD 6.3-current (GENERIC.MP) #86: Mon Jul 30 
> 18:57:10 MDT 2018
> :> 
> :> built packages:8235
> :> Jul 31:3169
> :> Aug 1:1486
> :> Aug 2:3579
> :> 
> :> 
> :> 
> :> build failures: 47
> :
> :dtb, u-boot-aarch64 and py-cryptography logs show they didn't fail to build.
> :
> 
> I slipped in the updates to those after dpb started.  The packages built
> with no problems, but it confused some of the reporting.

If you're still using my scripts unmodified, it just lists pkgpaths
corresponding to the dpb locks that are left at the end of the bulk - so
if a port is listed as failing, it's just because dpb didnt remove the
lock for whatever reason. Maybe someone should takeover those scripts
and improve them :)

Landry

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/08/03 01:07:45

Modified files:
archivers/libtar: Makefile 
audio/soundtouch: Makefile 
audio/wavpack  : Makefile 
comms/libhidapi: Makefile 
devel/gsoap: Makefile 
devel/libinotify: Makefile 
devel/ode  : Makefile 
devel/ois  : Makefile 
devel/sdl  : Makefile 
graphics/libpgf: Makefile 
graphics/openjpeg: Makefile 
mail/libetpan  : Makefile 
print/libpaper : Makefile 

Log message:
enforce PATH when running autoreconf

Re: [NEW] gzdoom-3.5.0

[Timo Myyrä]

timo.my...@bittivirhe.fi (Timo Myyrä) writes:

> Solene Rapenne  writes:
>
>> timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
>>
>>> Hi,
>>> 
>>> Here's a updated port for latest gzdoom version.
>>> Merged the stuff from Solene's port into my old gzdoom port and bumped it to
>>> latest version. Tested on amd64 and quick gameplay test seems to work and
>>> installing soundfont and tuning the ini file, the fluidsynth playback works.
>>> 
>>> - added patch to fix the fluidsynth library name
>>> 
>>> - dropped old linker args from Makefile, these don't seem to be needed at 
>>> all
>>> 
>>> - Added flag to disable GTK dialogs from building so no need for Gtk 
>>> dependency
>>> 
>>> - fluidsynth is detected at build time so add it as build_depends. At run 
>>> time
>>>   it needs to be installed but gzdoom can use other midi players as well so 
>>> I
>>>   didn't add it to run_depends. 
>>> 
>>> - Dropped previous gxmessage dependy, the game tries kdialog, gxmessage and
>>>   finally xmessage to show crash log.
>>> 
>>> - OpenAL needs to be installed to have audio.
>>> 
>>> 
>>> Timo
>>
>> Your port is way better than the one I submitted last month, good work! Still
>> when using mods, I only have music and no other sound, do you have the same
>> issue? Doom1 and Doom2 runs fine, so it may be related to the mods...
>
> I tested Doom One mod and only got sound in menu and no gameplay sounds or 
> music
> at all. Got bunch of errors in console so I guess the mods are to blame.
>
> Timo

Actually its the problem in library loading. There was wrong library names for
libmpg123, libsndfile in the code. I've patched those and the sounds seem to
work now after quick test.

Updated port attached.

timo



gzdoom.tar.gz
Description: Binary data

CVS: cvs.openbsd.org: ports

[Frederic Cambus]

CVSROOT:/cvs
Module name:ports
Changes by: fcam...@cvs.openbsd.org 2018/08/03 00:51:31

Modified files:
textproc/ruby-rouge: Makefile distinfo 

Log message:
Update ruby-rouge to 3.2.0.

Re: aarch64 bulk build report

[Peter Hessler]

On 2018 Aug 03 (Fri) at 11:50:59 +1000 (+1000), Jonathan Gray wrote:
:On Thu, Aug 02, 2018 at 05:33:09PM -0600, phess...@openbsd.org wrote:
:> bulk build on arm64.ports.openbsd.org
:> started on  Tue Jul 31 03:03:08 MDT 2018
:> finished at Thu Aug 2 17:30:25 MDT 2018
:> lasted 03D07h27m
:> done with kern.version=OpenBSD 6.3-current (GENERIC.MP) #86: Mon Jul 30 
18:57:10 MDT 2018
:> 
:> built packages:8235
:> Jul 31:3169
:> Aug 1:1486
:> Aug 2:3579
:> 
:> 
:> 
:> build failures: 47
:
:dtb, u-boot-aarch64 and py-cryptography logs show they didn't fail to build.
:

I slipped in the updates to those after dpb started.  The packages built
with no problems, but it confused some of the reporting.


-- 
A lot of people are afraid of heights.  Not me.  I'm afraid of widths.
-- Steve Wright