Re: NEW: sysutils/diffoscope
Stuart Henderson wrote: > On 2018/06/28 01:00, Brian Callahan wrote: > > Hi ports -- > > > > Attached is a new port, sysutils/diffoscope. Diffoscope is a utility for > > in-depth comparison of files, archives, and directories. > > > > --- > > pkg/DESCR: > > diffoscope will try to get to the bottom of what makes files or > > directories different. It will recursively unpack archives of many kinds > > and transform various binary formats into more human readable form to > > compare them. It can compare two tarballs, ISO images, or PDF just as > > easily. > > > > It can be scripted through error codes, and a report can be produced > > with the detected differences. The report can be text or HTML. When no > > type of report has been selected, diffoscope defaults to write a text > > report on the standard output. > > > > diffoscope was initially started by the "reproducible builds" Debian > > project and now being developed as part of the wider "Reproducible > > Builds" initiative. It is meant to be able to quickly understand why two > > builds of the same package produce different outputs. diffoscope was > > previously named debbindiff. > > --- > > > > Some time ago, afresh1@ asked me to port this. And it's been sitting in my > > queue since. Let's fix that! > > > > Requires the libarchive-c and py-magic ports also sent to ports@. > > > > OK? > > > > ~Brian > > > > > Should be NO_TEST not NO_TESTS - picked up because I have this in mk.conf: > > $ grep templ /etc/mk.conf > .include "/usr/ports/infrastructure/templates/mk.conf.template" > > Please regen PLIST. > > With those fixed, OK for when the py-magic conflict is handled. on my system diffoscope displays some kind of warning about "getfacl" for each file browsed before showing the result. solene@t480 /usr/ports/sysutils/diffoscope $ diffoscope . . 2018-11-29 06:30:00 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:01 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:01 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:01 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:01 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:01 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:01 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:01 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:02 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:02 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:02 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:02 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:02 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:02 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:02 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:03 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:03 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:03 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:03 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:03 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:03 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:04 W: diffoscope.comparators.directory: Unable to find 'getfacl', some directory metadata differences might not be noticed. 2018-11-29 06:30:04 W:
Re: Update to haproxy-1.8.14
On Thu, 29 Nov 2018 02:32:23 +1100, Joel Sing wrote: > On Monday 26 November 2018 18:21:56 Daniel Jakots wrote: > > Hi, > > > > Here's the diff to update haproxy to the 1.8 branch. > > Most of the libressl stuff has been done by jsing (thanks!) but he > > did the update to 1.8.13 and 13->14 needed some more fiddling. I > > did them on my own so I guess a review wouldn't hurt. > > > > The 1.8 branch brings HTTP/2 and TLS1.3 but maybe the latter won't > > work because of the libressl vs openssl. I don't know. > > TLSv1.3 is not currently supported by LibreSSL, hence the maximum > that haproxy will negotiate (as a client or server) is going to be > TLSv1.2. Once LibreSSL supports TLSv1.3 it will automatically start > working - the code that this disables relates to 0-RTT data, which > we're unlikely to support (at least initially). Thanks for the explanation! > > I'm dogfooding it and so far it's been good. > > > > I'll be kind and save some users some trouble: don't try to backport > > this diff to 6.4, it won't work. > > Why do you say that? OPENSSL_NO_ASYNC as pointed out by tb. I guess there could be a way to make this update work on 6.4 but let's just say it will be a friendly reminder for users that development happens on -current ;) > > Tests? Comments? OK? > > Looks good to me - ok jsing@. Thanks, I'm going to wait a few more days to let people test it. Cheers, Daniel
Re: ld.lld vs ld.bfd and cmake - missing shlib version in NEEDED
On Thu, 29 Nov 2018 00:28:11 +
Stuart Henderson wrote:
> $ objdump -p /usr/local/bin/zint|grep NEEDED
> NEEDED libzint.so
> NEEDED libpng.so.17.5
> NEEDED libz.so.5.0
> NEEDED libm.so.10.1
> NEEDED libc.so.93.0
I don't know. This might happen because some libraries in OpenBSD
(like libzint and libpng) don't have DT_SONAME.
In other ELF systems, a shared library has its name and version
number in DT_SONAME. The linker opens a symbolic link (like
libterminfo.so -> libterminfo.so.1.0) and reads the DT_SONAME to know
the version number. It copies this DT_SONAME to DT_NEEDED.
Like in NetBSD:
$ objdump -p /usr/lib/libterminfo.so | grep SONAME
SONAME libterminfo.so.1
$ objdump -p /usr/bin/tmux | grep terminfo
NEEDED libterminfo.so.1
In OpenBSD, there is no libpng.so symlink, so the linker opens
libpng.so.17.5. There's no DT_SONAME. The linker knows that the
basename is libpng.so.17.5, but the linker might or might not use
the basename as DT_NEEDED.
If I remember correctly, if ld.bfd links to a library without
DT_SONAME, then the rules are:
- If you use cc -L/usr/local/lib -lpng, then ld.bfd uses the
basename libpng.so.17.5 as DT_NEEDED. This is correct.
- If you use cc /usr/local/lib/libpng.so.17.5, then ld.bfd uses
the absolute path /usr/local/lib/libpng.so.17.5 as DT_NEEDED.
This is weird but might still work.
- If (inside some project) you use cc subdir/libwhat.so.0.0, then
ld.bfd uses the relative path subdir/libwhat.so.0.0 as DT_SONAME.
This might break the build because some executable has subdir in
its rpath, and needs subdir/libwhat.so.0.0 in its rpath, but fails
because subdir/subdir/libwhat.so.0.0 doesn't exist.
The rules in ld.lld might be different. I don't know. This weirdness
only happens on OpenBSD, because other ELF systems always put
DT_SONAME in their shared libraries.
Some build systems (like CMake and Meson) like to run cc with absolute
or relative paths to shared libraries. They rely on DT_SONAME to set
DT_NEEDED to just the basename. OpenBSD's port of devel/cmake has
local patches:
- patch-Modules_CMake{C,CXX}Information_cmake seems to remove the
-Wl,-soname=... so shared libraries don't get DT_SONAME.
- patch-Source_cmComputeLinkInformation seems to link to libraries
with -L... -l... instead of absolute paths.
--
George Koehler
error in building qt-everywhere-opensource-src-4.8.7 on arm
>From a clean install of armv7 and ports on Nov 25: In file included from ../../../../../include/QtCore/qatomic_arm.h:1: ../../../../../include/QtCore/../../../qt-everywhere-opensource-src-4.8.7/sr c/corelib/arch/qatomic_arm.h:54:1: warning: duplicate 'extern' declaration specifier [-Wduplicate-decl-specifier] QT_END_INCLUDE_HEADER ^ ../../../../../include/QtCore/../../../qt-everywhere-opensource-src-4.8.7/sr c/corelib/global/qglobal.h:144:31: note: expanded from macro 'QT_END_INCLUDE_HEADER' #define QT_END_INCLUDE_HEADER extern "C++" ^ :149:1: error: invalid instruction vmov.u32 r2, r3, s8, s9 ^ 1 warning and 1 error generated. gmake[2]: *** [Makefile.WebKit:435079: .obj/release-static/FELightingNEON.o] Error 1 gmake[2]: Leaving directory '/usr/ports/pobj/qt4-4.8.7/build-arm/src/3rdparty/webkit/Source/WebCore' gmake[1]: *** [Makefile.WebKit:90: sub-WebCore-all-ordered] Error 2 gmake[1]: Leaving directory '/usr/ports/pobj/qt4-4.8.7/build-arm/src/3rdparty/webkit/Source' gmake: *** [Makefile:797: sub-webkit-all-ordered] Error 2 *** Error 2 in /usr/ports/x11/qt4 (/usr/ports/infrastructure/mk/bsd.port.mk:2797 '/usr/ports/pobj/qt4-4.8.7/build-arm/.build_done') *** Error 1 in /usr/ports/x11/qt4 (/usr/ports/infrastructure/mk/bsd.port.mk:2020 '/usr/ports/packages/arm/all/qt4-4.8.7p18.tgz') *** Error 1 in /usr/ports/x11/qt4 (/usr/ports/infrastructure/mk/bsd.port.mk:2486 '_internal-package') *** Error 1 in /usr/ports/x11/qt4 (/usr/ports/infrastructure/mk/bsd.port.mk:2465 'package') *** Error 1 in /usr/ports/x11/qt4 (/usr/ports/infrastructure/mk/bsd.port.mk:2038 '/var/db/pkg/qt4-4.8.7p18/+CONTENTS') *** Error 1 in /usr/ports/x11/qt4 (/usr/ports/infrastructure/mk/bsd.port.mk:2465 'install') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2149 '/usr/ports/pobj/bacula-9.2.1/.dep-x11-qt4') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2544 '/usr/ports/pobj/bacula-9.2.1/.extract_done') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2020 '/usr/ports/packages/arm/all/bacula-client-9.2.1p0.tgz') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2486 '_internal-package') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2465 'package') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2038 '/var/db/pkg/bacula-client-9.2.1p0/+CONTENTS') *** Error 1 in /usr/ports/sysutils/bacula (/usr/ports/infrastructure/mk/bsd.port.mk:2465 'install')
Re: [UPDATE] print/lyx 2.2.3 -> 2.3.1
On Wed, Nov 28, 2018 at 02:06:08PM -0300, Elias M. Mariani wrote: > Modifications: > - Changed from textproc/enchant to textproc/enchant2. > - Added x11/qt5/qtx11extras to LIB_DEPENDS. > - Configure picked up new WANTLIBs: xcb Qt5X11Extras > Works for me on both amd64 and i386. :)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/11/28 17:42:12 Modified files: mail/opendkim : Makefile mail/opendkim/pkg: PLIST Added files: mail/opendkim/pkg: opendkim.rc Log message: add an rc script for opendkim, based on a diff from James J. Lippard
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/11/28 17:38:14 Modified files: infrastructure/db: user.list Log message: reserve 823 for _opendkim
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/11/28 17:29:47 Modified files: net/wireshark : Tag: OPENBSD_6_4 Makefile distinfo net/wireshark/patches: Tag: OPENBSD_6_4 patch-CMakeLists_txt patch-rawshark_c Log message: update to wireshark-2.6.5
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/11/28 17:29:01 Modified files: net/wireshark : Makefile distinfo Log message: update to wireshark-2.6.5
ld.lld vs ld.bfd and cmake - missing shlib version in NEEDED
(Some?) ports using cmake that have both a library and a binary in the same build, built using ld.lld as linker, look like this: $ objdump -p /usr/local/bin/zint|grep NEEDED NEEDED libzint.so NEEDED libpng.so.17.5 NEEDED libz.so.5.0 NEEDED libm.so.10.1 NEEDED libc.so.93.0 i.e. missing the version number. When built using ld.bfd it's like this: $ objdump -p /usr/obj/ports/zint-2.6.3.src/fake-amd64/usr/local/bin/zint | grep NEEDED NEEDED libzint.so.1.0 NEEDED libpng.so.17.5 NEEDED libz.so.5.0 NEEDED libm.so.10.1 NEEDED libc.so.93.0 First noticed with wireshark, but graphics/zint is a quicker build and shows it easily too (lib and executable in different subpackages makes it very easy to spot with "make port-lib-depends-check"). Anyone have a clue what's going on? I've confirmed that compiler command lines are the same by setting "USE_NINJA=samurai" to avoid doing random build order and diffing build logs between the two, the only difference is because ld.lld doesn't show apiwarn messages.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2018/11/28 15:11:24 Modified files: games/einstein : Makefile Added files: games/einstein/patches: patch-convert_h patch-unicode_cpp Log message: add missing includes
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/11/28 15:09:57 Modified files: net/libbgpdump : Makefile distinfo Log message: update to libbgpdump-1.6.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/11/28 14:57:49 Modified files: x11/lxqt/powermanagement: Makefile x11/lxqt/powermanagement/pkg: PLIST Added files: x11/lxqt/powermanagement/pkg: README Log message: add a README about messagebus; from maintainer Elias M. Mariani
Re: CVS: cvs.openbsd.org: ports
On Wed, Nov 28, 2018 at 08:09:12PM +0200, Timo Myyrä wrote:
> Stuart Henderson writes:
>
> > On 2018/11/28 13:38, Antoine Jacoutot wrote:
> >
> >> On Mon, Nov 26, 2018 at 03:35:30PM -0700, Juan Francisco Cantero Hurtado
> >> wrote:
> >> > CVSROOT: /cvs
> >> > Module name: ports
> >> > Changes by: juan...@cvs.openbsd.org 2018/11/26 15:35:30
> >> >
> >> > Log message:
> >> > From Timo Myyra. Help from sthen@ to a previous version. OK benoit@.
> >> >
> >> > Comment:
> >> > dialect of Scheme designed for systems programming
> >>
> >> Doesn't build for me.
> >
> > Builds here, but the build output is pretty much useless for debugging build
> > problems with all the hidden compiler lines..
Builds for me with dpb and manually on amd64.
>
> Well, here's quick patch to enable warnings and verbose messages.
With the patch applied, the build crashes.
Compilation finished.
cc -O2 -pipe-O2 -pipe -Wno-unused -Wno-write-strings
-Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-math-errno
-fomit-frame-pointer -fPIC -fno-common -rdynamic -shared -D___DYNAMIC
-I"/usr/local/include/gambit" -o "proto__1.o1" proto__1.c
Parsing:
"declare"
|std/actor/proto[2]#_g113702_|
|std/actor/proto[2]#_g113703_|
|std/actor/proto[2]#_g113704_|
|std/actor/proto[2]#_g113705_|
|std/actor/proto[2]#_g113706_|
|std/actor/proto[2]#_g113707_|
|std/actor/proto[2]#_g113708_|
|std/actor/proto[2]#_g113709_|
|std/actor/proto[2]#_g113710_|
|std/actor/proto[2]#_g113711_|
|std/actor/proto[2]#_g113712_|
|std/actor/proto[2]#_g113713_|
|std/actor/proto[2]#_g113714_|
|std/actor/proto[2]#_g113715_|
|std/actor/proto[2]#_g113716_|
|std/actor/proto[:1:]#protocol-info|
Compiling:
Dumping:
#
Compilation finished.
cc -O2 -pipe-O2 -pipe -Wno-unused -Wno-write-strings
-Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-math-errno
-fomit-frame-pointer -fPIC -fno-common -rdynamic -shared -D___DYNAMIC
-I"/usr/local/include/gambit" -o "proto__2.o1" proto__2.c
... compile net/wamp
... compile net/repl
... compile os/error
... compile os/fd
... compile os/fcntl
... compile os/fdio
... compile os/pipe
... compile foreign os/_socket
... copy ssi os/_socket
... compile loader os/_socket
... compile os/socket
... compile os/kqueue
... compile os/signal
... compile os/signal-handler
... compile os/pid
... compile net/socket/base
... compile net/socket/basic-socket
... compile net/socket/api
... compile net/socket/buffer
... compile net/socket/basic-server
... compile net/socket/kqueue-server
... compile net/socket/server
... compile net/socket
... compile misc/sync
... compile net/httpd/mux
... compile net/httpd/handler
... compile net/httpd/server
... compile net/httpd/file
... compile net/httpd
... compile crypto/cipher
... compile crypto/hmac
... compile crypto/bn
... compile crypto/dh
... compile crypto
... compile net/sasl
... compile foreign xml/_libxml
... copy ssi xml/_libxml
... compile loader xml/_libxml
... compile xml/libxml
*** ERROR IN gxc#gsc-compile-file -- Too many open files
(open-process
'(path: "gsc" arguments: ("-debug-environments" "-debug-source"
"/usr/ports/pob...
)
*** ERROR; build failed
*** Error 1 in . (Makefile:38 'do-build')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2793
'/usr/ports/pobj/gerbil-0.14/.build_done')
*** Error 1 in /usr/ports/lang/gerbil
(/usr/ports/infrastructure/mk/bsd.port.mk:2465 'all')
--
Juan Francisco Cantero Hurtado http://juanfra.info
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: juan...@cvs.openbsd.org 2018/11/28 14:13:12 Modified files: lang/gerbil: Makefile Log message: Enable verbose mode. From Timo Myyra (MAINTAINER).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2018/11/28 13:29:26 Modified files: net/bitcoin: Makefile Log message: use INSTALL_SCRIPT to install rpcauth.py Note from jca@ Thanks!
Re: [M. UPDATE] net/qbittorrent 4.1.3 -> 4.1.4
On Sat Nov 24, 2018 at 11:10:10PM -0300, Elias M. Mariani wrote: > Changelog: > https://www.qbittorrent.org/news.php > > Small diff attached. > Tested on amd64 without problems (both qbittorrent and qbittorrent-nox). > > A small tweak on the README for qbittorrent-nox, now is needed to > specify a locale to have text on the interface... > > Cheers. > Elias. OK rsadowski@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2018/11/28 12:45:36 Modified files: devel/pycharm : Makefile distinfo Log message: Update pycharm-2018.2.6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2018/11/28 12:44:21 Modified files: devel/catch2 : Makefile distinfo devel/catch2/pkg: PLIST Log message: Update catch2-2.5.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2018/11/28 12:40:27 Modified files: www/goaccess : Makefile distinfo www/goaccess/pkg: PLIST Added files: www/goaccess/patches: patch-src_gholder_c Log message: update to goaccess-1.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2018/11/28 12:29:04 Modified files: devel/kdevelop : Makefile distinfo devel/kdevelop/pkg: PLIST Log message: Update kdevelop 5.3.0
Re: [REVISION] x11/lxqt/powermanagement
Yes, I like your text better, I modified it just a little bit.
I copied the original out from meta/gnome:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/meta/gnome/pkg/README-main?rev=1.42
And in for some reason I still modified my rc.conf.local manually...
Cheers.
Elias.
On Wed, Nov 28, 2018 at 2:42 PM Stuart Henderson wrote:
>
> On 2018/11/28 14:34, Elias M. Mariani wrote:
> > Adding a small pkg-readme to explain how to get lxqt-powermanagement to
> > work.
> >
> >
> > Startup
> > ===
> > LXQt Power Management depends on KF5Solid and it needs a system-wide
> > D-Bus daemon to be running in order to work properly. So the need
> > to add "messagebus" to "pkg_scripts" in rc.conf.local(8) or start
> > it manually with "rcctl start messagebus" before starting the LXQt
> > session.
> >
> >
> > Cheers.
> > Elias.
>
> We normally point people at rcctl for these; possible alternative text:
>
>
>
> Startup
> ===
> LXQt Power Management depends on KF5Solid and it needs a system-wide
> D-Bus daemon ("messagebus") to be running in order to work properly.
>
> To enable at boot and start if not already running:
>
> # rcctl enable messagebus
> # rcctl start messagebus
>
>
>
>
>
lxqt-powermanagement-0.13.0p0.diff
Description: Binary data
Re: CVS: cvs.openbsd.org: ports
timo.my...@bittivirhe.fi (Timo Myyrä) writes:
> Stuart Henderson writes:
>
>> On 2018/11/28 13:38, Antoine Jacoutot wrote:
>>
>>> On Mon, Nov 26, 2018 at 03:35:30PM -0700, Juan Francisco Cantero Hurtado
>>> wrote:
>>> > CVSROOT: /cvs
>>> > Module name: ports
>>> > Changes by: juan...@cvs.openbsd.org 2018/11/26 15:35:30
>>> >
>>> > Log message:
>>> > From Timo Myyra. Help from sthen@ to a previous version. OK benoit@.
>>> >
>>> > Comment:
>>> > dialect of Scheme designed for systems programming
>>>
>>> Doesn't build for me.
>>
>> Builds here, but the build output is pretty much useless for debugging build
>> problems with all the hidden compiler lines..
>
> Well, here's quick patch to enable warnings and verbose messages.
>
> Timo
>
>
> Index: patches/patch-src_build_build0_scm
> ===
> RCS file: patches/patch-src_build_build0_scm
> diff -N patches/patch-src_build_build0_scm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_build_build0_scm28 Nov 2018 18:08:22 -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Index: src/build/build0.scm
> +--- src/build/build0.scm.orig
> src/build/build0.scm
> +@@ -10,7 +10,7 @@
> + (displayln "... compile " modf)
> + (let ((proc (open-process
> +(list path: "gsc"
> +- arguments: (list "-cc-options" "--param
> max-gcse-memory=3" modf)
> ++ arguments: (list "-warnings" "-verbose" modf)
> + stdout-redirection: #f
> + (if (not (zero? (process-status proc)))
> + (error "Compilation error; gsc exit with nonzero status" modf
> Index: patches/patch-src_build_build1_ss
> ===
> RCS file: patches/patch-src_build_build1_ss
> diff -N patches/patch-src_build_build1_ss
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_build_build1_ss 28 Nov 2018 18:08:22 -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Index: src/build/build1.ss
> +--- src/build/build1.ss.orig
> src/build/build1.ss
> +@@ -55,7 +55,7 @@
> + (displayln "... compile " modf)
> + (compile-file modf [output-dir: gerbil-libdir invoke-gsc: #t
> + debug: debug optimize: optimize? generate-ssxi:
> gen-ssxi? static: static?
> +- gsc-options: ["-cc-options" "--param
> max-gcse-memory=3"]]))
> ++ gsc-options: ["-warnings" "-verbose"]]))
> +
> + (def debug-none #f) ; no bloat
> + (def debug-src 'src) ; full introspection -- sadly, it adds bloat and
> increases load time
> Index: patches/patch-src_gerbil_runtime_build_scm
> ===
> RCS file: patches/patch-src_gerbil_runtime_build_scm
> diff -N patches/patch-src_gerbil_runtime_build_scm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_gerbil_runtime_build_scm28 Nov 2018 18:08:22
> -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Index: src/gerbil/runtime/build.scm
> +--- src/gerbil/runtime/build.scm.orig
> src/gerbil/runtime/build.scm
> +@@ -22,7 +22,7 @@
> + (let ((proc (open-process
> +`(path: ,(getenv "GERBIL_GSC" "gsc")
> +arguments: ("-o" ,*libdir*
> +- "-cc-options" "--param
> max-gcse-memory=3"
> ++ "-warnings" "-verbose"
> +,@(if (runtime-smp?)
> +'("-e"
> "(define-cond-expand-feature|enable-smp|)")
> +'())
> Index: patches/patch-src_misc_http-perf_build_ss
> ===
> RCS file: patches/patch-src_misc_http-perf_build_ss
> diff -N patches/patch-src_misc_http-perf_build_ss
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_misc_http-perf_build_ss 28 Nov 2018 18:08:22 -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Index: src/misc/http-perf/build.ss
> +--- src/misc/http-perf/build.ss.orig
> src/misc/http-perf/build.ss
> +@@ -9,7 +9,7 @@
> +
> + (def build-spec-static
> + '((static-exe: "hellod"
> +- "-cc-options" "--param max-gcse-memory=3"
> ++ "-warnings" "-verbose"
> + "-prelude" "(declare (not safe))")
> + (static-exe: "baseline"
> + "-prelude" "(declare (not safe))")))
> Index: patches/patch-src_std_build-spec_ss
> ===
> RCS file: patches/patch-src_std_build-spec_ss
> diff -N patches/patch-src_std_build-spec_ss
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_std_build-spec_ss 28 Nov 2018 18:08:22 -
> @@ -0,0 +1,47 @@
> +$OpenBSD$
> +
> +Index: src/std/build-spec.ss
> +--- src/std/build-spec.ss.orig
> src/std/build-spec.ss
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2018/11/28 11:23:08 Modified files: lang/ocaml : Makefile lang/ocaml/patches: patch-configure Log message: Wedge -znotext into all the necessary places to allow text relocations that are caused at least by non-PIC assembly in the i386 runtime stub. While here, also honor CFLAGS better. ok jca@ krw@ avsm@
Re: CVS: cvs.openbsd.org: ports
Stuart Henderson writes:
> On 2018/11/28 13:38, Antoine Jacoutot wrote:
>
>> On Mon, Nov 26, 2018 at 03:35:30PM -0700, Juan Francisco Cantero Hurtado
>> wrote:
>> > CVSROOT: /cvs
>> > Module name: ports
>> > Changes by:juan...@cvs.openbsd.org 2018/11/26 15:35:30
>> >
>> > Log message:
>> > From Timo Myyra. Help from sthen@ to a previous version. OK benoit@.
>> >
>> > Comment:
>> > dialect of Scheme designed for systems programming
>>
>> Doesn't build for me.
>
> Builds here, but the build output is pretty much useless for debugging build
> problems with all the hidden compiler lines..
Well, here's quick patch to enable warnings and verbose messages.
Timo
Index: patches/patch-src_build_build0_scm
===
RCS file: patches/patch-src_build_build0_scm
diff -N patches/patch-src_build_build0_scm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_build_build0_scm 28 Nov 2018 18:08:22 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: src/build/build0.scm
+--- src/build/build0.scm.orig
src/build/build0.scm
+@@ -10,7 +10,7 @@
+ (displayln "... compile " modf)
+ (let ((proc (open-process
+(list path: "gsc"
+- arguments: (list "-cc-options" "--param
max-gcse-memory=3" modf)
++ arguments: (list "-warnings" "-verbose" modf)
+ stdout-redirection: #f
+ (if (not (zero? (process-status proc)))
+ (error "Compilation error; gsc exit with nonzero status" modf
Index: patches/patch-src_build_build1_ss
===
RCS file: patches/patch-src_build_build1_ss
diff -N patches/patch-src_build_build1_ss
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_build_build1_ss 28 Nov 2018 18:08:22 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: src/build/build1.ss
+--- src/build/build1.ss.orig
src/build/build1.ss
+@@ -55,7 +55,7 @@
+ (displayln "... compile " modf)
+ (compile-file modf [output-dir: gerbil-libdir invoke-gsc: #t
+ debug: debug optimize: optimize? generate-ssxi:
gen-ssxi? static: static?
+- gsc-options: ["-cc-options" "--param
max-gcse-memory=3"]]))
++ gsc-options: ["-warnings" "-verbose"]]))
+
+ (def debug-none #f) ; no bloat
+ (def debug-src 'src) ; full introspection -- sadly, it adds bloat and
increases load time
Index: patches/patch-src_gerbil_runtime_build_scm
===
RCS file: patches/patch-src_gerbil_runtime_build_scm
diff -N patches/patch-src_gerbil_runtime_build_scm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_gerbil_runtime_build_scm 28 Nov 2018 18:08:22 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: src/gerbil/runtime/build.scm
+--- src/gerbil/runtime/build.scm.orig
src/gerbil/runtime/build.scm
+@@ -22,7 +22,7 @@
+ (let ((proc (open-process
+`(path: ,(getenv "GERBIL_GSC" "gsc")
+arguments: ("-o" ,*libdir*
+- "-cc-options" "--param
max-gcse-memory=3"
++ "-warnings" "-verbose"
+,@(if (runtime-smp?)
+'("-e"
"(define-cond-expand-feature|enable-smp|)")
+'())
Index: patches/patch-src_misc_http-perf_build_ss
===
RCS file: patches/patch-src_misc_http-perf_build_ss
diff -N patches/patch-src_misc_http-perf_build_ss
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_misc_http-perf_build_ss 28 Nov 2018 18:08:22 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: src/misc/http-perf/build.ss
+--- src/misc/http-perf/build.ss.orig
src/misc/http-perf/build.ss
+@@ -9,7 +9,7 @@
+
+ (def build-spec-static
+ '((static-exe: "hellod"
+- "-cc-options" "--param max-gcse-memory=3"
++ "-warnings" "-verbose"
+ "-prelude" "(declare (not safe))")
+ (static-exe: "baseline"
+ "-prelude" "(declare (not safe))")))
Index: patches/patch-src_std_build-spec_ss
===
RCS file: patches/patch-src_std_build-spec_ss
diff -N patches/patch-src_std_build-spec_ss
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_std_build-spec_ss 28 Nov 2018 18:08:22 -
@@ -0,0 +1,47 @@
+$OpenBSD$
+
+Index: src/std/build-spec.ss
+--- src/std/build-spec.ss.orig
src/std/build-spec.ss
+@@ -31,10 +31,10 @@
+ "srfi/8"
+ "srfi/9"
+ "srfi/14"
+-(gxc: "srfi/13" "-cc-options" "--param max-gcse-memory=3")
++(gxc: "srfi/13" "-warnings" "-verbose")
+ "srfi/19"
+ "srfi/41"
+-(gxc: "srfi/42" "-cc-options" "--param
Re: security/wpa_supplicant: Reassoc on NWID change
Peter Hessler writes:
> This looks really cool, thank you for looking at it!
>
> One thing that you may also need, is to may also need to reassoc when
> the bssid changes (roaming between different APs). Can you also test
> that when you do your join testing?
> [...]
Good call. That does turn out to be necessary, so I've amended my
original patch. An updated patch is attached below my signature.
I've tested this with a two-AP 802.1x network now, but since the APs are
more or less sitting on top of each other, I can't really move out of
range of only one of them to test organic handover. I've emulated that
by adding the SSID to my `iwm0`'s joinlist and manually exchanging the
BSSID.
I'll try to see if I can squeeze in some time at my local eduroam
network tomorrow to check out how this works in the "I got out of range
of one AP and the kernel switched me over to another"-scenario.
--
Gregor
Index: patches/patch-src_drivers_driver_openbsd_c
===
RCS file:
/home/cvs/ports/security/wpa_supplicant/patches/patch-src_drivers_driver_openbsd_c,v
retrieving revision 1.5
diff -u -p -r1.5 patch-src_drivers_driver_openbsd_c
--- patches/patch-src_drivers_driver_openbsd_c 17 May 2016 08:29:27 -
1.5
+++ patches/patch-src_drivers_driver_openbsd_c 28 Nov 2018 17:51:30 -
@@ -2,23 +2,137 @@ $OpenBSD: patch-src_drivers_driver_openb
Fix includes
src/drivers/driver_openbsd.c.orig Sun Sep 27 21:02:05 2015
-+++ src/drivers/driver_openbsd.c Mon Sep 28 09:51:53 2015
-@@ -9,13 +9,14 @@
+Index: src/drivers/driver_openbsd.c
+--- src/drivers/driver_openbsd.c.orig
src/drivers/driver_openbsd.c
+@@ -9,19 +9,34 @@
#include "includes.h"
#include
+#include "common.h"
+#include "driver.h"
++#include "eloop.h"
+
++#include
#include
+#include
++#include
#include
#include
#include
--
+
-#include "common.h"
-#include "driver.h"
++#define RTM_READSZ 2048
struct openbsd_driver_data {
- char ifname[IFNAMSIZ + 1];
+- char ifname[IFNAMSIZ + 1];
+ void *ctx;
+
+- int sock; /* open socket for 802.11 ioctls */
++ char ifname[IFNAMSIZ + 1];
++ int ifindex; /* Ifindex of the configured interface */
++
++ int sock; /* open socket for 802.11 ioctls */
++ int rtsock; /* routing socket for interface state messages */
++
++ /* These fields are used to track the last seen (and associated) access
point
++ to determine whether we should kick off an association event */
++ int nwid_len; /* Length of last seen SSID (as per routing message) */
++ char nwid[IEEE80211_NWID_LEN]; /* Last seen SSID (as per routing
message) */
++ char addr[IEEE80211_ADDR_LEN]; /* Last seen BSSID (as per routing
message) */
+ };
+
+
+@@ -90,6 +105,57 @@ wpa_driver_openbsd_set_key(const char *ifname, void *p
+ return 0;
+ }
+
++static void
++wpa_driver_openbsd_event_receive(int sock, void *global, void *sock_ctx)
++{
++ struct openbsd_driver_data *drv = sock_ctx;
++ struct rt_msghdr *rtm;
++ struct if_ieee80211_data *ifie;
++ char *rtmmsg;
++ ssize_t n;
++
++ rtmmsg = os_zalloc(RTM_READSZ);
++ if (rtmmsg == NULL) {
++ wpa_printf(MSG_ERROR, "Can't allocate space for routing
message");
++ return;
++ }
++
++ do {
++ n = read(sock, rtmmsg, RTM_READSZ);
++ } while (n == -1 && errno == EINTR);
++
++ if (n == -1)
++ goto done;
++
++ rtm = (struct rt_msghdr *)rtmmsg;
++
++ if ((size_t)n < sizeof(rtm->rtm_msglen) ||
++ n < rtm->rtm_msglen ||
++ rtm->rtm_version != RTM_VERSION)
++ goto done;
++
++ if ((rtm->rtm_type != RTM_80211INFO) ||
++ (rtm->rtm_index != drv->ifindex))
++ goto done;
++
++ ifie = &((struct if_ieee80211_msghdr *)rtm)->ifim_ifie;
++
++ if ((ifie->ifie_nwid_len != drv->nwid_len) ||
++ (os_memcmp(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len) != 0) ||
++ (os_memcmp(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN) != 0)) {
++ os_memcpy(drv->addr, ifie->ifie_addr, IEEE80211_ADDR_LEN);
++
++ os_memcpy(drv->nwid, ifie->ifie_nwid, ifie->ifie_nwid_len);
++ drv->nwid_len = ifie->ifie_nwid_len;
++
++ /* Emit ASSOC event */
++ wpa_supplicant_event(drv->ctx, EVENT_ASSOC, NULL);
++ }
++
++done:
++ os_free(rtmmsg);
++}
++
+ static void *
+ wpa_driver_openbsd_init(void *ctx, const char *ifname)
+ {
+@@ -103,9 +169,21 @@ wpa_driver_openbsd_init(void *ctx, const char *ifname)
+ if (drv->sock < 0)
+ goto fail;
+
++ drv->rtsock = socket(PF_ROUTE, SOCK_RAW, AF_UNSPEC);
++ if (drv->rtsock < 0)
++ goto fail;
++
+ drv->ctx = ctx;
+ os_strlcpy(drv->ifname, ifname, sizeof(drv->ifname));
+
++ drv->ifindex =
Re: [REVISION] x11/lxqt/powermanagement
On 2018/11/28 14:34, Elias M. Mariani wrote:
> Adding a small pkg-readme to explain how to get lxqt-powermanagement to work.
>
>
> Startup
> ===
> LXQt Power Management depends on KF5Solid and it needs a system-wide
> D-Bus daemon to be running in order to work properly. So the need
> to add "messagebus" to "pkg_scripts" in rc.conf.local(8) or start
> it manually with "rcctl start messagebus" before starting the LXQt
> session.
>
>
> Cheers.
> Elias.
We normally point people at rcctl for these; possible alternative text:
Startup
===
LXQt Power Management depends on KF5Solid and it needs a system-wide
D-Bus daemon ("messagebus") to be running in order to work properly.
To enable at boot and start if not already running:
# rcctl enable messagebus
# rcctl start messagebus
Re: CVS: cvs.openbsd.org: ports
On 2018/11/28 13:38, Antoine Jacoutot wrote: > On Mon, Nov 26, 2018 at 03:35:30PM -0700, Juan Francisco Cantero Hurtado > wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: juan...@cvs.openbsd.org 2018/11/26 15:35:30 > > > > Log message: > > From Timo Myyra. Help from sthen@ to a previous version. OK benoit@. > > > > Comment: > > dialect of Scheme designed for systems programming > > Doesn't build for me. Builds here, but the build output is pretty much useless for debugging build problems with all the hidden compiler lines..
[REVISION] x11/lxqt/powermanagement
Adding a small pkg-readme to explain how to get lxqt-powermanagement to work. Startup === LXQt Power Management depends on KF5Solid and it needs a system-wide D-Bus daemon to be running in order to work properly. So the need to add "messagebus" to "pkg_scripts" in rc.conf.local(8) or start it manually with "rcctl start messagebus" before starting the LXQt session. Cheers. Elias. lxqt-powermanagement-0.13.0p0.diff Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2018/11/28 10:34:28 Modified files: databases/sqlports/files: Inserter.pm Var.pm mksqlitedb Log message: with the "dual database" gone, I can get rid of a lot of scaffolding.
Re: [REVISION] x11/lxqt/build-tools and x11/lxqt/libqtxdg
Small ping for a small change. On Thu, Nov 15, 2018 at 6:35 AM Elias M. Mariani wrote: > > From George Koehler: > https://marc.info/?l=openbsd-ports=154118440613320 > "The build system tries to use link-time optimization (-flto > -fuse-linker-plugin). This fails because -fuse-linker-plugin "is > available in gold or in GNU ld 2.21 or newer" (says man egcc), but > OpenBSD has GNU ld 2.17. > > x11/lxqt/build-tools enables LTO for gcc, so the failure would happen > on ports-gcc arches like powerpc. Most packages outside LXQt don't > enable LTO, so I disabled LTO by modifying x11/lxqt/build-tools." > Thanks to George Koehler for the solution. > > The same applies to x11/lxqt/libqtxdg. > > Thanks landry@ for the bulk with the failure report. > > This should fix the build on non-clang archs. > > Cheers. > Elias. lxqt-gcc-fix.diff Description: Binary data
Re: [UPDATE] print/lyx 2.2.3 -> 2.3.1
Modifications: - Changed from textproc/enchant to textproc/enchant2. - Added x11/qt5/qtx11extras to LIB_DEPENDS. - Configure picked up new WANTLIBs: xcb Qt5X11Extras I love cmake way more than gnu configure... std::regex is been used instead of boost::regex, do we have archs without C++11? Cheers. Elias. On Tue, Nov 27, 2018 at 10:58 PM Elias M. Mariani wrote: > > On Tue, Nov 27, 2018 at 9:03 PM Josh Grosse wrote: > > The only thing I noticed was this port-lib-depends-check complaint: > > > >Missing lib: enchant-2.0 (/usr/local/bin/lyx) (NOT REACHABLE) > >Extra: enchant.6 > Oh, I see. > I build with textproc/enchant and you have installed > textproc/enchant2, so probably the configuration is picking in your > case the newer library. > I will send a new diff tomorrow using textproc/enchant2, it has more > sense than using enchant. > > Thanks for the report! > Elias. lyx-2.3.1.diff Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2018/11/28 09:36:05 Modified files: net/samba : Makefile net/samba/pkg : PLIST-ldb PLIST-main Log message: The ldb tools link against libldb-cmdline-samba4.so.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/11/28 08:35:43 Modified files: sysutils/burp/2.0: Makefile sysutils/burp/2.0/pkg: PLIST sysutils/burp/2.1: Makefile sysutils/burp/2.1/pkg: PLIST Log message: regenerate plists
Re: burp 2.2.12
On 2018/11/28 16:06, Florian Obser wrote:
> On Wed, Nov 28, 2018 at 09:49:28AM -0500, Brian Callahan wrote:
> > Hi Florian --
> >
> > On 11/25/18 5:40 AM, Florian Obser wrote:
> > > I started to use burp 2.1 the other day and has the shortcoming that
> > > it can only listen on one port. And :: means IPv6 in OpenBSD, you
> > > don't magically get a v4 socket, too.
> > >
> > > 2.2.12 gained the feature of listening on multiple sockets, but the
> > > syntax changed:
> > >
> > > -address = ::
> > > -port = 4971
> > > +listen = 0.0.0.0:4971
> > > +listen = :::4971
> > > max_children = 5
> > > -status_address = localhost
> > > -status_port = 4972
> > > +listen_status = 127.0.0.1:5972
> > > +listen_status = ::1:5972
> > > max_status_children = 5
> > >
> > > I tried these combinations:
> > >
> > > server: 2.1.28
> > > client: 2.2.12
> > >
> > > server: 2.2.12
> > > client: 2.1.28 (it warns that the client should be updated)
> > >
> > > server: 2.2.12
> > > client: 2.2.12
> > >
> > > So it seems like we could drop 2.1 once this is in.
> > >
> > > OKs, further tests?
> > >
> > >
> > >
> >
> > When I ran `make update-plist', I got the following message:
> > Can't put into any plist (no applicable prefix):
> > /var/run/burp
That can be ignored.
> > Additionally, the PLIST changed, more than just cosmetic rearranging of
> > entries.
>
> Thanks for looking. That's why they don't let me bring my aura near
> anything important. Nevermind then.
Definitely seems a useful addition - I'll regenerate PLISTs for 2.0 and 2.1
to make it a bit clearer ("make plist" changed the order of what it outputs
since they were added), OK to add 2.2 with the attached PLIST.
@comment $OpenBSD: PLIST,v 1.1 2018/03/08 14:41:02 sthen Exp $
@option is-branch
@conflict burp-*
@newgroup _burp:794
@newuser _burp:794:794:daemon:BackUp and Recovery
Daemon:/var/empty:/sbin/nologin
@rcscript ${RCDIR}/burp
@bin bin/vss_strip
@man man/man8/bedup.8
@man man/man8/bsigs.8
@man man/man8/bsparse.8
@man man/man8/burp.8
@man man/man8/burp_ca.8
@man man/man8/vss_strip.8
sbin/bedup
sbin/bsigs
sbin/bsparse
@bin sbin/burp
sbin/burp_ca
share/burp/
share/burp/scripts/
share/burp/scripts/backup_tool_script
share/burp/scripts/notify_script
share/burp/scripts/ssl_extra_checks_script
share/burp/scripts/summary_script
share/burp/scripts/timer_script
share/doc/burp/
share/doc/burp/CHANGELOG
share/doc/burp/CONTRIBUTORS
share/doc/burp/DONATIONS
share/doc/burp/LICENSE
share/doc/burp/README
share/doc/burp/UPGRADING
share/doc/burp/add-remove.txt
share/doc/burp/autoupgrade.txt
share/doc/burp/backup_phases.txt
share/doc/burp/backup_tool_script.txt
share/doc/burp/baremetal-windows2008.txt
share/doc/burp/baremetal-windows7-hirens.txt
share/doc/burp/baremetal-windows7.txt
share/doc/burp/baremetal-windows7and8.txt
share/doc/burp/burp_ca.txt
share/doc/burp/debug.txt
share/doc/burp/readwrite.txt
share/doc/burp/retention.txt
share/doc/burp/security-models.txt
share/doc/burp/server-basics.txt
share/doc/burp/shuffling.txt
share/doc/burp/status-monitor.txt
share/doc/burp/tests.txt
share/doc/burp/timer_script.txt
share/doc/burp/working_dir.txt
share/examples/burp/
share/examples/burp/CA-client/
@mode 750
@owner _burp
@group _burp
@sample ${SYSCONFDIR}/
@mode
share/examples/burp/CA.cnf
@sample ${SYSCONFDIR}/CA.cnf
share/examples/burp/burp-server.conf
@sample ${SYSCONFDIR}/burp-server.conf
share/examples/burp/burp.conf
@sample ${SYSCONFDIR}/burp.conf
@owner
@group
share/examples/burp/clientconfdir/
share/examples/burp/clientconfdir/incexc/
share/examples/burp/clientconfdir/incexc/example
@owner _burp
@group _burp
@sample ${SYSCONFDIR}/clientconfdir/incexc/example
share/examples/burp/clientconfdir/testclient
@sample ${SYSCONFDIR}/clientconfdir/testclient
@mode 750
@sample ${LOCALSTATEDIR}/spool/burp/
@sample ${SYSCONFDIR}/CA-client/
@sample ${SYSCONFDIR}/clientconfdir/
@sample ${SYSCONFDIR}/clientconfdir/incexc/
Re: Update to haproxy-1.8.14
On Monday 26 November 2018 18:21:56 Daniel Jakots wrote: > Hi, > > Here's the diff to update haproxy to the 1.8 branch. > Most of the libressl stuff has been done by jsing (thanks!) but he did > the update to 1.8.13 and 13->14 needed some more fiddling. I did them > on my own so I guess a review wouldn't hurt. > > The 1.8 branch brings HTTP/2 and TLS1.3 but maybe the latter won't work > because of the libressl vs openssl. I don't know. TLSv1.3 is not currently supported by LibreSSL, hence the maximum that haproxy will negotiate (as a client or server) is going to be TLSv1.2. Once LibreSSL supports TLSv1.3 it will automatically start working - the code that this disables relates to 0-RTT data, which we're unlikely to support (at least initially). > I'm dogfooding it and so far it's been good. > > I'll be kind and save some users some trouble: don't try to backport > this diff to 6.4, it won't work. Why do you say that? > Tests? Comments? OK? Looks good to me - ok jsing@. > Cheers, > Daniel
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/11/28 08:15:52 Modified files: www/iridium/patches: patch-build_config_compiler_BUILD_gn Log message: Adjust () position to disable --build-id on OpenBSD. The patch file is similar to one in chromium, but the line is slightly different meaning this didn't work quite right. Fixes build with ld.bfd (e.g. i386 until we switch to lld). ok robert@
Re: burp 2.2.12
On Wed, Nov 28, 2018 at 09:49:28AM -0500, Brian Callahan wrote: > Hi Florian -- > > On 11/25/18 5:40 AM, Florian Obser wrote: > > I started to use burp 2.1 the other day and has the shortcoming that > > it can only listen on one port. And :: means IPv6 in OpenBSD, you > > don't magically get a v4 socket, too. > > > > 2.2.12 gained the feature of listening on multiple sockets, but the syntax > > changed: > > > > -address = :: > > -port = 4971 > > +listen = 0.0.0.0:4971 > > +listen = :::4971 > > max_children = 5 > > -status_address = localhost > > -status_port = 4972 > > +listen_status = 127.0.0.1:5972 > > +listen_status = ::1:5972 > > max_status_children = 5 > > > > I tried these combinations: > > > > server: 2.1.28 > > client: 2.2.12 > > > > server: 2.2.12 > > client: 2.1.28 (it warns that the client should be updated) > > > > server: 2.2.12 > > client: 2.2.12 > > > > So it seems like we could drop 2.1 once this is in. > > > > OKs, further tests? > > > > > > > > When I ran `make update-plist', I got the following message: > Can't put into any plist (no applicable prefix): > /var/run/burp > > Additionally, the PLIST changed, more than just cosmetic rearranging of > entries. Thanks for looking. That's why they don't let me bring my aura near anything important. Nevermind then. > > ~Brian -- I'm not entirely sure you are real.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2018/11/28 07:57:45 Modified files: databases/sqlports: Makefile databases/sqlports/files: Inserter.pm mksqlitedb databases/sqlports/files/scripts: print-ports-index show-reverse-deps databases/sqlports/pkg: DESCR-main PLIST-main databases/ports-readmes: Makefile databases/ports-readmes/files: make-readmes databases/ports-readmes-dancer: Makefile databases/ports-readmes-dancer/files: config.yml.sample sysutils/upt/upt-openbsd: Makefile sysutils/pkg_mgr: Makefile sysutils/pkg_mgr/patches: patch-OpenBSD_PackageManager_DBIModel_pm misc/portroach : Makefile Removed files: databases/sqlports/pkg: DESCR-compact PLIST-compact Log message: switch to one single schema for sqlports. Kill sqlports-compact (it is the new default, change tables to be _table, views to be view (for now)) and adjust consumers to work with the new tool, to the best of my knowledge
Re: UPDATE: textproc/ripgrep-0.10.0 (with request for help)
On Tue, Nov 27, 2018 at 06:03:13PM -0600, Edward Lopez-Acosta wrote:
> WANTLIB fixed, it did add an extra entry (c++abi), I am fairly certain I
> sorted out the tabs vs spaces in the list. Is there a way to preserve this
> when I make the crate list and import it into the Makefile?
copy/paste could replace tab by spaces.
usually, I am doing something like:
$ make modcargo-gen-crates-licenses > foo
and use ":read foo" from vim.
> Thank you for the patience and hopefully this diff is clean. First time ever
> even looking at anything in Rust on my end.
the diff is OK semarie@ . if someone want to take a look and commit it,
it is possible. else I will commit it tomorrow.
Thanks.
--
Sebastien Marie
> diff --git Makefile Makefile
> index 16d2c678d98..2f06334c405 100644
> --- Makefile
> +++ Makefile
> @@ -4,16 +4,14 @@ COMMENT = line oriented search tool using Rust's
> regex library #'
>
> GH_ACCOUNT = BurntSushi
> GH_PROJECT = ripgrep
> -GH_TAGNAME = 0.8.1
> -REVISION = 2
> +GH_TAGNAME = 0.10.0
>
> CATEGORIES = textproc sysutils
>
> # Unlicense/MIT
> PERMIT_PACKAGE_CDROM = Yes
>
> -# uses pledge()
> -WANTLIB += c pthread
> +WANTLIB += c c++abi pthread
>
> # as devel/cargo MODULES adds DISTFILES, GH_* didn't
> DISTFILES += ${DISTNAME}${EXTRACT_SUFX}
> @@ -22,52 +20,83 @@ MODULES = devel/cargo
> BUILD_DEPENDS = lang/rust>=1.20 \
> textproc/asciidoc
>
> -MODCARGO_CRATES += aho-corasick-0.6.4 # Unlicense/MIT
> -MODCARGO_CRATES += ansi_term-0.10.2# MIT
> -MODCARGO_CRATES += atty-0.2.6 # MIT
> -MODCARGO_CRATES += bitflags-1.0.1 # MIT/Apache-2.0
> -MODCARGO_CRATES += bytecount-0.3.1 # Apache-2.0/MIT
> -MODCARGO_CRATES += cfg-if-0.1.2# MIT/Apache-2.0
> -MODCARGO_CRATES += clap-2.30.0 # MIT
> -MODCARGO_CRATES += crossbeam-0.3.2 # Apache-2.0/MIT
> -MODCARGO_CRATES += encoding_rs-0.7.2 # MIT/Apache-2.0
> +MODCARGO_CRATES += aho-corasick-0.6.8 # Unlicense/MIT
> +MODCARGO_CRATES += arrayvec-0.4.7 # MIT/Apache-2.0
> +MODCARGO_CRATES += atty-0.2.11 # MIT
> +MODCARGO_CRATES += base64-0.9.2# MIT/Apache-2.0
> +MODCARGO_CRATES += bitflags-1.0.4 # MIT/Apache-2.0
> +MODCARGO_CRATES += bytecount-0.3.2 # Apache-2.0/MIT
> +MODCARGO_CRATES += byteorder-1.2.6 # Unlicense/MIT
> +MODCARGO_CRATES += cc-1.0.24 # MIT/Apache-2.0
> +MODCARGO_CRATES += cfg-if-0.1.5# MIT/Apache-2.0
> +MODCARGO_CRATES += clap-2.32.0 # MIT
> +MODCARGO_CRATES += cloudabi-0.0.3 # BSD-2-Clause
> +MODCARGO_CRATES += crossbeam-channel-0.2.4 # MIT/Apache-2.0
> +MODCARGO_CRATES += crossbeam-epoch-0.5.2 # MIT/Apache-2.0
> +MODCARGO_CRATES += crossbeam-utils-0.5.0 # MIT/Apache-2.0
> +MODCARGO_CRATES += encoding_rs-0.8.6 # MIT/Apache-2.0
> +MODCARGO_CRATES += encoding_rs_io-0.1.2# MIT OR Apache-2.0
> MODCARGO_CRATES += fnv-1.0.6 # Apache-2.0 / MIT
> MODCARGO_CRATES += fuchsia-zircon-0.3.3# BSD-3-Clause
> -MODCARGO_CRATES += fuchsia-zircon-sys-0.3.3# BSD-3-Clause
> MODCARGO_CRATES += glob-0.2.11 # MIT/Apache-2.0
> -MODCARGO_CRATES += globset-0.3.0 # Unlicense/MIT
> -MODCARGO_CRATES += grep-0.1.8 # Unlicense/MIT
> -MODCARGO_CRATES += ignore-0.4.0# Unlicense/MIT
> -MODCARGO_CRATES += lazy_static-1.0.0 # MIT/Apache-2.0
> -MODCARGO_CRATES += libc-0.2.36 # MIT/Apache-2.0
> -MODCARGO_CRATES += log-0.4.1 # MIT/Apache-2.0
> -MODCARGO_CRATES += memchr-2.0.1# Unlicense/MIT
> +MODCARGO_CRATES += fuchsia-zircon-sys-0.3.3# BSD-3-Clause
> +MODCARGO_CRATES += itoa-0.4.2 # MIT/Apache-2.0
> +MODCARGO_CRATES += lazy_static-1.1.0 # MIT/Apache-2.0
> +MODCARGO_CRATES += libc-0.2.43 # MIT/Apache-2.0
> +MODCARGO_CRATES += lock_api-0.1.3 # Apache-2.0/MIT
> +MODCARGO_CRATES += log-0.4.5 # MIT/Apache-2.0
> +MODCARGO_CRATES += memchr-2.0.2# Unlicense/MIT
> MODCARGO_CRATES += memmap-0.6.2# MIT/Apache-2.0
> +MODCARGO_CRATES += memoffset-0.2.1 # MIT
> +MODCARGO_CRATES += nodrop-0.1.12 # MIT/Apache-2.0
> MODCARGO_CRATES += num_cpus-1.8.0 # MIT/Apache-2.0
> -MODCARGO_CRATES += rand-0.3.22 # MIT/Apache-2.0
> -MODCARGO_CRATES += rand-0.4.2 # MIT/Apache-2.0
> -MODCARGO_CRATES += redox_syscall-0.1.37# MIT
> +MODCARGO_CRATES += owning_ref-0.3.3# MIT
> +MODCARGO_CRATES += parking_lot-0.6.4 # Apache-2.0/MIT
> +MODCARGO_CRATES += parking_lot_core-0.3.0 # Apache-2.0/MIT
> +MODCARGO_CRATES += pcre2-0.1.0 # Unlicense/MIT
> +MODCARGO_CRATES += pcre2-sys-0.1.1 # Unlicense/MIT
> +MODCARGO_CRATES += pkg-config-0.3.14 # MIT/Apache-2.0
> +MODCARGO_CRATES += proc-macro2-0.4.18 # MIT/Apache-2.0
> +MODCARGO_CRATES += quote-0.6.8 # MIT/Apache-2.0
> +MODCARGO_CRATES += rand-0.4.3 # MIT/Apache-2.0
> +MODCARGO_CRATES += rand-0.5.5
Re: burp 2.2.12
Hi Florian -- On 11/25/18 5:40 AM, Florian Obser wrote: I started to use burp 2.1 the other day and has the shortcoming that it can only listen on one port. And :: means IPv6 in OpenBSD, you don't magically get a v4 socket, too. 2.2.12 gained the feature of listening on multiple sockets, but the syntax changed: -address = :: -port = 4971 +listen = 0.0.0.0:4971 +listen = :::4971 max_children = 5 -status_address = localhost -status_port = 4972 +listen_status = 127.0.0.1:5972 +listen_status = ::1:5972 max_status_children = 5 I tried these combinations: server: 2.1.28 client: 2.2.12 server: 2.2.12 client: 2.1.28 (it warns that the client should be updated) server: 2.2.12 client: 2.2.12 So it seems like we could drop 2.1 once this is in. OKs, further tests? When I ran `make update-plist', I got the following message: Can't put into any plist (no applicable prefix): /var/run/burp Additionally, the PLIST changed, more than just cosmetic rearranging of entries. ~Brian
Re: Building ports on sparc64
Sorry, My mistake it's now applied cleanly.
Kind regards John.
On Wed, 28 Nov 2018 at 14:30, John Gould wrote:
> Hi, I've tried applying this against current from cvs 28/11/2018.
> Unfortunately I get this:-
>
> /usr/ports/devel/llvm
>
> t5120-virt# vi llvm2.pkg
>
> t5120-virt# patch -C Makefile llvm2.pkg
>
> Hmm... Looks like a unified diff to me...
>
> The text leading up to this was:
>
> --
>
> |Index: Makefile
>
> |===
>
> |RCS file: /cvs/ports/devel/llvm/Makefile,v
>
> |retrieving revision 1.199
>
> |diff -u -p -r1.199 Makefile
>
> |--- Makefile21 Nov 2018 08:03:05 - 1.199
>
> |+++ Makefile26 Nov 2018 20:25:57 -
>
> --
>
> Patching file Makefile using Plan A...
>
> Hunk #1 failed at 8.
>
> Hunk #2 failed at 19.
>
> Hunk #3 failed at 45.
>
> Hunk #4 failed at 62.
>
> Hunk #5 succeeded at 109 with fuzz 2.
>
> Hunk #6 failed at 119.
>
> 5 out of 6 hunks failed
>
> Hmm... The next patch looks like a unified diff to me...
>
> The text leading up to this was:
>
> --
> |Index: pkg/DESCR-lldb
>
> |===
>
> |RCS file: pkg/DESCR-lldb
>
> |diff -N pkg/DESCR-lldb
>
> |--- /dev/null 1 Jan 1970 00:00:00 -
>
> |+++ pkg/DESCR-lldb 26 Nov 2018 20:25:02 -
>
> --
>
> (Creating file pkg/DESCR-lldb...)
>
> Patching file pkg/DESCR-lldb using Plan A...
>
> Empty context always matches.
>
> Hunk #1 succeeded at 1.
>
> Hmm... The next patch looks like a unified diff to me...
>
> The text leading up to this was:
>
>
> etc...
>
>
> Could you possibly send me the patch directly or enumerate what I have
> done wrong?
>
> Kind regards John
>
> On Tue, 27 Nov 2018 at 11:50, Jeremie Courreges-Anglas
> wrote:
>
>> On Tue, Nov 06 2018, Stuart Henderson wrote:
>> > On 2018/11/06 11:11, John Gould wrote:
>> >> Hello, I am trying to build parts of xfce4 and some kde4 applications
>> on
>> >> 6.4 current on sparc64.
>> >> Although these applications worked or were available from packages on
>> 6.3 I
>> >> am having no
>> >> luck on 6.4. I have several sparc machines here all doing nothing! Can
>> >> someone please help me with this or am I wasting my time? I've
>> included a
>> >> dmesg below and some of the output of a recent build.
>> >>
>> >> Kind regards John
>> >>
>> >>
>> /usr/ports/pobj/llvm-6.0.1/llvm-6.0.1.src/tools/lldb/include/lldb/Host/Editline.h:49:19:
>> >> fatal error: codecvt: No such file or directory
>> >>
>> >> #include
>> >>
>> >>^
>> >
>> > This is exactly the reason why these are not available in packages on
>> > 6.4. The patch below for devel/llvm should get things unblocked though I
>> > don't know if it will help get you as far as the ports you're really
>> > interested in.
>>
>> Thanks. Diff refreshed for -current, successfully tested on sparc64
>> (and amd64).
>>
>> IMO this has been broken since too long already. I'd like us to fix
>> what we can now instead of waiting for a switch to gcc 6 in the upcoming
>> weeks/months/releases. Stuart, if you want to commit this, ok jca@
>>
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/devel/llvm/Makefile,v
>> retrieving revision 1.199
>> diff -u -p -r1.199 Makefile
>> --- Makefile21 Nov 2018 08:03:05 - 1.199
>> +++ Makefile26 Nov 2018 20:25:57 -
>> @@ -8,8 +8,9 @@ ONLY_FOR_ARCHS = ${LLVM_ARCHS}
>>
>> DPB_PROPERTIES = parallel
>>
>> -MULTI_PACKAGES = -main -python
>> +MULTI_PACKAGES = -main -python -lldb
>> COMMENT-main = modular, fast C/C++/ObjC compiler, static analyzer and
>> tools
>> +COMMENT-lldb = LLDB debugger
>> COMMENT-python = Python bindings for Clang
>>
>> LLVM_V = 6.0.1
>> @@ -18,8 +19,9 @@ PKGNAME = llvm-${LLVM_V}
>> PKGSPEC-main = llvm-=${LLVM_V}
>> PKGNAME-main = llvm-${LLVM_V}
>> PKGNAME-python = py-llvm-${LLVM_V}
>> -REVISION-main =18
>> -REVISION-python = 2
>> +PKGNAME-lldb = lldb-${LLVM_V}
>> +REVISION-main =19
>> +REVISION-python = 3
>> CATEGORIES = devel
>> DISTFILES =llvm-${LLVM_V}.src${EXTRACT_SUFX} \
>> cfe-${LLVM_V}.src${EXTRACT_SUFX} \
>> @@ -43,6 +45,10 @@ PERMIT_PACKAGE_CDROM = Yes
>> WANTLIB = ${COMPILER_LIBCXX} c curses edit form m panel pthread \
>> ${MODPY_WANTLIB} z
>>
>> +PSEUDO_FLAVORS = no_lldb
>> +FLAVOR ?=
>> +NOT_FOR_ARCHS-lldb = ${GCC4_ARCHS}
>> +
>> MODULES = devel/cmake \
>> lang/python
>>
>> @@ -56,11 +62,14 @@ RUN_DEPENDS += devel/gtest
>>
>> # clang python module loads libclang.so dynamically with
>> cdll.LoadLibrary()
>> WANTLIB-python = clang
>> -LIB_DEPENDS-llvm = ${BUILD_PKGPATH},-main
>> -RUN_DEPENDS-python = ${MODPY_RUN_DEPENDS} \
>> - devel/py-six
>>
Re: Building ports on sparc64
Hi, I've tried applying this against current from cvs 28/11/2018.
Unfortunately I get this:-
/usr/ports/devel/llvm
t5120-virt# vi llvm2.pkg
t5120-virt# patch -C Makefile llvm2.pkg
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: Makefile
|===
|RCS file: /cvs/ports/devel/llvm/Makefile,v
|retrieving revision 1.199
|diff -u -p -r1.199 Makefile
|--- Makefile21 Nov 2018 08:03:05 - 1.199
|+++ Makefile26 Nov 2018 20:25:57 -
--
Patching file Makefile using Plan A...
Hunk #1 failed at 8.
Hunk #2 failed at 19.
Hunk #3 failed at 45.
Hunk #4 failed at 62.
Hunk #5 succeeded at 109 with fuzz 2.
Hunk #6 failed at 119.
5 out of 6 hunks failed
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: pkg/DESCR-lldb
|===
|RCS file: pkg/DESCR-lldb
|diff -N pkg/DESCR-lldb
|--- /dev/null 1 Jan 1970 00:00:00 -
|+++ pkg/DESCR-lldb 26 Nov 2018 20:25:02 -
--
(Creating file pkg/DESCR-lldb...)
Patching file pkg/DESCR-lldb using Plan A...
Empty context always matches.
Hunk #1 succeeded at 1.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
etc...
Could you possibly send me the patch directly or enumerate what I have done
wrong?
Kind regards John
On Tue, 27 Nov 2018 at 11:50, Jeremie Courreges-Anglas
wrote:
> On Tue, Nov 06 2018, Stuart Henderson wrote:
> > On 2018/11/06 11:11, John Gould wrote:
> >> Hello, I am trying to build parts of xfce4 and some kde4 applications on
> >> 6.4 current on sparc64.
> >> Although these applications worked or were available from packages on
> 6.3 I
> >> am having no
> >> luck on 6.4. I have several sparc machines here all doing nothing! Can
> >> someone please help me with this or am I wasting my time? I've included
> a
> >> dmesg below and some of the output of a recent build.
> >>
> >> Kind regards John
> >>
> >>
> /usr/ports/pobj/llvm-6.0.1/llvm-6.0.1.src/tools/lldb/include/lldb/Host/Editline.h:49:19:
> >> fatal error: codecvt: No such file or directory
> >>
> >> #include
> >>
> >>^
> >
> > This is exactly the reason why these are not available in packages on
> > 6.4. The patch below for devel/llvm should get things unblocked though I
> > don't know if it will help get you as far as the ports you're really
> > interested in.
>
> Thanks. Diff refreshed for -current, successfully tested on sparc64
> (and amd64).
>
> IMO this has been broken since too long already. I'd like us to fix
> what we can now instead of waiting for a switch to gcc 6 in the upcoming
> weeks/months/releases. Stuart, if you want to commit this, ok jca@
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/llvm/Makefile,v
> retrieving revision 1.199
> diff -u -p -r1.199 Makefile
> --- Makefile21 Nov 2018 08:03:05 - 1.199
> +++ Makefile26 Nov 2018 20:25:57 -
> @@ -8,8 +8,9 @@ ONLY_FOR_ARCHS = ${LLVM_ARCHS}
>
> DPB_PROPERTIES = parallel
>
> -MULTI_PACKAGES = -main -python
> +MULTI_PACKAGES = -main -python -lldb
> COMMENT-main = modular, fast C/C++/ObjC compiler, static analyzer and
> tools
> +COMMENT-lldb = LLDB debugger
> COMMENT-python = Python bindings for Clang
>
> LLVM_V = 6.0.1
> @@ -18,8 +19,9 @@ PKGNAME = llvm-${LLVM_V}
> PKGSPEC-main = llvm-=${LLVM_V}
> PKGNAME-main = llvm-${LLVM_V}
> PKGNAME-python = py-llvm-${LLVM_V}
> -REVISION-main =18
> -REVISION-python = 2
> +PKGNAME-lldb = lldb-${LLVM_V}
> +REVISION-main =19
> +REVISION-python = 3
> CATEGORIES = devel
> DISTFILES =llvm-${LLVM_V}.src${EXTRACT_SUFX} \
> cfe-${LLVM_V}.src${EXTRACT_SUFX} \
> @@ -43,6 +45,10 @@ PERMIT_PACKAGE_CDROM = Yes
> WANTLIB = ${COMPILER_LIBCXX} c curses edit form m panel pthread \
> ${MODPY_WANTLIB} z
>
> +PSEUDO_FLAVORS = no_lldb
> +FLAVOR ?=
> +NOT_FOR_ARCHS-lldb = ${GCC4_ARCHS}
> +
> MODULES = devel/cmake \
> lang/python
>
> @@ -56,11 +62,14 @@ RUN_DEPENDS += devel/gtest
>
> # clang python module loads libclang.so dynamically with
> cdll.LoadLibrary()
> WANTLIB-python = clang
> -LIB_DEPENDS-llvm = ${BUILD_PKGPATH},-main
> -RUN_DEPENDS-python = ${MODPY_RUN_DEPENDS} \
> - devel/py-six
> +RUN_DEPENDS-python = ${MODPY_RUN_DEPENDS}
> LIB_DEPENDS-python = ${BUILD_PKGPATH},-main
>
> +WANTLIB-lldb = clang
> +LIB_DEPENDS-lldb = ${BUILD_PKGPATH},-main
> +RUN_DEPENDS-lldb = ${MODPY_RUN_DEPENDS} \
> + devel/py-six
> +
> SEPARATE_BUILD = Yes
> CONFIGURE_ARGS = -DLLVM_ENABLE_FFI:Bool=False \
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2018/11/28 06:45:43 Modified files: net/libpsl : Makefile distinfo Added files: net/libpsl/patches: patch-tests_test-is-public-builtin_c patch-tools_psl_c Log message: Update to libpsl-0.20.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2018/11/28 06:08:19 Modified files: net/libpsl : Makefile Log message: Don't clobber LDFLAGS & make pre-configure more robust
new py-cachetools
Here's the port for py-cachetools, which is required to startup
carbon-aggregator{,-cache}.py. Only lightly tested in py3 flavor by
starting up carbon-aggregator.
martijn@
py-cachetools.tar.gz
Description: application/gzip
Re: update py-carbon
So something like this?
I'll send py-cachetools in a separate diff.
On 11/28/18 12:07 PM, Stuart Henderson wrote:
> On 2018/11/28 08:25, Martijn van Duren wrote:
>> On 11/27/18 2:36 PM, Daniel Jakots wrote:
>>> On Tue, 27 Nov 2018 12:43:52 +0100, Martijn van Duren
>>> wrote:
>>>
Here's an update to databases/py-carbon.
There's experimental support for python3, but I haven't included it
here because of other dependencies which don't yet have python3
support in our tree.
>>>
>>> Which one(s)?
>>>
>> I must have goofed somewhere. It's not py-carbon directly which has
>> "issues", but py-whisper. But let's safe that discussion for that
>> threat.
>>
>> Here's an updated diff. I don't know whether mostly executable
>> python packages should be moved to python3, or if they still
>> should come in flavors, so I just made it a flavor, so we can
>> quite easily dumb it down again if we just want python3.
>
> If it's actually useful as a library then it might be worth considering
> whether to subpackage it - have the executables as a separate package
> only built with the python3 flavour.
>
> But if (as COMMENT implies) it's only really useful as daemon/utilties
> then I'd much prefer to just switch to py3 outright. This cuts a lot of
> complexity from Makefile, patches and PLIST, and makes it so all users
> are on recent python (rather than the "default" being old python).
>
>> Note: carbon-aggregator{,-cache} doesn't work because it misses
>> py-cachetools, but people could get that themselves via pip, or it
>> could be added as a package in the future, so I left the plumbing in
>> as is.
>
> Hmm. People shouldn't be installing via pip to make packages work3
> I'd prefer to either port the dep, or @comment the files that need it.
>
>> @@ -108,3 +121,13 @@ share/examples/graphite/whitelist.conf.e
>> @sample /var/graphite/storage/whisper/
>> @owner
>> @group
>> +storage/
>> +storage/ceres/
>> +storage/ceres/dummy.txt/
>> +storage/lists/
>> +storage/log/
>> +storage/log/dummy.txt/
>> +storage/rrd/
>> +storage/rrd/dummy.txt/
>> +storage/whisper/
>> +storage/whisper/dummy.txt/
>
> It feels like these /usr/local/storage directories should not be installed,
> they are already @sample'd under /var/graphite/storage so I think should just
> be rm'd. But there are some missing @extra or @extraunexec that would be
> needed for pkg_delete -c to correctly remove files generated in this tree.
>
Index: Makefile
===
RCS file: /cvs/ports/devel/quirks/Makefile,v
retrieving revision 1.651
diff -u -p -r1.651 Makefile
--- Makefile27 Nov 2018 15:24:15 - 1.651
+++ Makefile28 Nov 2018 12:54:48 -
@@ -5,7 +5,7 @@ CATEGORIES =devel databases
DISTFILES =
# API.rev
-PKGNAME = quirks-3.44
+PKGNAME = quirks-3.45
PKG_ARCH = *
MAINTAINER = Marc Espie
Index: files/Quirks.pm
===
RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
retrieving revision 1.665
diff -u -p -r1.665 Quirks.pm
--- files/Quirks.pm 27 Nov 2018 15:24:15 - 1.665
+++ files/Quirks.pm 28 Nov 2018 12:54:48 -
@@ -288,6 +288,7 @@ my $stem_extensions = {
'py-pafy' => 'py3-pafy',
'py-libmagic' => 'py-magic',
'py3-libmagic' => 'py3-magic',
+ 'py-carbon' => 'py3-carbon',
};
my $obsolete_reason = {
Index: Makefile
===
RCS file: /cvs/ports/databases/py-carbon/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile1 Nov 2017 10:44:39 - 1.9
+++ Makefile28 Nov 2018 12:54:15 -
@@ -2,12 +2,11 @@
COMMENT= backend data caching and persistence daemon for Graphite
-MODPY_EGG_VERSION= 1.0.1
+MODPY_EGG_VERSION= 1.1.4
DISTNAME= carbon-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
CATEGORIES=databases
-REVISION= 0
# Apache
PERMIT_PACKAGE_CDROM= Yes
@@ -16,19 +15,26 @@ MODULES=lang/python
MODPY_PI = Yes
BUILD_DEPENDS= ${RUN_DEPENDS}
-RUN_DEPENDS= databases/py-whisper \
- devel/py-twisted
+RUN_DEPENDS= databases/py-whisper${MODPY_FLAVOR} \
+ devel/py-cachetools${MODPY_FLAVOR} \
+ devel/py-twisted${MODPY_FLAVOR} \
+ www/py-urllib3${MODPY_FLAVOR}
-BIN_FILES= carbon-aggregator.py carbon-cache.py carbon-client.py \
- carbon-relay.py validate-storage-schemas.py
+PYBINS=carbon-aggregator carbon-aggregator-cache
carbon-cache \
+ carbon-client carbon-relay validate-storage-schemas
-.for b in ${BIN_FILES}
-MODPY_ADJ_FILES+= bin/$b
+MODPY_VERSION= ${MODPY_DEFAULT_VERSION_3}
+
+.for b in ${PYBINS}
+MODPY_ADJ_FILES+=
Re: CVS: cvs.openbsd.org: ports
On Mon, Nov 26, 2018 at 03:35:30PM -0700, Juan Francisco Cantero Hurtado wr= ote: > CVSROOT: /cvs > Module name: ports > Changes by: juan...@cvs.openbsd.org 2018/11/26 15:35:30 >=20 > Log message: > From Timo Myyra. Help from sthen@ to a previous version. OK benoit@. >=20 > Comment: > dialect of Scheme designed for systems programming Doesn't build for me. >>> Building on exopi-5 under lang/gerbil BDEPENDS =3D [lang/gambit;textproc/libxml;databases/sqlite3] DIST =3D [lang/gerbil:gerbil-0.14.tar.gz] FULLPKGNAME =3D gerbil-0.14 RDEPENDS =3D [databases/sqlite3;devel/git;textproc/libxml;lang/gambit] (Junk lock obtained for exopi-5 at 1543402535) >>> Running depends in lang/gerbil at 1543402535 last junk was in devel/ruby-rspec/3/expectations, /usr/sbin/pkg_add -aI -Drepair gambit-4.9.1 libxml-2.9.8p0 sqlite3-3.25.1 was: /usr/sbin/pkg_add -aI -Drepair gambit-4.9.1 libxml-2.9.8p0 sqlite3-3.2= 5.1 /usr/sbin/pkg_add -aI -Drepair gambit-4.9.1 libxml-2.9.8p0 sqlite3-3.25.1 >>> Running show-prepare-results in lang/gerbil at 1543402539 =3D=3D=3D> lang/gerbil =3D=3D=3D> gerbil-0.14 depends on: gambit-* -> gambit-4.9.1 =3D=3D=3D> gerbil-0.14 depends on: sqlite3-* -> sqlite3-3.25.1 =3D=3D=3D> gerbil-0.14 depends on: libxml-* -> libxml-2.9.8p0 =3D=3D=3D> Verifying specs: c m pthread util z crypto iconv lzma sqlite3 = ssl xml2 =3D=3D=3D> found c.93.0 m.10.1 pthread.25.1 util.13.0 z.5.0 crypto.45.1 ic= onv.6.0 lzma.2.1 sqlite3.37.4 ssl.47.1 xml2.16.1 gambit-4.9.1 libxml-2.9.8p0 sqlite3-3.25.1 (Junk lock released for exopi-5 at 1543402540) distfiles size=3D1205331 >>> Running patch in lang/gerbil at 1543402540 =3D=3D=3D> lang/gerbil =3D=3D=3D> Checking files for gerbil-0.14 `/exopi-cvs/ports/distfiles/gerbil-0.14.tar.gz' is up to date. >> (SHA256) gerbil-0.14.tar.gz: OK =3D=3D=3D> Extracting for gerbil-0.14 =3D=3D=3D> Patching for gerbil-0.14 =3D=3D=3D> Applying OpenBSD patch patch-src_std_build-features_ss Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-src_std_build-features_ss,v 1.1.1.1 2018/11/26 22:35:30 ju= anfra Exp $ | |Index: src/std/build-features.ss |--- src/std/build-features.ss.orig |+++ src/std/build-features.ss -- Patching file src/std/build-features.ss using Plan A... Hunk #1 succeeded at 1. done =3D=3D=3D> Compiler link: clang -> /usr/bin/clang =3D=3D=3D> Compiler link: clang++ -> /usr/bin/clang++ =3D=3D=3D> Compiler link: cc -> /usr/bin/cc =3D=3D=3D> Compiler link: c++ -> /usr/bin/c++ >>> Running configure in lang/gerbil at 1543402541 =3D=3D=3D> lang/gerbil =3D=3D=3D> Generating configure for gerbil-0.14 =3D=3D=3D> Configuring for gerbil-0.14 >>> Running build in lang/gerbil at 1543402541 =3D=3D=3D> lang/gerbil =3D=3D=3D> Building for gerbil-0.14 cd /exopi-obj/pobj/gerbil-0.14/gerbil-0.14/src && /usr/bin/env -i CPPFLAGS= =3D-I/usr/local/include LDFLAGS=3D-L/usr/local/lib GERBIL_PATH=3D/usr/loc= al/gerbil PORTSDIR=3D"/exopi-cvs/ports" LIBTOOL=3D"/usr/bin/libtool" PATH= =3D'/exopi-obj/pobj/gerbil-0.14/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/loca= l/bin:/usr/X11R6/bin' PREFIX=3D'/usr/local' LOCALBASE=3D'/usr/local' X11BA= SE=3D'/usr/X11R6' CFLAGS=3D'-O2 -pipe' TRUEPREFIX=3D'/usr/local' DESTDIR= =3D'' HOME=3D'/gerbil-0.14_writes_to_HOME' COMPILER_VERSION=3Dclang PICFL= AG=3D"-fpic" BINGRP=3Dbin BINOWN=3Droot BINMODE=3D755 NONBINMODE=3D644 DI= RMODE=3D755 INSTALL_COPY=3D-c INSTALL_STRIP=3D-s MANGRP=3Dbin MANOWN=3Dro= ot MANMODE=3D644 BSD_INSTALL_PROGRAM=3D"/exopi-obj/pobj/gerbil-0.14/bin/ins= tall -c -s -m 755" BSD_INSTALL_SCRIPT=3D"/exopi-obj/pobj/gerbil-0.14/bin/i= nstall -c -m 755" BSD_INSTALL_DATA=3D"/exopi-obj/pobj/gerbil-0.14/bin/inst= all -c -m 644" BSD_INSTALL_MAN=3D"/exopi-obj/pobj/gerbil-0.14/bin/install = -c -m 644" BSD_INSTALL_PROGRAM_DIR=3D"/exopi-obj/pobj/gerbil-0.14/bin/inst= all -d -m 755" BSD_INSTALL_SCRIPT_DIR=3D"/exopi-obj/pobj/gerbil-0.14/bin/i= nstall -d -m 755" BSD_INSTALL_DATA_DIR=3D"/exopi-obj/pobj/gerbil-0.14/bin/= install -d -m 755" BSD_INSTALL_MAN_DIR=3D"/exopi-obj/pobj/gerbil-0.14/bin/= install -d -m 755" ./build.sh [*] Building Gerbil [*] Building gerbil stage0 >>> preparing /exopi-obj/pobj/gerbil-0.14/gerbil-0.14/bootstrap >>> compiling runtime cc: warning: argument unused during compilation: '--param max-gcse-memory= =3D3' [-Wunused-command-line-argument] cc: warning: argument unused during compilation: '--param max-gcse-memory= =3D3' [-Wunused-command-line-argument] cc: warning: argument unused during compilation: '--param max-gcse-memory= =3D3' [-Wunused-command-line-argument] cc: warning: argument unused during compilation: '--param max-gcse-memory= =3D3' [-Wunused-command-line-argument] building gerbil/runtime in /exopi-obj/pobj/gerbil-0.14/gerbil-0.14/bootstra= p/lib =2E.. compile gx-gambc =2E.. compile gx-gambc0 =2E.. compile gx-gambc1 =2E.. compile
Re: lang/gcc/6: Install missing stdatomic.h header
On 2018/11/27 19:36, George Koehler wrote:
> On Tue, 27 Nov 2018 16:12:08 -0500
> George Koehler wrote:
>
> > NetBSD's packages of gcc5 and gcc7 do contain the headers from float.h
> > to stdatomic.h (or most of them). I haven't found the reason why
> > NetBSD keeps those headers and OpenBSD doesn't.
>
> Found it!
>
> $ cat gcc-6.4.0/gcc/config/t-openbsd
> # We don't need GCC's own include files.
> USER_H = $(EXTRA_HEADERS)
>
> This t-openbsd gets enabled by gcc-6.4.0/gcc/config.gcc and then
> included by build-powerpc/{prev-gcc,gcc}/Makefile so it overrides
> USER_H. The effect is to remove gcc's float.h, iso646.h, stdarg.h,
> stdbool.h, stddef.h, varargs.h, stdfix.h, stdnoreturn.h, stdalign.h,
> stdatomic.h from the compiler.
>
> The obvious fix (though I haven't tried it) is to remove this USER_H
> override, either by commenting it or by patching config.gcc to ignore
> t-openbsd. Most platforms don't override USER_H. (The only other
> platform to override USER_H is config/mips/t-sdemtk, but its
> override looks outdated to me.)
This fix seems like the right approach in general to me, I think this
is definitely worth trying.
> Another option is to keep the USER_H override and add only the 4
> headers stdfix.h, stdnoreturn.h, stdalign.h, stdatomic.h. This may
> become outdated if a future version of gcc adds more headers.
That sounds like it's asking for future trouble.
> Another option is to add the 4 headers to base OpenBSD. If there
> is some reason why /usr/include has its own float.h, iso646.h, and so
> on, then the same reason might be why to add the 4 headers.
I'm not sure if it's the same for all of these headers, but stdatomic.h
in particular seems much more tightly bound to the compiler than to
the OS.
> gcc also has its own stdint.h, but doesn't use it on OpenBSD, because
> config.gcc defaults to use_gcc_stdint=none and has no code to enable
> it on OpenBSD.
>
> For comparison, ports-clang (pkg_info -L llvm) seems to package its
> own float.h, iso646.h, and so on, and its own stdint.h; while
> base-clang seems to omit headers that exist in /usr/include.
It does for some but not others. diff -wu of iso646.h, for example,
differs only in whitespace, copyright/PD notice, and double-inclusion
protection macro..
Re: update mpv to 0.29.1
Hi,
At first, thanks Klemens :) The ffmpeg+mpv build required no changes on
macppc.
On Sun, 18 Nov 2018 00:40:54 +0100
Klemens Nanni wrote:
> According to `port-lib-depends-check' the cd, dvd and v4l related
> libraries where extra, so I blatantly removed them including their
> LDEP.
>
> Since I don't have access to CD/DVD (readers), can anyone test mpv
> with playing physical media?
>
I don't have DVDs, but cdda support will require to bring back libcdio,
and reenable support. The diff at the bottom reintroduces it, and
still works fine here.
About macppc runtime:
Audio is ok, but when playing videos with the default gl video output,
it segfaults, here is a backtrace:
---
(gdb) run
Starting program: /usr/local/bin/mpv /tmp/test.mp4
Playing: /tmp/test.mp4
(+) Video --vid=1 (*) (h264 640x480 29.970fps)
(+) Audio --aid=1 (*) (aac 2ch 44100Hz)
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 428485]
0x0e7cc09c in gl_video_init (ra=Cannot access memory at address
0xc51e93bc ) at ../video/out/gpu/video.c:3784
3784{
(gdb) bt full
#0 0x0e7cc09c in gl_video_init (ra=Cannot access memory at address
#0xc51e93bc
) at ../video/out/gpu/video.c:3784
p = (struct gl_video *) 0xe010101
opts = (struct gl_video_opts *) 0x1
#1 0x0e7e2670 in preinit (vo=0xb6f7e720) at ../video/out/vo_gpu.c:286
p = (struct gpu_priv *) 0xbe9bd0a0
alpha_mode = 3
opts = {allow_sw = 0, want_alpha = 0, debug = 0, probing =
false, swapchain_depth = 3} __func__ = "preinit"
#2 0xa17d9ab0 in _rthread_start (v=Variable "v" is not available.
) at /usr/src/lib/librthread/rthread.c:96
No locals.
#3 0xa17d9ab0 in _rthread_start (v=Variable "v" is not available.
) at /usr/src/lib/librthread/rthread.c:96
No locals.
Previous frame inner to this frame (corrupt stack?)
---
Using '-vo sdl' allows OpenGL accelerated display, but has no fullscreen
support (scaling is wrong).
Some OpenGL infos:
---
machdep.allowaperture=1
Extended renderer info (GLX_MESA_query_renderer):
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: ATI RV350
OpenGL version string: 2.1 Mesa 17.3.9
OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 17.3.9
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
---
Mplayer runs fine with its own gl backend, and all stuff using OpenGL
i've installed work properly on this box.
I've totally no idea on how to fix it, but i think we can't let mpv's
default invocation generates a segfault, so the diff disables '-vo gl'
support only for macpcc, implicitly using the old and working Xv video
output by default instead.
Charlène.
Index: Makefile
===
RCS file: /cvs/ports/multimedia/mpv/Makefile,v
retrieving revision 1.44
diff -u -p -r1.44 Makefile
--- Makefile25 Nov 2018 10:09:25 - 1.44
+++ Makefile28 Nov 2018 11:06:43 -
@@ -4,17 +4,16 @@ COMMENT = movie player based on MPlayer
GH_ACCOUNT = mpv-player
GH_PROJECT = mpv
-GH_TAGNAME = v0.22.0
-REVISION = 5
+GH_TAGNAME = v0.29.1
CATEGORIES = multimedia x11
-HOMEPAGE = http://mpv.io/
+HOMEPAGE = https://mpv.io/
MAINTAINER = Dmitrij D. Czarkoff
-WAF = ${WRKSRC}/waf-1.8.19
-MASTER_SITES0 =http://waf.io/
+WAF = ${WRKSRC}/waf-2.0.12
+MASTER_SITES0 =https://waf.io/
DISTFILES =${DISTNAME}{${GH_TAGNAME}}${EXTRACT_SUFX} ${WAF:T}:0
EXTRACT_ONLY = ${DISTNAME}${EXTRACT_SUFX}
@@ -22,14 +21,11 @@ EXTRACT_ONLY = ${DISTNAME}${EXTRACT_SUF
PERMIT_PACKAGE_CDROM = patents
PERMIT_PACKAGE_FTP = Yes
-WANTLIB += EGL GL SDL2 X11 X11-xcb Xau Xdamage Xdmcp Xext Xfixes
-WANTLIB += Xinerama Xrandr Xrender Xss Xv Xxf86vm ass avcodec
-WANTLIB += avdevice avfilter avformat avresample avutil bluray
-WANTLIB += c cdio cdio_cdda cdio_paranoia drm dvdnav dvdread expat
-WANTLIB += fontconfig freetype fribidi gbm iconv jpeg lcms2 m
-WANTLIB += opus postproc pthread sndio speex swresample
-WANTLIB += swscale v4l2 v4lconvert vpx x264 x265 xcb xcb-dri2
-WANTLIB += xcb-glx z ${MODLUA_WANTLIB}
+WANTLIB += ${MODLUA_WANTLIB} EGL GL SDL2 X11 X11-xcb Xau Xdamage Xdmcp Xext
+WANTLIB += Xfixes Xinerama Xrandr Xrender Xss Xv Xxf86vm ass avcodec avdevice
+WANTLIB += avfilter avformat avutil bluray c cdio cdio_cdda cdio_paranoia
+WANTLIB += drm expat fontconfig freetype fribidi gbm iconv jpeg lcms2 m
+WANTLIB += postproc pthread sndio swresample swscale xcb xcb-dri2 xcb-glx z
MODULES = lang/lua \
lang/python
@@ -39,7 +35,6 @@ BUILD_DEPENDS = audio/ladspa \
LIB_DEPENDS = audio/libcdio \
Re: update py-carbon
On 2018/11/28 08:25, Martijn van Duren wrote:
> On 11/27/18 2:36 PM, Daniel Jakots wrote:
> > On Tue, 27 Nov 2018 12:43:52 +0100, Martijn van Duren
> > wrote:
> >
> >> Here's an update to databases/py-carbon.
> >> There's experimental support for python3, but I haven't included it
> >> here because of other dependencies which don't yet have python3
> >> support in our tree.
> >
> > Which one(s)?
> >
> I must have goofed somewhere. It's not py-carbon directly which has
> "issues", but py-whisper. But let's safe that discussion for that
> threat.
>
> Here's an updated diff. I don't know whether mostly executable
> python packages should be moved to python3, or if they still
> should come in flavors, so I just made it a flavor, so we can
> quite easily dumb it down again if we just want python3.
If it's actually useful as a library then it might be worth considering
whether to subpackage it - have the executables as a separate package
only built with the python3 flavour.
But if (as COMMENT implies) it's only really useful as daemon/utilties
then I'd much prefer to just switch to py3 outright. This cuts a lot of
complexity from Makefile, patches and PLIST, and makes it so all users
are on recent python (rather than the "default" being old python).
> Note: carbon-aggregator{,-cache} doesn't work because it misses
> py-cachetools, but people could get that themselves via pip, or it
> could be added as a package in the future, so I left the plumbing in
> as is.
Hmm. People shouldn't be installing via pip to make packages work3
I'd prefer to either port the dep, or @comment the files that need it.
> @@ -108,3 +121,13 @@ share/examples/graphite/whitelist.conf.e
> @sample /var/graphite/storage/whisper/
> @owner
> @group
> +storage/
> +storage/ceres/
> +storage/ceres/dummy.txt/
> +storage/lists/
> +storage/log/
> +storage/log/dummy.txt/
> +storage/rrd/
> +storage/rrd/dummy.txt/
> +storage/whisper/
> +storage/whisper/dummy.txt/
It feels like these /usr/local/storage directories should not be installed,
they are already @sample'd under /var/graphite/storage so I think should just
be rm'd. But there are some missing @extra or @extraunexec that would be
needed for pkg_delete -c to correctly remove files generated in this tree.
