Re: UPDATE: ansible-2.8.6
On 2019/10/18 23:03, Pavel Korovin wrote:
> Dear all,
>
> Please find the diff for ansible-2.8.6 attached.
> Ansible changelog:
> https://github.com/ansible/ansible/blob/stable-2.8/changelogs/CHANGELOG-v2.8.rst#v2-8-6
>
> Port changes:
>
> * Removed RUN_DEPENDS-html = ${BUILD_PKGPATH},-main
> Maybe I didn't get this right, but I don't see the reason for this dep
I agree with dropping ${BUILD_PKGPATH},-main but your diff changes it so
that -html RUN_DEPENDS on the various py-* things from the global RUN_DEPENDS.
Best to explicitly set it to blank,
RUN_DEPENDS-html =
> * I noticed that html docs were built without modules docs, and something
> else was missing. Fixed to build the complete docs prescribed by Makefile,
> added devel/gmake dependency for this to happen.
I think it's better to set USE_GMAKE for this rather than BUILD_DEPENDS and
using ${GMAKE}.
> While building the docs, found that ${MAKE_JOBS} > 1 produces an error,
> so locked it to 1, I didn't want to go deeper with it, I just want
> html docs :)
> +Index: docs/docsite/Makefile
> +--- docs/docsite/Makefile.orig
> docs/docsite/Makefile
> +@@ -5,11 +5,18 @@ TESTING_FORMATTER=../bin/testing_formatter.sh
> + DUMPER=../bin/dump_keywords.py
> + CONFIG_DUMPER=../bin/dump_config.py
> + GENERATE_CLI=../bin/generate_man.py
> +-ifeq ($(shell echo $(OS) | egrep -ic 'Darwin|FreeBSD|OpenBSD|DragonFly'),1)
> ++ifdef MAKE_JOBS
> ++CPUS = $(MAKE_JOBS)
> ++endif
> ++ifndef MAKE_JOBS
> ++ifeq ($(shell echo $(OS) | egrep -ic 'Darwin|FreeBSD|DragonFly'),1)
> + CPUS ?= $(shell sysctl hw.ncpu|awk '{print $$2}')
> ++else ifeq ($(shell echo $(OS) | egrep -ic 'OpenBSD'),1)
> ++CPUS ?= $(shell sysctl -n hw.ncpu)
> + else
> + CPUS ?= $(shell nproc)
> + endif
> ++endif
For the ncpu thing the correct thing to do here would be to pass
CPUS=${MAKE_JOBS} to gmake (on the command line, not in the environment,
i.e. "${MAKE_PROGRAM} CPUS=... all"), you don't need the ifdef patches to
Makefile because command line variables override the Makefile anyway.
There's no requirement for ports to work with MAKE_JOBS>1 but if it is
set I do think it should be passed on to internal make invocations.
> +
> + # Sets the build output directory if it's not already specified
> + ifndef BUILDDIR
> +@@ -106,5 +113,5 @@ epub:
> + (CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx epub)
> +
> + htmlsingle: assertrst
> +-sphinx-build -j $(CPUS) -b html -d $(BUILDDIR)/doctrees ./rst
> $(BUILDDIR)/html rst/$(rst)
> ++sphinx-build-3 -j $(CPUS) -b html -d $(BUILDDIR)/doctrees ./rst
> $(BUILDDIR)/html rst/$(rst)
This shouldn't hardcode -3. I think I would symlink
sphinx-build${MODPY_BIN_SUFFIX}
into ${WRKDIR}/bin/sphinx-build in pre-build instead rather than messing about
with SUBST_CMD'ing variables.
> + @echo "Output is in $(BUILDDIR)/html/$(rst:.rst=.html)"
> Index: patches/patch-docs_docsite_Makefile_sphinx
> ===
> RCS file: patches/patch-docs_docsite_Makefile_sphinx
> diff -N patches/patch-docs_docsite_Makefile_sphinx
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-docs_docsite_Makefile_sphinx18 Oct 2019 19:41:38
> -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Index: docs/docsite/Makefile.sphinx
> +--- docs/docsite/Makefile.sphinx.orig
> docs/docsite/Makefile.sphinx
> +@@ -3,7 +3,7 @@
> +
> + # You can set these variables from the command line.
> + SPHINXOPTS= -j $(CPUS) -n -w rst_warnings
> +-SPHINXBUILD = sphinx-build
> ++SPHINXBUILD = sphinx-build-3
same. (I wonder why they set SPHINXBUILD here but hardcode sphinx-build
in the htmlsingle target ..)
> -share/doc/ansible/html/reference_appendices/general_precedence.html
I think moving this between subpackages probably needs @conflict markers
Re: [NEW] devel/p5-Sys-MemInfo
On Fri, 18 Oct 2019 20:31:36 +0100 Stuart Henderson wrote: > Oh could you move it to sysutils/ please, it makes more sense than > devel. Otherwise OK It's committed -- i've reported the issue upstream as well: https://rt.cpan.org/Public/Bug/Display.html?id=130740
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/10/18 15:10:04 Modified files: sysutils : Makefile Log message: +p5-Sys-MemInfo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/10/18 15:09:03 Log message: Import p5-Sys-MemInfo-0.99 Sys::MemInfo return the total amount of free and used physical memory in bytes in totalmem and freemem variables. From Henry Jensen, with hints from sthen@, and further fixes from me. OK sthen@ Status: Vendor Tag: cwen Release Tags: cwen_20191018 N ports/devel/sysutils/p5-Sys-MemInfo/Makefile N ports/devel/sysutils/p5-Sys-MemInfo/distinfo N ports/devel/sysutils/p5-Sys-MemInfo/pkg/DESCR N ports/devel/sysutils/p5-Sys-MemInfo/pkg/PLIST N ports/devel/sysutils/p5-Sys-MemInfo/patches/patch-Makefile_PL No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/10/18 15:04:59 Modified files: net/unifi/testing: Makefile distinfo Log message: update to unifi-5.12.19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/10/18 15:00:41 Modified files: databases/freetds: Makefile distinfo databases/freetds/patches: patch-include_tds_sysdep_public_h_in Log message: update to freetds-1.1.20
Re: valgrind diff to fix run memcheck on amd64
On 2019/10/18 15:08, Masato Asou wrote:
> From: YASUOKA Masahiko
> Date: Wed, 02 Oct 2019 23:29:05 +0900 (JST)
>
> > I looked into the problem more.
> >
> > - unveil(2) itself fails
> > - so file system related system calls are not restricted (yet)
> >
> > valgrind complains:
> >
> > ==13326==
> > --13326-- WARNING: unhandled syscall: 114
> > --13326-- You may be able to write your own handler.
> > --13326-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> > --13326-- Nevertheless we consider this a bug. Please report
> > --13326-- it at http://valgrind.org/support/bug_reports.html.
> >
> > valgrind doesn't support unveil(2) yet. I suppose Asou can add that.
>
> I was added unveil(2).
Please set REVISION = 14 in ports/devel/valgrind/Makefile so that
"pkg_add -u" will find the update.
Otherwise OK sthen@
> --
> ASOU Masato
>
> Index: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
> ===
> RCS file: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
> diff -N patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h 8 Oct 2019
> 02:53:32 -
> @@ -0,0 +1,10 @@
> +--- coregrind/m_syswrap/priv_syswrap-openbsd.h.orig
> coregrind/m_syswrap/priv_syswrap-openbsd.h
> +@@ -144,6 +144,7 @@
> + DECL_TEMPLATE(openbsd, sys_pledge);
> + DECL_TEMPLATE(openbsd, sys_ppoll);
> + DECL_TEMPLATE(openbsd, sys_pselect);
> ++DECL_TEMPLATE(openbsd, sys_unveil);
> + DECL_TEMPLATE(openbsd, sys_sigsuspend);
> + DECL_TEMPLATE(openbsd, sys_gettimeofday);
> + DECL_TEMPLATE(openbsd, sys_getrusage);
> Index: patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
> ===
> RCS file: patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
> diff -N patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-coregrind_m_syswrap_syswrap_openbsd_c 8 Oct 2019
> 02:53:32 -
> @@ -0,0 +1,30 @@
> +--- coregrind/m_syswrap/syswrap-openbsd.c.orig
> coregrind/m_syswrap/syswrap-openbsd.c
> +@@ -575,6 +579,17 @@
> + // XXXTBD
> + }
> +
> ++PRE(sys_unveil)
> ++{
> ++ PRINT("sys_unveil ( %#lx(%s), %#lx(%s) )",
> ++ ARG1,(char *)ARG1,ARG2,(char*)ARG2);
> ++ PRE_REG_READ2(long, "unveil", const char *, path, const char *,
> permissions);
> ++ if (ARG1 != (UWord)NULL)
> ++ PRE_MEM_RASCIIZ( "unveil(path)", ARG1 );
> ++ if (ARG2 != (UWord)NULL)
> ++ PRE_MEM_RASCIIZ( "unveil(permissions)", ARG2 );
> ++}
> ++
> + PRE(sys_getsockname)
> + {
> +PRINT("sys_getsockname ( %ld, %#lx, %#lx )",ARG1,ARG2,ARG3);
> +@@ -4079,7 +4093,7 @@
> + BSDX_(__NR_sigsuspend,sys_sigsuspend),// 111
> + BSDX_(__NR_sendsyslog,sys_sendsyslog),// 112
> + // obsol orecvmsg // 113
> +- // obsol osendmsg // 114
> ++ BSDX_(__NR_unveil,sys_unveil),// 114
> + // obsol vtrace // 115
> +
> + BSDX_(__NR_getsockopt,sys_getsockopt),// 118
> +Only in pobj/valgrind-3.10.1/valgrind-3.10.1/coregrind/m_syswrap:
> syswrap-openbsd.c.orig
> Index: patches/patch-include_vki_vki_scnums_openbsd_h
> ===
> RCS file: patches/patch-include_vki_vki_scnums_openbsd_h
> diff -N patches/patch-include_vki_vki_scnums_openbsd_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-include_vki_vki_scnums_openbsd_h8 Oct 2019 02:53:32
> -
> @@ -0,0 +1,10 @@
> +--- include/vki/vki-scnums-openbsd.h.orig
> include/vki/vki-scnums-openbsd.h
> +@@ -146,6 +146,7 @@
> + #define __NR_pselect110
> + #define __NR_sigsuspend 111
> + #define __NR_sendsyslog 112
> ++#define __NR_unveil 114
> + #define __NR_getsockopt 118
> + #define __NR_thrkill119
> + #define __NR_readv 120
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2019/10/18 14:22:49 Modified files: www/vimb : Makefile distinfo Log message: Update vimb to 3.5.0 Update diff from "Heppler, J. Scott" . Thanks!
Re: [NEW] devel/p5-Sys-MemInfo
Oh could you move it to sysutils/ please, it makes more sense than devel. Otherwise OK On 2019/10/18 17:58, Charlene Wendling wrote: > On Thu, 17 Oct 2019 21:21:14 +0100 > Stuart Henderson wrote: > > > On 2019/10/17 10:01, Henry Jensen wrote: > > > On Wed, 16 Oct 2019 16:07:34 +0100 > > > Stuart Henderson wrote: > > > > > > > On 2019/10/16 09:04, Henry Jensen wrote: > > > > > Ping > > > > > > > > > > On Wed, 9 Oct 2019 15:08:00 +0200 > > > > > Henry Jensen wrote: > > > > > > > > > > > Greetings, > > > > > > > > > > > > attached is a new port for the perl module Sys::MemInfo. > > > > > > Sys::MemInfo returns the total amount of free and used > > > > > > physical memory in bytes in totalmem and freemem variables. > > > > > > Tested on -current amd64. > > > > > > > > Please format Makefile and DESCR a bit nicer. Look at other ports > > > > in the tree for examples. > > > > > > Actually, I used one of the p5-* ports as template. I made minor > > > modifications now (honoring the 72 character per line limit) and > > > compared the formatting to other ports. > > > > That's better, this one is okay sthen@ if someone would like to > > import. > > Sorry, but this module is broken because it badly computes totalmem, > see [0], where i have 16 gigs actually. I've modified Makefile.PL, so > we use the same code as NetBSD, this fixes the issue. > > Also there was a trailing whitespace in DESCR. > > It works fine on macppc as well. > > I'm attaching a modified tarball. > > Charlène. > > > [0] https://bin.charlenew.xyz/meminfo.failing.log > >
Re: [NEW] devel/p5-Sys-MemInfo
On Thu, 17 Oct 2019 21:21:14 +0100 Stuart Henderson wrote: > On 2019/10/17 10:01, Henry Jensen wrote: > > On Wed, 16 Oct 2019 16:07:34 +0100 > > Stuart Henderson wrote: > > > > > On 2019/10/16 09:04, Henry Jensen wrote: > > > > Ping > > > > > > > > On Wed, 9 Oct 2019 15:08:00 +0200 > > > > Henry Jensen wrote: > > > > > > > > > Greetings, > > > > > > > > > > attached is a new port for the perl module Sys::MemInfo. > > > > > Sys::MemInfo returns the total amount of free and used > > > > > physical memory in bytes in totalmem and freemem variables. > > > > > Tested on -current amd64. > > > > > > Please format Makefile and DESCR a bit nicer. Look at other ports > > > in the tree for examples. > > > > Actually, I used one of the p5-* ports as template. I made minor > > modifications now (honoring the 72 character per line limit) and > > compared the formatting to other ports. > > That's better, this one is okay sthen@ if someone would like to > import. Sorry, but this module is broken because it badly computes totalmem, see [0], where i have 16 gigs actually. I've modified Makefile.PL, so we use the same code as NetBSD, this fixes the issue. Also there was a trailing whitespace in DESCR. It works fine on macppc as well. I'm attaching a modified tarball. Charlène. [0] https://bin.charlenew.xyz/meminfo.failing.log p5-Sys-MemInfo.tgz Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/10/18 09:11:09 Modified files: games/love : Makefile Added files: games/love/patches: patch-src_libraries_Box2D_Collision_Shapes_b2ChainShape_h Log message: love: fix the build with ports-gcc Fix some occurrences where ports-gcc doesn't want to consider `NULL' as a boolean `false'. Tested on sparc64 by kmos@ and macppc by me. Also move HOMEPAGE to https. OK kmos@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/10/18 08:51:59 Modified files: graphics/DevIL : Makefile Log message: DevIL: disable _mm_malloc() detection and usage on powerpc gcc-8's _mm_malloc() uses the AltiVec keyword __vector on this arch, breaking the build -- and we don't want AltiVec for macppc G3 compat. While here refresh WANTLIB and remove the unused graphics/openjpeg from LIB_DEPENDS (spotted by kmos@, thanks!) OK sthen@ kmos@
NEW: devel/p5-Locale-Codes
Standard Perl module removed from Perl distribution that some software could need. pkg/DESCR: Locale-Codes is a distribution containing a set of modules designed to work with sets of codes which uniquely identify something. For example, there are codes associated with different countries, different currencies, different languages, etc. These sets of codes are typically maintained in some standard. Comments ? Ok ? Giovanni p5-Locale-Codes-3.62.tgz Description: application/compressed-tar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/10/18 08:15:09 Modified files: devel/p5-Test-Deep-JSON: Makefile distinfo devel/p5-Test-Deep-JSON/pkg: PLIST Log message: p5-Test-Deep-JSON: update to 0.05 Changelog: https://metacpan.org/changes/distribution/Test-Deep-JSON >From Wen Heping, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/10/18 08:13:31 Modified files: sysutils/firmware/iwm: Makefile distinfo Log message: now that we have DQA support in iwm(4), we can switch to newer V22 API firmware ok stsp@
Re: Retire python2
> On Oct 18, 2019, at 9:02 AM, Stuart Henderson wrote:
>
> On 2019/10/17 22:27, Daniel Dickman wrote:
>>> On Thu, Sep 26, 2019 at 8:25 AM Stuart Henderson
>>> wrote:
>>> On 2019/09/26 08:12, Daniel Dickman wrote:
(Moved from: “Adding binary renaming facility to python.port.mk”)
> On Sep 25, 2019, at 5:47 AM, Stuart Henderson
>>> wrote:
> imo, if there's a good reason to keep the py2 version (used by
>>> something
> else in the ports tree, or possibly if it includes a useful compiled
> iextension) then split the port.
> but if the py2 version isn't really useful and is holding back an
>>> update,
> drop the py2 version.
I’m wondering how you’re thinking about this. Something like the below?
Change:
FLAVORS =python3
FLAVOR ?=
To:
FLAVORS = python3
FLAVOR = python3
(Note, I purposely remove the ? above to avoid ability to override
>>> FLAVOR.)
I think this approach would minimize changes in reverse dependencies
>>> that depend on a FLAVOR.
>>> For the sake of consistency I was mostly thinking of following the
>>> current py3-only ports and use MODPY_VERSION=${MODPY_DEFAULT_VERSION_3}
>>> without a flavour, it's not too much work to find and update reverse
>>> dep's.
>>> I had originally tried this approach via MODPY_VERSION and found it
>> painful as a transition strategy compared to my proposed approach via
>> FLAVOR/S.
>
> Painful in what way?
>
> It is a bit awkward later because then you have a mixture of
> ${MODPY_FLAVOR} for the dual-version ports and no ${MODPY_FLAVOR} for
> others but that is the current standard approach in ports (and the
> actual transition seems alright to me?)
Yes exactly. And also dealing with the top level Makefiles and quirks.
Let me try to do a proof of concept both ways using scipy and seaborn and come
back to you. Maybe it will help make things clearer (at least for me).
>
> Reminder that I would still like to convert things so that py2 things
> are *also* flavoured, i.e. FLAVOR=python2/python3 or maybe py27/py37/py38/etc,
> but I see that as a separate step to what you're doing here [I'm
> considering looking at this at p2k19]. It's easier to do that if all
> of the existing py3-only ports are consistent with respect to each other.
Agree on consistency. That would be very useful.
No opinion on python2 though as I don’t use anything that’s python2 myself
anymore. :-)
>
>
>> So I think maybe better to keep all the ,python3 flavors first, then when
>> we’re ready to drop python2 do a bulk conversion of the tree to drop those
>> flavors?
>> But I’m open to ideas if someone has a good strategy they can share.
>> Would be nice to decide on the approach because I have my python3-only,
>> numpy 1.17.3 update pretty much ready to go. And that port is going to have
>> an impact on a good chunk of the ports tree...
>> ps. I suggest scipy, matplotlib or pandas as proof of concept ports to
>> update because: they’re probably some of the most widely used python ports,
>> have all gone python3-only, and have fewer reverse dependencies to worry
>> about.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/10/18 07:14:36 Modified files: x11/qt5/qtbase : Makefile Log message: missed bump
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/10/18 07:08:07 Modified files: lang/python: Makefile python.port.mk Removed files: lang/python/3.6: Makefile distinfo lang/python/3.6/files: CHANGES.OpenBSD lang/python/3.6/patches: patch-Lib_test_test_locale_py patch-Makefile_pre_in patch-Modules__hashopenssl_c patch-Modules__ssl_c patch-configure_ac patch-setup_py lang/python/3.6/pkg: DESCR-gdbm DESCR-idle DESCR-main DESCR-tests DESCR-tkinter PLIST-gdbm PLIST-idle PLIST-main PLIST-tests PLIST-tkinter Log message: Retire Python 3.6 ok sthen
Re: Retire python2
On 2019/10/17 22:27, Daniel Dickman wrote:
> On Thu, Sep 26, 2019 at 8:25 AM Stuart Henderson
> wrote:
>
> > On 2019/09/26 08:12, Daniel Dickman wrote:
> > > (Moved from: “Adding binary renaming facility to python.port.mk”)
> > >
> > > > On Sep 25, 2019, at 5:47 AM, Stuart Henderson
> > wrote:
> > > >
> > > > imo, if there's a good reason to keep the py2 version (used by
> > something
> > > > else in the ports tree, or possibly if it includes a useful compiled
> > > > iextension) then split the port.
> > > >
> > > > but if the py2 version isn't really useful and is holding back an
> > update,
> > > > drop the py2 version.
> > >
> > > I’m wondering how you’re thinking about this. Something like the below?
> > >
> > > Change:
> > >
> > > FLAVORS = python3
> > > FLAVOR ?=
> > >
> > > To:
> > >
> > > FLAVORS = python3
> > > FLAVOR = python3
> > >
> > > (Note, I purposely remove the ? above to avoid ability to override
> > FLAVOR.)
> > >
> > > I think this approach would minimize changes in reverse dependencies
> > that depend on a FLAVOR.
> >
> > For the sake of consistency I was mostly thinking of following the
> > current py3-only ports and use MODPY_VERSION=${MODPY_DEFAULT_VERSION_3}
> > without a flavour, it's not too much work to find and update reverse
> > dep's.
> >
> > I had originally tried this approach via MODPY_VERSION and found it
> painful as a transition strategy compared to my proposed approach via
> FLAVOR/S.
Painful in what way?
It is a bit awkward later because then you have a mixture of
${MODPY_FLAVOR} for the dual-version ports and no ${MODPY_FLAVOR} for
others but that is the current standard approach in ports (and the
actual transition seems alright to me?)
Reminder that I would still like to convert things so that py2 things
are *also* flavoured, i.e. FLAVOR=python2/python3 or maybe py27/py37/py38/etc,
but I see that as a separate step to what you're doing here [I'm
considering looking at this at p2k19]. It's easier to do that if all
of the existing py3-only ports are consistent with respect to each other.
> So I think maybe better to keep all the ,python3 flavors first, then when
> we’re ready to drop python2 do a bulk conversion of the tree to drop those
> flavors?
>
> But I’m open to ideas if someone has a good strategy they can share.
>
> Would be nice to decide on the approach because I have my python3-only,
> numpy 1.17.3 update pretty much ready to go. And that port is going to have
> an impact on a good chunk of the ports tree...
>
> ps. I suggest scipy, matplotlib or pandas as proof of concept ports to
> update because: they’re probably some of the most widely used python ports,
> have all gone python3-only, and have fewer reverse dependencies to worry
> about.
Re: [macppc] Unbreak graphics/DevIL
On 2019/10/18 01:51, Charlene Wendling wrote:
>
> (Pascal, only this port seems to have this issue, it's FYI)
>
> > http://build-failures.rhaalovely.net/powerpc/2019-09-17/graphics/DevIL.log
>
> __vector is an AltiVec keyword. AltiVec is not found by DevIL's
> configure script, which is actually what we want (G3 machines don't
> support AltiVec).
>
> The "problem" comes from gcc-8's _mm_malloc(), that uses that keyword.
> It seems to me that the old gcc-4.9 didn't have _mm_malloc(), so that's
> why it's broken since gcc-8 is ports-gcc.
>
> As such, i've disabled the use of _mm_malloc. While here i've updated
> WANTLIB.
>
> It builds fine on amd64, and macppc [0], where i have been able to
> fix (diff incoming), build and run games/love, its only consumer on
> macppc.
>
> Comments/feedback are welcome!
OK
> Charlène.
>
>
> [0] https://bin.charlenew.xyz/DevIL.log
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/DevIL/Makefile,v
> retrieving revision 1.26
> diff -u -p -u -p -r1.26 Makefile
> --- Makefile 12 Jul 2019 20:46:56 - 1.26
> +++ Makefile 17 Oct 2019 21:53:10 -
> @@ -3,7 +3,7 @@
> COMMENT= library for powerful image loading capabilities
>
> DISTNAME=DevIL-1.7.8
> -REVISION=14
> +REVISION=15
> SHARED_LIBS+=IL 1.0 # 2.0
> SHARED_LIBS+=ILU 1.0 # 2.0
> SHARED_LIBS+=ILUT1.0 # 2.0
> @@ -18,11 +18,12 @@ PERMIT_PACKAGE= Yes
> MASTER_SITES=${MASTER_SITE_SOURCEFORGE:=openil/}
> EXTRACT_SUFX=.zip
>
> -WANTLIB += GL GLU Half ICE Iex IexMath IlmImf IlmThread Imath
> -WANTLIB += SDL SM X11 X11-xcb Xdamage Xext Xfixes Xi
> -WANTLIB += Xmu Xrandr Xrender Xt Xxf86vm c drm glapi glut iconv jasper
> -WANTLIB += jpeg lcms m mng png pthread sndio ${COMPILER_LIBCXX}
> -WANTLIB += tiff usbhid xcb xcb-dri2 xcb-glx z expat
> +WANTLIB += ${COMPILER_LIBCXX} GL GLU Half ICE Iex IexMath IlmImf
> +WANTLIB += IlmThread Imath SDL SM X11 X11-xcb Xdamage Xext Xfixes
> +WANTLIB += Xi Xmu Xrandr Xrender Xt Xxf86vm c drm expat glapi
> +WANTLIB += glut iconv jasper jpeg lcms m mng png sndio tiff usbhid
> +WANTLIB += xcb xcb-dri2 xcb-dri3 xcb-glx xcb-present xcb-sync
> +WANTLIB += xcb-xfixes xshmfence z
>
> COMPILER = base-clang ports-gcc base-gcc
>
> @@ -56,6 +57,12 @@ WRKDIST= ${WRKDIR}/${DISTNAME:L}
>
> # Too many Linuxisms in testing tools
> NO_TEST= Yes
> +
> +# gcc-8's _mm_malloc() uses the AltiVec keyword __vector, so we need
> +# to disable it to make it run on macppc G3 machines
> +.if ${MACHINE_ARCH:Mpowerpc}
> +CONFIGURE_ENV += ac_cv_header_mm_malloc_h=
> +.endif
>
> post-extract:
> chmod +x ${WRKSRC}/configure
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2019/10/18 06:50:00 Modified files: x11/tint2 : Makefile distinfo x11/tint2/patches: patch-CMakeLists_txt patch-themes_CMakeLists_txt patch-themes_tint2rc x11/tint2/pkg : PLIST Log message: Update tint2 to 16.7 Update diff from "Heppler, J. Scott" . Thanks
Re: [macppc, probably ports-gcc] Unbreak devel/double-conversion (was: Re: new: devel/double-conversion)
On 2019/10/18 01:19, Charlene Wendling wrote: > That's why portcheck(1) yells if COMPILER_LIBCXX is in WANTLIB and > no COMPILER line with at least ports-gcc is set [0]. I added that check mainly to avoid pulling in multiple standard C++ libraries to the same address space (e.g. via library dependencies).
UPDATE: x11/qt5
Simple bugfix update Qt5 from 5.9.7 to 5.9.8.
I don't see any danger to the ports tree. The SSL stuff works fine
(tested with otter-browser) and all of my other qt applications are
still happy. Qt is known for not breaking the API/ABI.
To be on the safe side, can anyone push it into the next bulk build,
please?
Ports note:
I dropped KDE porting team as maintainer. Nobody listens on the list,
expect me.
Qt 5.13+ comment:
I would like to present an update to 5.13 but it is going very slowly
and with a lot of pain. BUT it's moving forward.
RS
Index: Makefile.inc
===
RCS file: /cvs/ports/x11/qt5/Makefile.inc,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile.inc
--- Makefile.inc13 Jul 2019 11:02:18 - 1.11
+++ Makefile.inc18 Oct 2019 11:42:19 -
@@ -24,7 +24,6 @@ DPB_PROPERTIES += nojunk
CATEGORIES += x11 x11/qt5 devel
HOMEPAGE ?=https://www.qt.io/
-MAINTAINER ?= KDE porting team
# We don't build examples, but provide sources only.
WANTLIB-examples ?=
Index: Makefile.version
===
RCS file: /cvs/ports/x11/qt5/Makefile.version,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile.version
--- Makefile.version30 Oct 2018 08:08:40 - 1.7
+++ Makefile.version18 Oct 2019 11:42:19 -
@@ -1,13 +1,13 @@
# $OpenBSD: Makefile.version,v 1.7 2018/10/30 08:08:40 rsadowski Exp $
# Common source for Qt5 version
-QT5_VERSION = 5.9.7
-QT5_DIST_VERSION = 5.9.7
+QT5_VERSION = 5.9.8
+QT5_DIST_VERSION = 5.9.8
QT5_WEBKIT_VERSION = 5.9.0
# This one is used for building dependencies for examples and documentation,
# which obviously should be in sync with core packages.
-QT5_NEXT_VERSION = 5.10
+QT5_NEXT_VERSION = 5.14
# Enginio has own versioning
ENGINIO_VERSION = ${QT5_VERSION:C/^5/1/}
Index: qt3d/Makefile
===
RCS file: /cvs/ports/x11/qt5/qt3d/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- qt3d/Makefile 25 Aug 2019 20:10:37 - 1.11
+++ qt3d/Makefile 18 Oct 2019 11:42:19 -
@@ -5,7 +5,6 @@
QT5NAME = Qt3D
COMMENT-main = Qt5 components for 3D graphics
-REVISION-main =2
MULTI_PACKAGES = -main -examples
Index: qt3d/distinfo
===
RCS file: /cvs/ports/x11/qt5/qt3d/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- qt3d/distinfo 30 Oct 2018 08:08:40 - 1.7
+++ qt3d/distinfo 18 Oct 2019 11:42:19 -
@@ -1,2 +1,2 @@
-SHA256 (qt/qt3d-opensource-src-5.9.7.tar.xz) =
FBkRVZiJztWF0+ikUXjqxRm9o6BDXZo4O8k7KsW5bWo=
-SIZE (qt/qt3d-opensource-src-5.9.7.tar.xz) = 83723376
+SHA256 (qt/qt3d-opensource-src-5.9.8.tar.xz) =
IaSJDMUsAVwb4FaO8tMi1ItDBHD7jEguKD/214PLk/k=
+SIZE (qt/qt3d-opensource-src-5.9.8.tar.xz) = 83723260
Index: qtbase/Makefile
===
RCS file: /cvs/ports/x11/qt5/qtbase/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- qtbase/Makefile 17 Oct 2019 19:58:16 - 1.32
+++ qtbase/Makefile 18 Oct 2019 11:42:19 -
@@ -16,13 +16,6 @@ PKGNAME-psql = qt5-postgresql-${VERSION
PKGNAME-sqlite2 = qt5-sqlite2-${VERSION}
PKGNAME-tds = qt5-tds-${VERSION}
-REVISION-global = 0
-REVISION-main =7
-REVISION-mysql = 0
-REVISION-psql =0
-REVISION-sqlite2 = 0
-REVISION-tds = 0
-
PKG_ARCH-global = *
PKG_ARCH-examples =*
@@ -218,12 +211,13 @@ MAKE_ENV += ${MODQMAKE_ENV}
# See qtbase/tests/README for details
TEST_IS_INTERACTIVE = X11
TEST_DEPENDS = audio/sox
-# kde4-minimal-*|kdebase-*:meta/kde4,-minimal
post-extract:
mkdir -p ${WRKDIST}/mkspecs/openbsd-clang
- cp ${FILESDIR}/clang-qmake.conf
${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
- cp ${WRKDIST}/mkspecs/openbsd-g++/qplatformdefs.h
${WRKDIST}/mkspecs/openbsd-clang/
+ cp ${FILESDIR}/clang-qmake.conf \
+ ${WRKDIST}/mkspecs/openbsd-clang/qmake.conf
+ cp ${WRKDIST}/mkspecs/openbsd-g++/qplatformdefs.h \
+ ${WRKDIST}/mkspecs/openbsd-clang/
pre-configure:
@gccbasedir=`ecpp -print-search-dirs | awk '/^install:/{print $$2}'`; \
Index: qtbase/distinfo
===
RCS file: /cvs/ports/x11/qt5/qtbase/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- qtbase/distinfo 30 Oct 2018 08:08:40 - 1.7
+++ qtbase/distinfo 18 Oct 2019 11:42:19 -
@@ -1,2 +1,2 @@
-SHA256 (qt/qtbase-opensource-src-5.9.7.tar.xz) =
Nt2VdPAG6qHlr3gOSzPRH+OdCf18EvO52DKUF0vSjwA=
-SIZE (qt/qtbase-opensource-src-5.9.7.tar.xz) =
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/10/18 05:06:41 Modified files: devel : Makefile Log message: +p5-CLI-Framework
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: c...@cvs.openbsd.org2019/10/18 05:05:30
Log message:
Import p5-CLI-Framework-0.05
CLI::Framework ("CLIF") provides a framework and conceptual pattern
for building full-featured command line applications. It intends
to make this process simple and consistent. It assumes the
responsibility of implementing details that are common to all
command-line applications, making it possible for new applications
adhering to well-defined conventions to be built without the need
to repeatedly write the same command-line interface code.
From Peter Ezetta , with tweaks from afresh1@
OK afresh1@
Status:
Vendor Tag: cwen
Release Tags: cwen_20191018
N ports/devel/p5-CLI-Framework/Makefile
N ports/devel/p5-CLI-Framework/distinfo
N ports/devel/p5-CLI-Framework/pkg/PLIST
N ports/devel/p5-CLI-Framework/pkg/DESCR
No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: c...@cvs.openbsd.org2019/10/18 04:39:09
Modified files:
math/double-conversion: Makefile
Log message:
double-conversion: ${COMPILER_LIBCXX} in WANTLIB should come with a
COMPILER line including ports-gcc in it. This fixes the build on macppc.
Also tested on sparc64 by kmos@
OK rsadowski@ kmos@
Update prometheus to v2.13.1
The update just fixes these three things: [BUGFIX] Fix panic in ARM builds of Prometheus. #6110 [BUGFIX] promql: fix potential panic in the query logger. #6094 [BUGFIX] Multiple errors of http: superfluous response.WriteHeader call in the logs. #6145 Since I hit the 2nd bug myself I think it is good to update the port. Please test thanks -- :wq Claudio Index: Makefile === RCS file: /cvs/ports/sysutils/prometheus/Makefile,v retrieving revision 1.7 diff -u -p -r1.7 Makefile --- Makefile16 Oct 2019 06:47:12 - 1.7 +++ Makefile18 Oct 2019 08:57:46 - @@ -4,7 +4,7 @@ COMMENT = systems monitoring and alerti GH_ACCOUNT = prometheus GH_PROJECT = prometheus -GH_TAGNAME = v2.13.0 +GH_TAGNAME = v2.13.1 CATEGORIES = sysutils Index: distinfo === RCS file: /cvs/ports/sysutils/prometheus/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo16 Oct 2019 06:47:12 - 1.3 +++ distinfo18 Oct 2019 08:58:23 - @@ -1,2 +1,2 @@ -SHA256 (prometheus-2.13.0.tar.gz) = jfCsdC/tqtEuOZaFC2t2nVrKcHVmngVUD7xcNjvgsoo= -SIZE (prometheus-2.13.0.tar.gz) = 15193226 +SHA256 (prometheus-2.13.1.tar.gz) = ViTBZyhnk2LPpGt27B0kcBgQaYnyJg01WDxCxJxRQrU= +SIZE (prometheus-2.13.1.tar.gz) = 15249891
Re: [new] net/barrier 2.3.2
On Wed, 16 Oct 2019, Aaron Bieber wrote: > Hi! > > This is a fork of synergy from the 1.9 code base. I have been using it for a > while without issue. > > I don't use the gui app, but it starts up and lets me diddle various things. > > Description: > Barrier is KVM software forked from Symless's synergy 1.9 codebase. Synergy > was a commercialized reimplementation of the original CosmoSynergy written by > Chris Schoeneman. > > Cluesticks? OKs? Tested for 24h as a server (amd64) with mac as client. It works fine. On the build process I had this error on the "make package" stage: pkg_create: can't open /usr/ports/mystuff/net/barrier/pkg/DESCR: Permission denied That's because the permissions on this file after tarball extraction are like: -rw--- 1 paco wheel 172 Oct 17 02:55 DESCR and I have PRIVSEP enabled. Once that corrected it created the package and installs ok. Cheers, -- Paco Esteban. 5818130B8A6DBC03
Re: valgrind diff to fix run memcheck on amd64
From: YASUOKA Masahiko
Date: Wed, 02 Oct 2019 23:29:05 +0900 (JST)
> I looked into the problem more.
>
> - unveil(2) itself fails
> - so file system related system calls are not restricted (yet)
>
> valgrind complains:
>
> ==13326==
> --13326-- WARNING: unhandled syscall: 114
> --13326-- You may be able to write your own handler.
> --13326-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> --13326-- Nevertheless we consider this a bug. Please report
> --13326-- it at http://valgrind.org/support/bug_reports.html.
>
> valgrind doesn't support unveil(2) yet. I suppose Asou can add that.
I was added unveil(2).
--
ASOU Masato
Index: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
===
RCS file: patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
diff -N patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-coregrind_m_syswrap_priv_syswrap_openbsd_h8 Oct 2019
02:53:32 -
@@ -0,0 +1,10 @@
+--- coregrind/m_syswrap/priv_syswrap-openbsd.h.orig
coregrind/m_syswrap/priv_syswrap-openbsd.h
+@@ -144,6 +144,7 @@
+ DECL_TEMPLATE(openbsd, sys_pledge);
+ DECL_TEMPLATE(openbsd, sys_ppoll);
+ DECL_TEMPLATE(openbsd, sys_pselect);
++DECL_TEMPLATE(openbsd, sys_unveil);
+ DECL_TEMPLATE(openbsd, sys_sigsuspend);
+ DECL_TEMPLATE(openbsd, sys_gettimeofday);
+ DECL_TEMPLATE(openbsd, sys_getrusage);
Index: patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
===
RCS file: patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
diff -N patches/patch-coregrind_m_syswrap_syswrap_openbsd_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-coregrind_m_syswrap_syswrap_openbsd_c 8 Oct 2019 02:53:32
-
@@ -0,0 +1,30 @@
+--- coregrind/m_syswrap/syswrap-openbsd.c.orig
coregrind/m_syswrap/syswrap-openbsd.c
+@@ -575,6 +579,17 @@
+ // XXXTBD
+ }
+
++PRE(sys_unveil)
++{
++ PRINT("sys_unveil ( %#lx(%s), %#lx(%s) )",
++ ARG1,(char *)ARG1,ARG2,(char*)ARG2);
++ PRE_REG_READ2(long, "unveil", const char *, path, const char *,
permissions);
++ if (ARG1 != (UWord)NULL)
++ PRE_MEM_RASCIIZ( "unveil(path)", ARG1 );
++ if (ARG2 != (UWord)NULL)
++ PRE_MEM_RASCIIZ( "unveil(permissions)", ARG2 );
++}
++
+ PRE(sys_getsockname)
+ {
+PRINT("sys_getsockname ( %ld, %#lx, %#lx )",ARG1,ARG2,ARG3);
+@@ -4079,7 +4093,7 @@
+ BSDX_(__NR_sigsuspend, sys_sigsuspend),// 111
+ BSDX_(__NR_sendsyslog, sys_sendsyslog),// 112
+ // obsol orecvmsg // 113
+- // obsol osendmsg // 114
++ BSDX_(__NR_unveil, sys_unveil),// 114
+ // obsol vtrace // 115
+
+ BSDX_(__NR_getsockopt, sys_getsockopt),// 118
+Only in pobj/valgrind-3.10.1/valgrind-3.10.1/coregrind/m_syswrap:
syswrap-openbsd.c.orig
Index: patches/patch-include_vki_vki_scnums_openbsd_h
===
RCS file: patches/patch-include_vki_vki_scnums_openbsd_h
diff -N patches/patch-include_vki_vki_scnums_openbsd_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-include_vki_vki_scnums_openbsd_h 8 Oct 2019 02:53:32
-
@@ -0,0 +1,10 @@
+--- include/vki/vki-scnums-openbsd.h.orig
include/vki/vki-scnums-openbsd.h
+@@ -146,6 +146,7 @@
+ #define __NR_pselect110
+ #define __NR_sigsuspend 111
+ #define __NR_sendsyslog 112
++#define __NR_unveil 114
+ #define __NR_getsockopt 118
+ #define __NR_thrkill119
+ #define __NR_readv 120
