回复: 回复: [NEW]databases/p5-SQL-Abstract-More
ping ... 发件人: owner-po...@openbsd.org 代表 wen heping 发送时间: 2019年11月6日 15:27 收件人: afre...@openbsd.org 抄送: ports@openbsd.org 主题: 回复: [NEW]databases/p5-SQL-Abstract-More Revised patch that add the missing TEST_DEPENDS. wen 发件人: Andrew Hewus Fresh 发送时间: 2019年9月21日 9:12 收件人: wen heping 抄送: ports@openbsd.org 主题: Re: [NEW]databases/p5-SQL-Abstract-More On Fri, Sep 06, 2019 at 01:08:07PM +, wen heping wrote: > Hi, ports@: > >Here is a patch to create new port databases/p5-SQL-Abstract-More, > which is required by the update of databases/p5-DBIx-DataModel. >Currently databases/p5-DBIx-DataModel failed with regression tests. > We shall update it and it will pass all the tests. > >It build well and passed all tests on amd64-head system. > > Comments? OK? > wen Appears to be missing a TEST_DEPENDS += devel/p5-Test-Deep With that, OK afresh1@
[Update] www/p5-HTTP-Date : Update to 6.03
Hi, Here is a simple patch for www/p5-HTTP-Date to update to 6.03. It build well and pass all tests on amd64-current system. There are 11 ports depends on www/p5-HTTP-Date, all build well and pass all tests. Comments? OK? wen Index: Makefile === RCS file: /cvs/ports/www/p5-HTTP-Date/Makefile,v retrieving revision 1.3 diff -u -p -r1.3 Makefile --- Makefile12 Jul 2019 20:50:55 - 1.3 +++ Makefile14 Nov 2019 03:18:57 - @@ -2,9 +2,9 @@ COMMENT = date conversion routines -DISTNAME = HTTP-Date-6.02 +DISTNAME = HTTP-Date-6.03 CATEGORIES = www -CPAN_AUTHOR = GAAS +CPAN_AUTHOR = OALDERS MAINTAINER = Nigel Taylor Index: distinfo === RCS file: /cvs/ports/www/p5-HTTP-Date/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- distinfo23 Oct 2014 19:26:44 - 1.1.1.1 +++ distinfo14 Nov 2019 03:18:57 - @@ -1,2 +1,2 @@ -SHA256 (HTTP-Date-6.02.tar.gz) = 6LmUHaD58MnAEGhAGl6BNB8ONwfRx1T44R9Cp+Yp4zM= -SIZE (HTTP-Date-6.02.tar.gz) = 7319 +SHA256 (HTTP-Date-6.03.tar.gz) = hHhWOsl7auMxCzFhVgDzfBynhXHcqv6DsMVIMxPZ3Ag= +SIZE (HTTP-Date-6.03.tar.gz) = 31224
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 23:55:13 Modified files: textproc/py-natsort: Makefile distinfo Log message: update to py-natsort-6.2.0
WANTLIB regen in x11/qt4
Simple diff which regen WANTLIB in qt4. To be on the safe side, more
eyes should check it.
- Clean up -mysql, s/mysqlclient_r/mariadb. Bump -mysql
- Remove "iconv intl" from commonWANTLIB. Bump -examples and -main
"make port-lib-depends-check" is happy with that again.
OK?
Index: Makefile
===
RCS file: /cvs/ports/x11/qt4/Makefile,v
retrieving revision 1.159
diff -u -p -u -p -r1.159 Makefile
--- Makefile12 Nov 2019 09:55:51 - 1.159
+++ Makefile13 Nov 2019 17:26:16 -
@@ -25,13 +25,13 @@ PKGNAME-main = qt4-${PKGVERSION}
PKGNAME-debug =qt4-debug-${PKGVERSION}
FULLPKGNAME-html = qt4-html-${PKGVERSION}
FULLPKGPATH-html = ${BASE_PKGPATH},-html
-REVISION-main =20
-REVISION-mysql = 6
+REVISION-main =21
+REVISION-mysql = 7
REVISION-postgresql = 6
REVISION-sqlite2 = 6
REVISION-tds = 6
REVISION-debug = 3
-REVISION-examples =7
+REVISION-examples =8
REVISION-html =3
# XXX qmake include parser is bogus
@@ -153,7 +153,7 @@ LIB_DEPENDS =
WANTLIB =
RUN_DEPENDS =
-commonWANTLIB =c pthread GL iconv intl m ${COMPILER_LIBCXX}
+commonWANTLIB =c pthread GL m ${COMPILER_LIBCXX}
sqlWANTLIB = m lib/qt4/QtCore>=4 QtSql ${COMPILER_LIBCXX} pthread
@@ -164,7 +164,7 @@ LIB_DEPENDS-main = ${LIB_DEPENDS} \
graphics/libmng \
multimedia/gstreamer-0.10/plugins-base \
graphics/png
-WANTLIB-main = ${commonWANTLIB} jpeg mng \
+WANTLIB-main = ${commonWANTLIB} iconv intl jpeg mng \
lcms tiff gobject-2.0 gstvideo-0.10 \
gstbase-0.10 gstreamer-0.10 xml2 \
gobject-2.0 gmodule-2.0 gstinterfaces-0.10 \
@@ -180,8 +180,7 @@ RUN_DEPENDS-main += textproc/icu4c
LIB_DEPENDS-mysql =${BUILD_PKGPATH} \
databases/mariadb
-WANTLIB-mysql =${sqlWANTLIB} \
- crypto ssl z mysqlclient_r
+WANTLIB-mysql =${sqlWANTLIB} mariadb
LIB_DEPENDS-postgresql =${BUILD_PKGPATH} \
Re: [poc][wip] sqlite3-tcl 3.30.1 + enable tests
Please keep them separate. Much easier to update either. If they were tied together and I wanted to update tcl-sqlite I'd have to spend a week testing and convincing. Also, tcl-sqlite isn't built with the same options as the main sqlite port. The tests would be nice but I'm not sure you're going down the right path; the amalgamation build is really the only sensible and mostly-guaranteed-to-work way to build sqlite. Stu -- Original Message -- From: Landry Breuil Date: November 9, 2019 at 9:55 AM Hi, sqlite3-tcl is a bit outdated compared to 'main' sqlite3, so im pondering moving back to the previous situation of having them as a single port with multipackages (which was the case before sqlite3 got imported into base) - and while here i hacked my way around to be able to run the tcl test suite. Right now its still running (and seems hung) but that allows to run those natively for each updates. - we need to switch to the -src tarball which is the only one containing tests - that requires horrible hacks to generate configure in the autoconf/tea subdir, + generate tclsqlite3.c wrapper. - that means rerunning configure/building in do-test as the WRKDIST dir changes so its a gross hack, more an interesting exercise in ports wrestling, but finally having sqlite tests. even if it doesnt build with the same options as the main sqlite3 port.. some of the SQLITE_ENABLE_XX choices look rather arbitrary. stu, an opinion about keeping it separate or not ? Landry
Re: [poc][wip] sqlite3-tcl 3.30.1 + enable tests
"some of the SQLITE_ENABLE_XX choices look rather arbitrary." Actually I spent some time carefully poring through all the options so I could provide the best sqlite possible for Tcl. Yeah, so separate please. Stu -- Original Message -- From: Landry Breuil Date: November 9, 2019 at 9:55 AM Hi, sqlite3-tcl is a bit outdated compared to 'main' sqlite3, so im pondering moving back to the previous situation of having them as a single port with multipackages (which was the case before sqlite3 got imported into base) - and while here i hacked my way around to be able to run the tcl test suite. Right now its still running (and seems hung) but that allows to run those natively for each updates. - we need to switch to the -src tarball which is the only one containing tests - that requires horrible hacks to generate configure in the autoconf/tea subdir, + generate tclsqlite3.c wrapper. - that means rerunning configure/building in do-test as the WRKDIST dir changes so its a gross hack, more an interesting exercise in ports wrestling, but finally having sqlite tests. even if it doesnt build with the same options as the main sqlite3 port.. some of the SQLITE_ENABLE_XX choices look rather arbitrary. stu, an opinion about keeping it separate or not ? Landry
Re: [poc][wip] sqlite3-tcl 3.30.1 + enable tests
Also I don't think this needs to be forced to build against 8.6. Sorry for all the messages, I'm just coming back after almost 2 years away ... whatever that means. Stu -- Original Message -- From: Landry Breuil Date: November 9, 2019 at 9:55 AM Hi, sqlite3-tcl is a bit outdated compared to 'main' sqlite3, so im pondering moving back to the previous situation of having them as a single port with multipackages (which was the case before sqlite3 got imported into base) - and while here i hacked my way around to be able to run the tcl test suite. Right now its still running (and seems hung) but that allows to run those natively for each updates. - we need to switch to the -src tarball which is the only one containing tests - that requires horrible hacks to generate configure in the autoconf/tea subdir, + generate tclsqlite3.c wrapper. - that means rerunning configure/building in do-test as the WRKDIST dir changes so its a gross hack, more an interesting exercise in ports wrestling, but finally having sqlite tests. even if it doesnt build with the same options as the main sqlite3 port.. some of the SQLITE_ENABLE_XX choices look rather arbitrary. stu, an opinion about keeping it separate or not ? Landry
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2019/11/13 19:58:15 Modified files: sysutils/firmware/intel: Tag: OPENBSD_6_6 Makefile distinfo sysutils/firmware/intel/pkg: Tag: OPENBSD_6_6 PLIST Log message: MFC intel ucode
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2019/11/13 19:54:35 Modified files: sysutils/firmware/intel: Makefile distinfo sysutils/firmware/intel/pkg: PLIST Log message: update intel microcode to 20191113 -- Updates upon 20191112 release -- Processor Identifier Version Products ModelStepping F-MO-S/PI Old->New new platforms updated platforms CFL-SP0 6-9e-c/22 00a2->00c6 Core Gen9 Desktop removed platforms NOTE: This microcode was previously incorrectly listed as both CFL-S (Desktop) and CFL-H (Mobile) and was removed from the 20191112 release. This processor is now correctly listed as CFL-S (Desktop) only.
[NEW] wiresep - privilege separated implementation of WireGuard
Hi all,
This is a port of my implementation of WireGuard.
I had some trouble with the following when creating the port:
1. I was not able to set "SEPARATE_BUILD = Yes", I get the error "cannot open
Makefile":
/usr/ports/net/wiresep/ $ make build
===> Verifying specs: c crypto
===> found c.95.1 crypto.45.5
===> Checking files for wiresep-0.8.2-rc.3
`/usr/ports/distfiles/wiresep-0.8.2-rc.3.tar.gz' is up to date.
>> (SHA256) wiresep-0.8.2-rc.3.tar.gz: OK
===> Extracting for wiresep-0.8.2-rc.3
===> Patching for wiresep-0.8.2-rc.3
===> Compiler link: clang -> /usr/bin/clang
===> Compiler link: clang++ -> /usr/bin/clang++
===> Compiler link: cc -> /usr/bin/cc
===> Compiler link: c++ -> /usr/bin/c++
===> Generating configure for wiresep-0.8.2-rc.3
===> Configuring for wiresep-0.8.2-rc.3
===> Building for wiresep-0.8.2-rc.3
make: cannot open Makefile.
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2800
'/usr/ports/pobj/wiresep-0.8.2-rc.3/build-amd64/.build_done')
*** Error 1 in /usr/ports/net/wiresep
(/usr/ports/infrastructure/mk/bsd.port.mk:2466 'build')
2. somehow `rcctl stop wiresep` does not execute my custom rc_stop
function in /etc/rc.d/wiresep
3. portcheck(1) issues "hardcoded paths detected in pkg/MESSAGE,
consider using SUBST_VARS and TRUEPREFIX/LOCALBASE/LOCALSTATEDIR/VARBASE"
When I try to replace "/usr/local" with ${TRUEPREFIX} it does not
get substituted and is displayed verbatim when the MESSAGE file is
displayed right after installing the package with `doas make install`.
Kind regards,
Tim
wiresep.tar.gz
Description: GNU Zip compressed data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/11/13 16:11:09 Modified files: astro/ansiweather: Makefile distinfo Log message: Update ansiweather to 1.15.0.
FIX: lang/flang/libpgmath on aarch64
Hi ports --
Without rehashing too much, flang broke libpgmath compilation with clang
in its aarch64-specific math routines a bit over a year ago. I reported
it then. It was found to be a bug in clang itself, which has not been
fixed. The code to work around the clang problems was extremely
invasive, and subsequently never committed to the flang repo. The work
around I used in the flang package for aarch64 was to use only the
generic math routines and not the aarch64-specific math routines on aarch64.
More recently, the flang people broke generic math routine only builds
of libpgmath, breaking the aarch64 build of libpgmath. I've given up
hope that libpgmath will build on aarch64 with clang in the short or
medium term. So let's switch to building libpgmath (and only libpgmath)
with egcc on aarch64. Not ideal, but it does work. Passes the NIST
Fortran-95 suite.
No change at all on amd64.
Diff here works on my RPi3B+. Any concerns I'm missing?
~Brian
Index: flang/patches/patch-runtime_flangrti_aarch64-Linux_dumpregs_c
===
RCS file: /cvs/ports/lang/flang/flang/patches/patch-runtime_flangrti_aarch64-Linux_dumpregs_c,v
retrieving revision 1.2
diff -u -p -r1.2 patch-runtime_flangrti_aarch64-Linux_dumpregs_c
--- flang/patches/patch-runtime_flangrti_aarch64-Linux_dumpregs_c 10 Nov 2019 16:50:32 - 1.2
+++ flang/patches/patch-runtime_flangrti_aarch64-Linux_dumpregs_c 13 Nov 2019 22:39:24 -
@@ -13,7 +13,7 @@ Index: runtime/flangrti/aarch64-Linux/du
#include
#include
#include
-@@ -29,6 +30,21 @@ typedef struct {
+@@ -29,12 +30,28 @@ typedef struct {
} xregs_t;
@@ -35,3 +35,15 @@ Index: runtime/flangrti/aarch64-Linux/du
/*
* The way the structure below is organized, the X registers are all
* sequential with no gaps - the structure is probably overkill - but
+ * allows for some flexibility.
+ */
+
++#ifndef __OpenBSD__
+ xregs_t xregs[] = {
+ { offsetof(mcontext_t, regs[0])/sizeof(uint64_t), "x0" },
+ { offsetof(mcontext_t, regs[1])/sizeof(uint64_t), "x1" },
+@@ -121,3 +138,4 @@ getRegs(ucontext_t *u)
+ mcontext_t *mc = >uc_mcontext;
+ return (uint64_t *)mc;
+ }
++#endif
Index: libpgmath/Makefile
===
RCS file: /cvs/ports/lang/flang/libpgmath/Makefile,v
retrieving revision 1.36
diff -u -p -r1.36 Makefile
--- libpgmath/Makefile 10 Nov 2019 16:50:32 - 1.36
+++ libpgmath/Makefile 13 Nov 2019 22:39:24 -
@@ -12,8 +12,17 @@ GH_COMMIT = cbadb27675c4681c8a77eef73c1f
WANTLIB += ${COMPILER_LIBCXX} m
-# REQUIRES a compiler that understands AVX-512F
+# Clang on amd64; gcc on aarch64 (XXX: monitor aarch64 situation)
+.if ${MACHINE_ARCH:Mamd64}
COMPILER = base-clang ports-clang
+.else
+COMPILER = ports-gcc
+
+# Attempt to prevent libstdc++ and libc++ symbol conflicts in the edge case
+# where you're on aarch64 and you are linking together both Fortran and C++
+# code into a single object.
+CONFIGURE_ARGS += -DCMAKE_SHARED_LINKER_FLAGS='-static-libstdc++ static-libgcc'
+.endif
MODULES = devel/cmake \
lang/python
@@ -23,12 +32,6 @@ BUILD_DEPENDS = devel/llvm
# If you delete flang, this should go too.
RUN_DEPENDS = lang/flang/driver
-
-# arm64-specific routines don't build with clang
-# (known upstream) so use the generic routines for now.
-.if ${MACHINE_ARCH:Maarch64}
-CONFIGURE_ARGS += -DLIBPGMATH_WITH_GENERIC=On
-.endif
WRKDIST = ${WRKDIR}/flang-${GH_COMMIT}/runtime/libpgmath
Index: libpgmath/patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/lang/flang/libpgmath/patches/patch-CMakeLists_txt,v
retrieving revision 1.5
diff -u -p -r1.5 patch-CMakeLists_txt
--- libpgmath/patches/patch-CMakeLists_txt 10 Nov 2019 16:50:32 - 1.5
+++ libpgmath/patches/patch-CMakeLists_txt 13 Nov 2019 22:39:24 -
@@ -3,7 +3,16 @@ $OpenBSD: patch-CMakeLists_txt,v 1.5 201
Index: CMakeLists.txt
--- CMakeLists.txt.orig
+++ CMakeLists.txt
-@@ -112,7 +112,7 @@ set(LIBPGMATH_TOOLS_DIR ${LIBPGMATH_BASE_DIR}/tools)
+@@ -86,8 +86,6 @@ if(CMAKE_C_COMPILER_ID STREQUAL "GNU" AND ${LIBPGMATH_
+ endif()
+
+ if(CMAKE_C_COMPILER_ID STREQUAL "GNU" AND ${LIBPGMATH_SYSTEM_PROCESSOR} MATCHES "aarch64")
+- string(REPLACE "-O2" "-O3 -finline-functions -funroll-loops" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
+- string(REPLACE "-O2" "-O3 -finline-functions -funroll-loops" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+ string(REPLACE "-std=c++11" "-std=gnu++11" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+ string(REPLACE "-fno-tree-vectorize" "-ftree-vectorize" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
+ string(REPLACE "-fno-tree-vectorize" "-ftree-vectorize" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+@@ -112,7 +110,7 @@ set(LIBPGMATH_TOOLS_DIR ${LIBPGMATH_BASE_DIR}/tools)
set(LIBPGMATH_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
set(LIBPGMATH_RUNTIME_PATH ${CMAKE_BINARY_DIR}/lib)
set(LIBPGMATH_LIBRARY_NAME
Re: new: opensmtpd clamav filter
I'll jump in since I wrote the other filters that aren't in C... November 13, 2019 7:04 AM, "Martijn van Duren" wrote: > [...] > > I do however dislike the trend that every single filters in ports not > written by me is in go. At first I thought this was to display the > flexibility of the smtpd-api (I even recollect it was said, but I can't > find the mail which states so). But it's restricting to OpenBSD users > not running on amd64, arm, or i386. > I was the one who said I'd write filters in !C to show that the stdin/stdout-based API was not tied to a specific language, and I didn't know this implied I could only use them in experiments but not to do actual useful things. Your comment that it is restricting is a bit off. What would be restricting is if I did not write them so that no OpenBSD users on any architecture would be able to use them. It is unfortunate that these features are not available to more but the cost of writing them in C was considerably higher and I might not have found time to write them at all. You are free to provide a portable replacement if this bothers you so much that these tools even exist in the first place. > Just yesterday there was someone who couldn't run a filter on sparc64 > because it was written in go[0]. If we as OpenBSD community value > portability over architectures these tools should be written in a > language that's just as portable. > Because I spend time writing something in a language does not mean that I'm willing to spend more time writing it in another. Even if written by me, Joerg, or whoever, these tools are _third-party_ addons written by individuals who worked on their own use-cases. I have no idea what Joerg did with his filter, it is not in OpenSMTPD and I've no use for Amavis. Eric probably did not look at my filter-senderscore, I doubt he is using it, others do. They're not in any OpenBSD/OpenSMTPD roadmap whatsoever and filter-rspamd exists only because I was bored on a week-end and motivated enough to start writing it. They are not shipped in base, they are not shipped with OpenSMTPD, they are not even in the portable repository, they are individual work. That you think this work should be done in a language is your opinion but as long as it's not in base and not even in the portable OpenSMTPD release I don't see why the language used for these is even to be debated. Yes, it would be better if sparc64 users could use them, so when you're bored on a week-end, write a replacement in C. > If you want to demonstrate the flexibility of the API write it in > something new like ruby, C++, or even PHP or awk for all I care. > If you care about portability please use one of these (although > PHP is currently not supported on HPPA). > No, sorry, but no. If I'm working on a side-project during my free time, you don't get to decide how I'm working on it. I'll write it in fucking brainfuck or asm if that's what I want to waste my spare time with. I picked Go because I wanted to see what made it so popular, I made SEVERAL projects with it and TWO of them are filters for which I've submitted packages as I thought that it was a nice thing to do. Goroutines and channels makes Go a pleasant choice to write filters so, wether you like it or not, I'll keep using it to handle MY very own use-cases until I find a better tool. If such tools are not wanted in ports, porters can just tell me and I'll stop packaging them with no hard feelings. > Maybe you could give libopensmtpd a go (pun intended). I reckon > it's not hard to use. > Because I spend time writing something in a language does not mean that I'm willing to write it in another. Some filters I write in C, others I don't. libopensmtpd as of today may be portable to multiple archs but it isn't portable to other systems so if I use it today, I can write filters for OpenBSD/sparc64 but no longer for Linux, FreeBSD or OSX. The fact that I can write filters portable to other systems today means that a much larger community of users is now reporting bugs, and caused three bugs to be fixed in CVS. Had I not written these filters in Go we would not have had these reports. If you want more coverage, write alternatives.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 13:53:32 Modified files: net/mosquitto : Makefile distinfo net/mosquitto/patches: patch-lib_CMakeLists_txt patch-lib_mosquitto_c patch-mosquitto_conf patch-src_CMakeLists_txt net/mosquitto/pkg: PLIST Removed files: net/mosquitto/patches: patch-CMakeLists_txt patch-lib_cpp_CMakeLists_txt patch-src_handle_connect_c patch-test_Makefile patch-test_broker_c_Makefile patch-test_lib_c_Makefile patch-test_lib_cpp_Makefile Log message: update to mosquitto-1.6.7
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 13:13:39 Modified files: net/py-netmiko : Makefile distinfo net/py-netmiko/pkg: PLIST Log message: - update to py-netmiko-2.4.2 - add missing RDEPs for python2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 13:12:47 Modified files: security/py-cryptodome: Makefile distinfo security/py-cryptodome/pkg: PLIST Log message: update to py-cryptodome-3.9.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 13:13:20 Modified files: textproc/py-natsort: Makefile textproc/py-natsort/pkg: PLIST Log message: fix PLIST from previous
Re: new: opensmtpd clamav filter
On 2019/11/13 16:39, Pascal Stumpf wrote: > On Wed, 13 Nov 2019 13:25:17 +0100, Tim Kuijsten wrote: > > "Theo de Raadt" wrote: > > > I'll add my voice to this. > > > > > > The powerful vendors writing new languages must expand their breath, > > > or face the consequences that some software is not going to get written > > > in their languages. Better is very much muted by unportable. > > > > What about gccgo? It supports more architectures than the standard Go > > compiler, is written and maintained by one of the core developers of > > the language and exists since the inception of Go[1]. > > gccgo is even worse because it relies on the (deprecated and utterly > unportable) setcontext() family of functions. Oh not this one again. Call it out because the interface is horrible and the makecontext definition relies on a pre-ISO C "feature", but it's widely enough supported (SunOS, HP/UX, AIX, IRIX, Linux, NetBSD, FreeBSD, MacOS) that "utterly unportable" is really a stretch.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 13:04:26 Modified files: math/py-graphviz: Makefile distinfo Log message: update to py-graphviz-0.13.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 13:04:36 Modified files: textproc/py-natsort: Makefile distinfo textproc/py-natsort/pkg: PLIST Log message: update to py-natsort-6.1.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 12:38:39 Modified files: www/sassc : Makefile www/libsass: Makefile Log message: add debug packages
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 12:21:50 Modified files: net/gupnp/av : Makefile net/gupnp/av/pkg: PLIST net/gupnp/core : Makefile net/gupnp/dlna : Makefile net/gupnp/dlna/pkg: PLIST net/gupnp/igd : Makefile net/gupnp/igd/pkg: PLIST net/gupnp/tools: Makefile Log message: - provide debug packages for the gupnp bits - regen WANTLIB
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 11:52:03 Modified files: lang/elixir: Makefile distinfo Log message: update to elixir-1.9.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 11:33:08 Modified files: devel/libgtop2 : Makefile devel/libgtop2/pkg: PLIST Log message: add debug-libgtop2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/11/13 11:23:19 Modified files: devel/iso-codes: Makefile distinfo devel/iso-codes/pkg: PLIST Log message: update to iso-codes-4.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/11/13 10:41:22 Modified files: devel/frama-c : Makefile Log message: put BROKEN-i386 back
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2019/11/13 10:05:35 Modified files: sysutils/diffoscope: Makefile distinfo sysutils/diffoscope/pkg: PLIST Log message: Update to diffoscope-129
Re: new: opensmtpd clamav filter
> On 13. Nov 2019, at 16:59, Ingo Schwarze wrote: > > Strictly speaking, martijn@ is right. Thanks for the elaborations and clarification. I will adjust that with the next release. >> is just not very readable and multiple arguments have always >> non-optional predecessors anyways. > > Absolutely not. That is clearly not true, see the examples above. I think we misunderstood here. I meant plain simple arguments and not -options or key=value pairs. You can not distinguish between plain arbitrary string arguments which can have any value without respecting the order, so an predecessor is necessary (non-optional) in my example for the limit: filter-clamav “value1" is “value1" the limit or the address? By design it is defined to be the address, because first argument. Second argument is limit and limit can never be without (even empty “") first address argument predecessor, because the string values are not distinguishable from each other, except through argument position. That might be poor design, in particular with more arguments and depending on the argument intentions. But this is very simple to implement (in most languages) and I don’t plan to add any further arguments anyways. In fact, I’m thinking of getting rid of the second argument by setting a reasonable default limit ;) > Admittedly, this is a fringe issue for a port and shouldn't > hinder importing. Yes, I really not expected to defend my choice of language or the 120 lines of code in a review here, before importing ;) >> But I'm not a manpage syntax expert, >> maybe Ingo or jmc can chime in and correct me to be wrong here. > > At your service. ;-) Thanks!!!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/11/13 09:16:52 Modified files: infrastructure/bin: build-debug-info Log message: clean-up (put stuff into self, not state) inherit from BaseFS, so that dest/undest/resolve_link can happen
Re: new: opensmtpd clamav filter
Hi Joerg, Joerg Jung wrote on Wed, Nov 13, 2019 at 02:55:17PM +0100: > martijn@ wrote: >> Also the manpage is incorrect. It states [address] [limit], while >> if you want to limit the address is non-optional (from reading the >> code). So this should be [address [limit]]. Strictly speaking, martijn@ is right. Per convention in manual pages, [...] [...] means that you can given none, or either of them, or both, while [... [...]] means that you can give none, or the first, or both, but not the second alone. Examples of [...] [...] with the meaning explained above include atrm(1), cal(1), grep(1), lpq(1), lprm(1), nc(1), systat(1), ... In such cases, often the syntax of both arguments is sufficiently different that it's clear which one is intended when only one is given (for example, a number vs. a string of letters); in other cases, the first argument can be left out when a certain option is specified, like grep(1) -e or nc(1) -l. That said, synopses sometimes cannot be absolutely precise without becoming excessively complicated. But i don't think there is a problem of that kind here. > I don't think that this is incorrect, but a rather common idiom found > in other man pages as well, because: >foo [bar [baz [bat [ban [address [limit]] I don't buy that argument. On the one hand, taking six arguments in a fixed order would seem pretty poor UI design to me. Usually, making them option arguments like foo [-a bar] [-b baz] [-c bat] [-d ban] [address [limit]] would be better UI design because it wouldn't force you to repeat all the defaults just to be able to specify a limit - and it wouldn't force users to learn the order. Besides, i quickly looked through /usr/share/man/man1/ and failed to find a single example where [...] [...] is used but [... [...]] is intended. Admittedly, i might have missed one, but it certainly doesn't look like a common idiom to me. On the other hand, i quickly found several examples of [... [...]]: cmp(1), colrm(1), gprof(1), ksh(1), patch(1), rs(1), split(1), su(1), tmux(1), tradcpp(1), xargs(1), ... > is just not very readable and multiple arguments have always > non-optional predecessors anyways. Absolutely not. That is clearly not true, see the examples above. > But I'm not a manpage syntax expert, > maybe Ingo or jmc can chime in and correct me to be wrong here. At your service. ;-) Admittedly, this is a fringe issue for a port and shouldn't hinder importing. I'm also slightly concerned about large corporations promoting non-portable software and languages and the possibly resulting vendor-lockin, but i'm not a language expert, so my opinion doesn't mean all that much in that respect. I don't doubt the argument, though, that portability ought to be *considered* when making decisions about tools to be used. Either way, even having chosen a poorly-portable language should not hinder committing a port; sometimes, even non-free software gets ported, after all. I can't comment on the port itself. Yours, Ingo
Re: new: opensmtpd clamav filter
On Wed, 13 Nov 2019 13:25:17 +0100, Tim Kuijsten wrote: > "Theo de Raadt" wrote: > > I'll add my voice to this. > > > > The powerful vendors writing new languages must expand their breath, > > or face the consequences that some software is not going to get written > > in their languages. Better is very much muted by unportable. > > What about gccgo? It supports more architectures than the standard Go > compiler, is written and maintained by one of the core developers of > the language and exists since the inception of Go[1]. gccgo is even worse because it relies on the (deprecated and utterly unportable) setcontext() family of functions. > (Note: I only learned about the existence of the different compilers > last night when I was researching a bit and evaluating whether or not I > should try Go) > > [1] https://commandcenter.blogspot.com/2017/09/go-ten-years-and-climbing.html >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/11/13 08:26:47 Modified files: graphics/xfig : Makefile distinfo graphics/xfig/patches: patch-src_d_text_c graphics/xfig/pkg: PLIST Removed files: graphics/xfig/patches: patch-e_chop_c patch-w_intersect_c patch-w_keyboard_c patch-w_snap_c Log message: Update xfig to 3.2.7b. We can now drop all patches for the includes. OK rsadowski@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/11/13 08:24:11 Modified files: print/transfig : Makefile distinfo print/transfig/patches: patch-fig2dev_Makefile_in patch-fig2dev_fig2dev_c print/transfig/pkg: PLIST Log message: Update transfig to 3.2.7b. This fixes CVE-2018-16140 and CVE-2019-14275. Since version 3.2.7a, the X bitmaps files are not installed anymore. >From upstream CHANGES: o Distribute the X bitmaps files within fig2dev, no need to install these files. The files were needed for Tk and Perl/Tk output. OK rsadowski@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/11/13 08:22:41 Modified files: infrastructure/bin: build-debug-info infrastructure/mk: bsd.port.mk Log message: tweak call, some options are not needed, passing PORTSDIR will be necessary to grab other code. also error out when file writing breaks.
Re: [base-gcc] Unbreak devel/libpeas
On Wed, Nov 13, 2019 at 03:43:41PM +0100, Charlene Wendling wrote:
> On Wed, 13 Nov 2019 13:41:13 +
> Stuart Henderson wrote:
>
> > On 2019/11/13 14:11, Charlene Wendling wrote:
> > >
> > > > http://build-failures.rhaalovely.net/sparc64/2019-11-08/devel/libpeas.log
> > >
> > > It's broken since the latest update.
> > >
> > > I did the same thing as i did with vte3, i just added an extra
> > > LDFLAG for ld.bfd archs and it builds on macppc [0]. REVISION bump
> > > is unneeded, this version never built on these archs.
> > >
> > > As i will also send a diff for libgweather, please note that fixing
> > > those two will unlock a lot of gnome-related ports. Many will be
> > > broken due to base-gcc being used by default for x11/gnome/*, and
> > > gnome using C99/C11 constructs. That could be fixed if COMPILER was
> > > set the same way x11/qt5 does across gnome ports.
> > >
> > >
> > > Comments/feedback are welcome,
> > >
> > > Charlène.
> > >
> > >
> > > [0] https://bin.charlenew.xyz/libpeas.log
> > >
> > >
> > > Index: Makefile
> > > ===
> > > RCS file: /cvs/ports/devel/libpeas/Makefile,v
> > > retrieving revision 1.65
> > > diff -u -p -u -p -r1.65 Makefile
> > > --- Makefile 1 Nov 2019 19:44:13 - 1.65
> > > +++ Makefile 13 Nov 2019 12:52:42 -
> > > @@ -43,4 +43,10 @@ BUILD_DEPENDS +=lang/python/${MODPY_DEFA
> > > RUN_DEPENDS += lang/python/${MODPY_DEFAULT_VERSION_2} \
> > > devel/py-gobject3
> > >
> > > +# Fix X11-related undefined references errors on ld.bfd archs
> > > +.include
> > > +.if !${PROPERTIES:Mlld}
> > > +MODGNOME_LDFLAGS += -L${X11BASE}/lib
> > > +.endif
> > > +
> > > .include
> > >
> >
> > Any idea why it's happening (or why it's not needed for LLD)?
>
> Short answer: no.
>
> I _suspect_ that on ld.bfd side, -rpath and --*group flags are
> misbehaving, it's the common point between all these linker related
> failures on the 3 ld.bfd archs we build packages for.
>
> This is definitely not meson-related, see how rspamd fails on
> powerpc [1] once COMPILER is properly set.
>
> That's why i'm proposing this kind of change only on ports that have a
> fair number of rdeps.
>
> > I don't really like adding this across the tree, I think I'd be
> > happier with adding it in the module (probably unconditionally
> > because I don't think bsd.port.arch.mk is safe to add there) if that
> > doesn't cause other problems ...
>
> Agreed. On that point it's up to Antoine, i've built and run gnome
> months ago on powerpc [2], so i think it's worth it.
By "unconditionally", you mean unconditionally for legacy arches?
If so then sure, I don't care :-)
--
Antoine
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/11/13 07:50:45 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: Register firewalk removal.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/11/13 07:49:29 Modified files: net: Makefile Removed files: net/firewalk : Makefile distinfo net/firewalk/patches: patch-Makefile_in patch-firewalk_c patch-ifaddrlist_c patch-listener_c patch-main_c patch-p_cap_h patch-packet_c patch-udptcpwalk_c net/firewalk/pkg: DESCR PLIST Log message: Remove net/firewalk. The port hasn't been updated since 1999, despite the fact new versions have been released, up to version 5.0 in 2002. The version we have does not work anymore, it doesn't recognize any network interface, even when specifying them manually with the -i switch. OK kmos@, jca@, ajacoutot@
Re: [base-gcc] Unbreak devel/libpeas
On Wed, 13 Nov 2019 13:41:13 +
Stuart Henderson wrote:
> On 2019/11/13 14:11, Charlene Wendling wrote:
> >
> > > http://build-failures.rhaalovely.net/sparc64/2019-11-08/devel/libpeas.log
> >
> > It's broken since the latest update.
> >
> > I did the same thing as i did with vte3, i just added an extra
> > LDFLAG for ld.bfd archs and it builds on macppc [0]. REVISION bump
> > is unneeded, this version never built on these archs.
> >
> > As i will also send a diff for libgweather, please note that fixing
> > those two will unlock a lot of gnome-related ports. Many will be
> > broken due to base-gcc being used by default for x11/gnome/*, and
> > gnome using C99/C11 constructs. That could be fixed if COMPILER was
> > set the same way x11/qt5 does across gnome ports.
> >
> >
> > Comments/feedback are welcome,
> >
> > Charlène.
> >
> >
> > [0] https://bin.charlenew.xyz/libpeas.log
> >
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/devel/libpeas/Makefile,v
> > retrieving revision 1.65
> > diff -u -p -u -p -r1.65 Makefile
> > --- Makefile1 Nov 2019 19:44:13 - 1.65
> > +++ Makefile13 Nov 2019 12:52:42 -
> > @@ -43,4 +43,10 @@ BUILD_DEPENDS +=lang/python/${MODPY_DEFA
> > RUN_DEPENDS += lang/python/${MODPY_DEFAULT_VERSION_2} \
> > devel/py-gobject3
> >
> > +# Fix X11-related undefined references errors on ld.bfd archs
> > +.include
> > +.if !${PROPERTIES:Mlld}
> > +MODGNOME_LDFLAGS +=-L${X11BASE}/lib
> > +.endif
> > +
> > .include
> >
>
> Any idea why it's happening (or why it's not needed for LLD)?
Short answer: no.
I _suspect_ that on ld.bfd side, -rpath and --*group flags are
misbehaving, it's the common point between all these linker related
failures on the 3 ld.bfd archs we build packages for.
This is definitely not meson-related, see how rspamd fails on
powerpc [1] once COMPILER is properly set.
That's why i'm proposing this kind of change only on ports that have a
fair number of rdeps.
> I don't really like adding this across the tree, I think I'd be
> happier with adding it in the module (probably unconditionally
> because I don't think bsd.port.arch.mk is safe to add there) if that
> doesn't cause other problems ...
Agreed. On that point it's up to Antoine, i've built and run gnome
months ago on powerpc [2], so i think it's worth it.
Charlène.
[1] https://bin.charlenew.xyz/rspamd.log
[2] https://bsd.network/@julianaito/102065676125440442
Re: CVS: cvs.openbsd.org: ports
On Tue, Nov 12, 2019 at 02:55:52AM -0700, Theo Buehler wrote: > CVSROOT: /cvs > Module name: ports > Changes by: t...@cvs.openbsd.org2019/11/12 02:55:52 > > Modified files: > x11/qt4: Makefile > x11/qt4/patches: >patch-src_network_ssl_qsslsocket_openssl_symbols_p_h > > Log message: > Fix symbol lookup that I screwed up when I last had to touch this mess: > > W:QSslSocket: cannot call unresolved function X509_getm_notBefore > Segmentation fault (core dumped) > > Reproducer, test & ok rsadowski > also ok jca sthen (after I double checked thta the header is private)
Re: new: opensmtpd clamav filter
On Tue, Nov 12, 2019 at 11:13:36PM -0700, Theo de Raadt wrote: > I'll add my voice to this. > > The powerful vendors writing new languages must expand their breath, > or face the consequences that some software is not going to get written > in their languages. Better is very much muted by unportable. I agree with that, but believe this discussion has gone a bit sideways and does not belong to ports@ > > I do however dislike the trend that every single filters in ports not > > written by me is in go. 2 out of 3 devs decided to write some of their filters in Go, I would not call that a "trend" yet. > > At first I thought this was to display the > > flexibility of the smtpd-api (I even recollect it was said, but I can't > > find the mail which states so). Showing the flexibility of the API is/was not my goal. > > But it's restricting to OpenBSD users > > not running on amd64, arm, or i386. > > Just yesterday there was someone who couldn't run a filter on sparc64 > > because it was written in go[0]. I know, I've seen and read that thread. > > If we as OpenBSD community value > > portability over architectures these tools should be written in a > > language that's just as portable. While I mostly agree to that, the decision which language I choose to write and maintain my tools in is still: _mine_. Back in Dec 2018, when I wrote and released my first tiny filter, I've chosen Go for good and valid reasons. I will not start to defend my decision nor Go here, since this is not my first preferred native main language and I also dislike it's restrictions. But let me just add: I strongly believe into choose the right tools/language for the jobs and the Goroutines just fit very well into the async programming model of the filters API. > > If you want to demonstrate the flexibility of the API write it in I didn't wrote my filters for PoC of API or to test flexibility or something, but for real world usage. In fact I run my filters on some high traffic mail servers. > > something new like ruby, C++, or even PHP or awk for all I care. > > If you care about portability please use one of these (although > > PHP is currently not supported on HPPA). Personally, I won't run a filter in Ruby or PHP on a high traffic mail server. I needed something simple, small, fast, and compiled. Also, I have not seen a large mail server running on a sparc for years. > > Maybe you could give libopensmtpd a go (pun intended). I reckon > > it's not hard to use. I looked into it, but IMHO it's over-engineered containing way too much code for simple and tiny filter tasks. While I like the approach to make everything as re-usable and generic as possible, it is not always the best choice. cloc tells me 3300 lines of code just for the library and another 230 lines for filter-dnsbl. In contrast my own filter-dnsbl(.go) has just 120 lines and even has support for whitelists (like DNSWL.org). Your library also seems to be written for OpenBSD only, and does not seem to be _portable_ to Linux or other (you see the irony eeh?). In contrast again: my own filters do also work with OpenSMTPD-portable, which I personally consider important. > > Also the manpage is incorrect. It states [address] [limit], while > > if you want to limit the address is non-optional (from reading the > > code). So this should be [address [limit]]. I don't think that this is incorrect, but a rather common idiom found in other man pages as well, because: foo [bar [baz [bat [ban [address [limit]] is just not very readable and multiple arguments have always non-optional predecessors anyways. But I'm not a manpage syntax expert, maybe Ingo or jmc can chime in and correct me to be wrong here. > > Also I don't like this syntax, because it gets confusing if the > > amount of arguments grows (not saying it will happen here, just > > bad practice). I'd rather see this as [-s address] [-l limit]. You can choose whatever syntax you like in your own filters. In fact multiple OpenBSD base tools use this syntax, think of all the *ctl commands like relayctl. Please, can we get back to the actual port, anyone tested it? OK to import? > > On 11/13/19 1:32 AM, Joerg Jung wrote: > > > Hi, > > > > > > please find attached a port for opensmtpd filter-clamav. > > > > > > Comments, OKs? > > > > > > Thanks, > > > Regards, > > > Joerg > > > > >
Re: [base-gcc] Unbreak devel/libpeas
On 2019/11/13 14:11, Charlene Wendling wrote:
>
> > http://build-failures.rhaalovely.net/sparc64/2019-11-08/devel/libpeas.log
>
> It's broken since the latest update.
>
> I did the same thing as i did with vte3, i just added an extra LDFLAG
> for ld.bfd archs and it builds on macppc [0]. REVISION bump is unneeded,
> this version never built on these archs.
>
> As i will also send a diff for libgweather, please note that fixing
> those two will unlock a lot of gnome-related ports. Many will be broken
> due to base-gcc being used by default for x11/gnome/*, and gnome using
> C99/C11 constructs. That could be fixed if COMPILER was set the same way
> x11/qt5 does across gnome ports.
>
>
> Comments/feedback are welcome,
>
> Charlène.
>
>
> [0] https://bin.charlenew.xyz/libpeas.log
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/libpeas/Makefile,v
> retrieving revision 1.65
> diff -u -p -u -p -r1.65 Makefile
> --- Makefile 1 Nov 2019 19:44:13 - 1.65
> +++ Makefile 13 Nov 2019 12:52:42 -
> @@ -43,4 +43,10 @@ BUILD_DEPENDS +=lang/python/${MODPY_DEFA
> RUN_DEPENDS += lang/python/${MODPY_DEFAULT_VERSION_2} \
> devel/py-gobject3
>
> +# Fix X11-related undefined references errors on ld.bfd archs
> +.include
> +.if !${PROPERTIES:Mlld}
> +MODGNOME_LDFLAGS += -L${X11BASE}/lib
> +.endif
> +
> .include
>
Any idea why it's happening (or why it's not needed for LLD)?
I don't really like adding this across the tree, I think I'd be happier
with adding it in the module (probably unconditionally because I don't
think bsd.port.arch.mk is safe to add there) if that doesn't cause
other problems ...
[base-gcc] Unbreak devel/libpeas
> http://build-failures.rhaalovely.net/sparc64/2019-11-08/devel/libpeas.log
It's broken since the latest update.
I did the same thing as i did with vte3, i just added an extra LDFLAG
for ld.bfd archs and it builds on macppc [0]. REVISION bump is unneeded,
this version never built on these archs.
As i will also send a diff for libgweather, please note that fixing
those two will unlock a lot of gnome-related ports. Many will be broken
due to base-gcc being used by default for x11/gnome/*, and gnome using
C99/C11 constructs. That could be fixed if COMPILER was set the same way
x11/qt5 does across gnome ports.
Comments/feedback are welcome,
Charlène.
[0] https://bin.charlenew.xyz/libpeas.log
Index: Makefile
===
RCS file: /cvs/ports/devel/libpeas/Makefile,v
retrieving revision 1.65
diff -u -p -u -p -r1.65 Makefile
--- Makefile1 Nov 2019 19:44:13 - 1.65
+++ Makefile13 Nov 2019 12:52:42 -
@@ -43,4 +43,10 @@ BUILD_DEPENDS +=lang/python/${MODPY_DEFA
RUN_DEPENDS += lang/python/${MODPY_DEFAULT_VERSION_2} \
devel/py-gobject3
+# Fix X11-related undefined references errors on ld.bfd archs
+.include
+.if !${PROPERTIES:Mlld}
+MODGNOME_LDFLAGS +=-L${X11BASE}/lib
+.endif
+
.include
Re: unbreak tls in Qt4
On Wed, Nov 13, 2019 at 12:14:38PM +, Stuart Henderson wrote: > On 2019/11/12 10:37, Rafael Sadowski wrote: > > > > The diff is part of qtnetwork which is part of -main, so we just need > > the bump -main. With this, OK rsadowski@ > > As long as you are certain nothing else pulls in this header. > (If in doubt, bump) I think we're good with just a bump of -main. It's a private header of qtnetwork and there are no occurrences of the string qsslsocket_openssl outside of it (except from translations and the changelog): $ ag -l qsslsocket_openssl /usr/ports/pobj/qt4-4.8.7/qt-everywhere-opensource-src-4.8.7 include/QtNetwork/headers.pri include/QtNetwork/private/qsslsocket_openssl_symbols_p.h include/QtNetwork/private/qsslsocket_openssl_p.h translations/qt_sv.ts translations/qt_da.ts translations/qt_hu.ts translations/qt_zh_CN.ts translations/qt_pt.ts translations/qt_zh_TW.ts translations/qt_es.ts src/network/ssl/qsslcertificate.cpp src/network/ssl/qsslsocket_openssl.cpp src/network/ssl/qsslsocket_openssl_symbols_p.h src/network/ssl/ssl.pri src/network/ssl/qsslkey.cpp src/network/ssl/qsslsocket_openssl_symbols.cpp src/network/ssl/qsslsocket.cpp src/network/ssl/qsslsocket_openssl_p.h changes-4.8.7 > > > > Thanks! > > > > > > > > # XXX qmake include parser is bogus > > > DPB_PROPERTIES = parallelnojunk > > > Index: patches/patch-src_network_ssl_qsslsocket_openssl_symbols_p_h > > > === > > > RCS file: > > > /var/cvs/ports/x11/qt4/patches/patch-src_network_ssl_qsslsocket_openssl_symbols_p_h,v > > > retrieving revision 1.1 > > > diff -u -p -r1.1 patch-src_network_ssl_qsslsocket_openssl_symbols_p_h > > > --- patches/patch-src_network_ssl_qsslsocket_openssl_symbols_p_h 27 Aug > > > 2018 03:54:57 - 1.1 > > > +++ patches/patch-src_network_ssl_qsslsocket_openssl_symbols_p_h 11 Nov > > > 2019 20:07:24 - > > > @@ -3,14 +3,23 @@ $OpenBSD: patch-src_network_ssl_qsslsock > > > Index: src/network/ssl/qsslsocket_openssl_symbols_p.h > > > --- src/network/ssl/qsslsocket_openssl_symbols_p.h.orig > > > +++ src/network/ssl/qsslsocket_openssl_symbols_p.h > > > -@@ -410,8 +410,8 @@ DSA *q_d2i_DSAPrivateKey(DSA **a, unsigned char > > > **pp, > > > +@@ -360,6 +360,8 @@ int q_X509_get_ext_count(X509 *a); > > > + void *q_X509_get_ext_d2i(X509 *a, int b, int *c, int *d); > > > + X509_NAME *q_X509_get_issuer_name(X509 *a); > > > + X509_NAME *q_X509_get_subject_name(X509 *a); > > > ++ASN1_TIME *q_X509_getm_notBefore(const X509 *x); > > > ++ASN1_TIME *q_X509_getm_notAfter(const X509 *x); > > > + int q_X509_verify_cert(X509_STORE_CTX *ctx); > > > + int q_X509_NAME_entry_count(X509_NAME *a); > > > + X509_NAME_ENTRY *q_X509_NAME_get_entry(X509_NAME *a,int b); > > > +@@ -410,8 +412,8 @@ DSA *q_d2i_DSAPrivateKey(DSA **a, unsigned char > > > **pp, > > > #define q_sk_SSL_CIPHER_value(st, i) q_SKM_sk_value(SSL_CIPHER, (st), > > > (i)) > > > #define q_SSL_CTX_add_extra_chain_cert(ctx,x509) \ > > > q_SSL_CTX_ctrl(ctx,SSL_CTRL_EXTRA_CHAIN_CERT,0,(char *)x509) > > > -#define q_X509_get_notAfter(x) X509_get_notAfter(x) > > > -#define q_X509_get_notBefore(x) X509_get_notBefore(x) > > > -+#define q_X509_getm_notAfter(x) X509_getm_notAfter(x) > > > -+#define q_X509_getm_notBefore(x) X509_getm_notBefore(x) > > > ++#define q_X509_getm_notAfter(x) q_X509_getm_notAfter(x) > > > ++#define q_X509_getm_notBefore(x) q_X509_getm_notBefore(x) > > > #define q_EVP_PKEY_assign_RSA(pkey,rsa) > > > q_EVP_PKEY_assign((pkey),EVP_PKEY_RSA,\ > > > (char *)(rsa)) > > > #define q_EVP_PKEY_assign_DSA(pkey,dsa) > > > q_EVP_PKEY_assign((pkey),EVP_PKEY_DSA,\ > >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/11/13 05:50:39 Modified files: www/sogo : Makefile distinfo www/sogo/pkg : PLIST Log message: Update 4.0.8 -> 4.1.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2019/11/13 05:50:01 Modified files: www/sope : Makefile distinfo Log message: Update 4.0.8 -> 4.1.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2019/11/13 05:43:49 Modified files: x11/kde4 : Makefile.inc Log message: s/stable/Attic/ in MASTER_SITES
Re: new: opensmtpd clamav filter
"Theo de Raadt" wrote: > I'll add my voice to this. > > The powerful vendors writing new languages must expand their breath, > or face the consequences that some software is not going to get written > in their languages. Better is very much muted by unportable. What about gccgo? It supports more architectures than the standard Go compiler, is written and maintained by one of the core developers of the language and exists since the inception of Go[1]. (Note: I only learned about the existence of the different compilers last night when I was researching a bit and evaluating whether or not I should try Go) [1] https://commandcenter.blogspot.com/2017/09/go-ten-years-and-climbing.html
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/11/13 05:18:10 Modified files: net/dhcpcd : Makefile distinfo Removed files: net/dhcpcd/patches: patch-src_dhcp6_c Log message: update to dhcpcd-8.1.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/11/13 05:17:21 Modified files: net/rsync : Makefile Log message: debug info for rsync
Re: unbreak tls in Qt4
On 2019/11/12 10:37, Rafael Sadowski wrote: > > The diff is part of qtnetwork which is part of -main, so we just need > the bump -main. With this, OK rsadowski@ As long as you are certain nothing else pulls in this header. (If in doubt, bump) > Thanks! > > > > > # XXX qmake include parser is bogus > > DPB_PROPERTIES = parallelnojunk > > Index: patches/patch-src_network_ssl_qsslsocket_openssl_symbols_p_h > > === > > RCS file: > > /var/cvs/ports/x11/qt4/patches/patch-src_network_ssl_qsslsocket_openssl_symbols_p_h,v > > retrieving revision 1.1 > > diff -u -p -r1.1 patch-src_network_ssl_qsslsocket_openssl_symbols_p_h > > --- patches/patch-src_network_ssl_qsslsocket_openssl_symbols_p_h27 Aug > > 2018 03:54:57 - 1.1 > > +++ patches/patch-src_network_ssl_qsslsocket_openssl_symbols_p_h11 Nov > > 2019 20:07:24 - > > @@ -3,14 +3,23 @@ $OpenBSD: patch-src_network_ssl_qsslsock > > Index: src/network/ssl/qsslsocket_openssl_symbols_p.h > > --- src/network/ssl/qsslsocket_openssl_symbols_p.h.orig > > +++ src/network/ssl/qsslsocket_openssl_symbols_p.h > > -@@ -410,8 +410,8 @@ DSA *q_d2i_DSAPrivateKey(DSA **a, unsigned char **pp, > > +@@ -360,6 +360,8 @@ int q_X509_get_ext_count(X509 *a); > > + void *q_X509_get_ext_d2i(X509 *a, int b, int *c, int *d); > > + X509_NAME *q_X509_get_issuer_name(X509 *a); > > + X509_NAME *q_X509_get_subject_name(X509 *a); > > ++ASN1_TIME *q_X509_getm_notBefore(const X509 *x); > > ++ASN1_TIME *q_X509_getm_notAfter(const X509 *x); > > + int q_X509_verify_cert(X509_STORE_CTX *ctx); > > + int q_X509_NAME_entry_count(X509_NAME *a); > > + X509_NAME_ENTRY *q_X509_NAME_get_entry(X509_NAME *a,int b); > > +@@ -410,8 +412,8 @@ DSA *q_d2i_DSAPrivateKey(DSA **a, unsigned char **pp, > > #define q_sk_SSL_CIPHER_value(st, i) q_SKM_sk_value(SSL_CIPHER, (st), (i)) > > #define q_SSL_CTX_add_extra_chain_cert(ctx,x509) \ > > q_SSL_CTX_ctrl(ctx,SSL_CTRL_EXTRA_CHAIN_CERT,0,(char *)x509) > > -#define q_X509_get_notAfter(x) X509_get_notAfter(x) > > -#define q_X509_get_notBefore(x) X509_get_notBefore(x) > > -+#define q_X509_getm_notAfter(x) X509_getm_notAfter(x) > > -+#define q_X509_getm_notBefore(x) X509_getm_notBefore(x) > > ++#define q_X509_getm_notAfter(x) q_X509_getm_notAfter(x) > > ++#define q_X509_getm_notBefore(x) q_X509_getm_notBefore(x) > > #define q_EVP_PKEY_assign_RSA(pkey,rsa) > > q_EVP_PKEY_assign((pkey),EVP_PKEY_RSA,\ > > (char *)(rsa)) > > #define q_EVP_PKEY_assign_DSA(pkey,dsa) > > q_EVP_PKEY_assign((pkey),EVP_PKEY_DSA,\ >
[ports-gcc] Unbreak graphics/openimageio
Hi!
The port is BROKEN-powerpc due to libatomic not being linked, so i fixed
that already, but then met:
> http://build-failures.rhaalovely.net/sparc64/2019-11-08/graphics/openimageio.log
This is just a missing header.
I have been able to build openimageio on macppc [0] with these fixes,
without breaking amd64.
Comments/feedback are welcome,
Charlène.
[0] https://bin.charlenew.xyz/openimageio.log
Index: Makefile
===
RCS file: /cvs/ports/graphics/openimageio/Makefile,v
retrieving revision 1.37
diff -u -p -u -p -r1.37 Makefile
--- Makefile10 Nov 2019 15:32:55 - 1.37
+++ Makefile13 Nov 2019 10:16:20 -
@@ -1,6 +1,5 @@
# $OpenBSD: Makefile,v 1.37 2019/11/10 15:32:55 ajacoutot Exp $
-BROKEN-powerpc = undefined reference to __atomic_fetch_add_8
BROKEN-i386 = clang segfault compiling imagebufalgo_pixelmath.cpp
COMMENT = library for reading and writing images
@@ -10,7 +9,7 @@ GH_PROJECT = oiio
V =1.8.6
GH_TAGNAME = Release-$V
DISTNAME = openimageio-${V}
-REVISION = 5
+REVISION = 6
SHARED_LIBS += OpenImageIO 5.0 # 1.0
SHARED_LIBS += OpenImageIO_Util2.0 # 1.5
@@ -60,6 +59,12 @@ CXXFLAGS += -pthread
CXXFLAGS +=-march=i686
.endif
WRKDIST = ${WRKDIR}/oiio-Release-$V
+
+# Fix undefined reference to __atomic_*
+.if ${MACHINE_ARCH:Mpowerpc} || ${MACHINE_ARCH:Mhppa}
+CONFIGURE_ENV += LDFLAGS="${LDFLAGS} -latomic"
+WANTLIB += atomic
+.endif
post-install:
find ${PREFIX} -name '*.orig' -exec rm -f {} \;
Index: patches/patch-src_include_OpenImageIO_strutil_h
===
RCS file: patches/patch-src_include_OpenImageIO_strutil_h
diff -N patches/patch-src_include_OpenImageIO_strutil_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_include_OpenImageIO_strutil_h 13 Nov 2019 10:16:20
-
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+Add missing header for ports-gcc
+
+Index: src/include/OpenImageIO/strutil.h
+--- src/include/OpenImageIO/strutil.h.orig
src/include/OpenImageIO/strutil.h
+@@ -43,6 +43,7 @@
+
+ #include
++#include
+ #include
+ #include
+ #include
+
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/11/13 04:53:47 Modified files: sysutils/firmware/intel: Tag: OPENBSD_6_6 Makefile distinfo sysutils/firmware/intel/pkg: Tag: OPENBSD_6_6 PLIST Log message: MFC intel ucode
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/11/13 04:50:03 Modified files: textproc/ruby-rouge: Makefile distinfo Log message: Update ruby-rouge to 3.13.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/11/13 04:38:48 Modified files: infrastructure/lib/OpenBSD: FS2.pm Added files: infrastructure/lib/OpenBSD: BaseFS.pm Log message: move the dest/undest/resolve_link code to its own class, so it can be reused in other WRKINST contexts (build-debug-info) Also make use of state to display errors, like duh
[NEW] devel/p5-TOML and devel/p5-TOML-Parser
Hi, ports@: Here is a patch to create 2 new ports: devel/p5-TOML and devel/p5-TOML-Parser. It is required by the update of mail/p5-Mail-Milter-Authentication. It build well and pass all tests on amd64-current system. devel/p5-Test-Deep-Fuzzy should be imported into ports before this patch is committed. Comments? OK? wen
回复: [NEW] devel/p5-Test-Deep-Fuzzy
Revised patch, which remove p5-Test-Deep from TEST_DEPENDS since it is RUN_DEPENDS. wen 发件人: owner-po...@openbsd.org 代表 wen heping 发送时间: 2019年11月13日 16:08 收件人: ports@openbsd.org 主题: [NEW] devel/p5-Test-Deep-Fuzzy Hi, ports@: Here is a patch to create new port: devel/p5-Test-Deep-Fuzzy. It is required by the update of mail/p5-Mail-Milter-Authentication. It build well and pass all tests on amd64-current system. Comments? OK? wen p5-Test-Deep-Fuzzy-p0.tar.gz Description: p5-Test-Deep-Fuzzy-p0.tar.gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/11/13 04:30:30 Modified files: sysutils/firmware/intel: Makefile sysutils/firmware/intel/pkg: PLIST Log message: after installing or updating intel ucode, print "*** CPU microcode has been updated - reboot to apply."
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/11/13 04:00:52 Modified files: x11/libdbusmenu: Makefile Log message: libdbusmenu: don't build with `-Werror'; glib2 deprecation notices were breaking the build on base-gcc archs. OK kmos@ sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/11/13 04:00:21 Modified files: audio/liba52 : Makefile audio/liba52/pkg: PLIST Log message: DEBUG_PACKAGES, @static-lib
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/11/13 03:57:51 Modified files: sysutils/random_run: Makefile Log message: DEBUG_PACKAGES, simple and sweet to test
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/11/13 03:08:58 Modified files: infrastructure/bin: build-debug-info infrastructure/mk: bsd.port.mk Log message: tweak it yet again to always run build-debug-info, it's cheap enough
[NEW] devel/p5-Test-Deep-Fuzzy
Hi, ports@: Here is a patch to create new port: devel/p5-Test-Deep-Fuzzy. It is required by the update of mail/p5-Mail-Milter-Authentication. It build well and pass all tests on amd64-current system. Comments? OK? wen p5-Test-Deep-Fuzzy.tar.gz Description: p5-Test-Deep-Fuzzy.tar.gz
