security update: postgresql 9.4.4 -> 9.4.5
Hi ports this updates postgres, deletes one patch because now its applied upstream. http://www.postgresql.org/about/news/1615/ tested in amd64@ with: $ make test NO_TEST=No also tested dependents: databases/p5-DBD-Pg databases/p5-Mojo-Pg with $ make test; any comments about removing NO_TEST=Yes in databases/postgresql? tests didn't asked for any user intervention nor any SYSV changes - in amd64@ at least... comments? thanks patch attached as I use gmail... Index: Makefile === RCS file: /cvs/ports/databases/postgresql/Makefile,v retrieving revision 1.207 diff -u -p -r1.207 Makefile --- Makefile 3 Aug 2015 07:42:30 - 1.207 +++ Makefile 3 Nov 2015 07:32:39 - @@ -11,7 +11,7 @@ BROKEN-sparc= Requires v9|v9a|v9b; reque # DO NOT FORGET to also change the @ask-update entry in pkg/PLIST-server # in case a dump before / restore after pkg_add -u is required! -VERSION= 9.4.4 +VERSION= 9.4.5 DISTNAME= postgresql-${VERSION} PKGNAME-main= postgresql-client-${VERSION} PKGNAME-server= postgresql-server-${VERSION} Index: distinfo === RCS file: /cvs/ports/databases/postgresql/distinfo,v retrieving revision 1.57 diff -u -p -r1.57 distinfo --- distinfo 22 Jun 2015 07:29:42 - 1.57 +++ distinfo 3 Nov 2015 07:32:39 - @@ -1,2 +1,2 @@ -SHA256 (postgresql-9.4.4.tar.gz) = mm885nfV8UmQH8dsEZgokahGvLkogGnZGBHatqGBF2Y= -SIZE (postgresql-9.4.4.tar.gz) = 23113477 +SHA256 (postgresql-9.4.5.tar.gz) = qh15GK54Kg/F4Yhv1GP8iQPl/8PrbTtRUABlrsmIohA= +SIZE (postgresql-9.4.5.tar.gz) = 23211720 Index: patches/patch-src_include_storage_barrier_h === RCS file: patches/patch-src_include_storage_barrier_h diff -N patches/patch-src_include_storage_barrier_h --- patches/patch-src_include_storage_barrier_h 16 Jan 2015 23:24:15 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,15 +0,0 @@ -$OpenBSD: patch-src_include_storage_barrier_h,v 1.1 2015/01/16 23:24:15 landry Exp $ - -fix build on alpha - src/include/storage/barrier.h.orig Fri Jan 16 13:08:20 2015 -+++ src/include/storage/barrier.h Fri Jan 16 13:24:05 2015 -@@ -117,7 +117,7 @@ extern slock_t dummy_spinlock; - * read barrier to cover that case. We might need to add that later. - */ - #define pg_memory_barrier() __asm__ __volatile__ ("mb" : : : "memory") --#define pg_read_barrier() __asm__ __volatile__ ("rmb" : : : "memory") -+#define pg_read_barrier() __asm__ __volatile__ ("mb" : : : "memory") - #define pg_write_barrier() __asm__ __volatile__ ("wmb" : : : "memory") - #elif defined(__hppa) || defined(__hppa__) /* HP PA-RISC */ - Index: pkg/PLIST-docs === RCS file: /cvs/ports/databases/postgresql/pkg/PLIST-docs,v retrieving revision 1.69 diff -u -p -r1.69 PLIST-docs --- pkg/PLIST-docs 22 Jun 2015 07:29:42 - 1.69 +++ pkg/PLIST-docs 3 Nov 2015 07:32:39 - @@ -485,6 +485,7 @@ share/doc/postgresql/html/monitoring-ps. share/doc/postgresql/html/monitoring-stats.html share/doc/postgresql/html/monitoring.html share/doc/postgresql/html/multibyte.html +share/doc/postgresql/html/mvcc-caveats.html share/doc/postgresql/html/mvcc-intro.html share/doc/postgresql/html/mvcc.html share/doc/postgresql/html/nls-programmer.html @@ -826,6 +827,7 @@ share/doc/postgresql/html/release-9-0-2. share/doc/postgresql/html/release-9-0-20.html share/doc/postgresql/html/release-9-0-21.html share/doc/postgresql/html/release-9-0-22.html +share/doc/postgresql/html/release-9-0-23.html share/doc/postgresql/html/release-9-0-3.html share/doc/postgresql/html/release-9-0-4.html share/doc/postgresql/html/release-9-0-5.html @@ -844,6 +846,7 @@ share/doc/postgresql/html/release-9-1-15 share/doc/postgresql/html/release-9-1-16.html share/doc/postgresql/html/release-9-1-17.html share/doc/postgresql/html/release-9-1-18.html +share/doc/postgresql/html/release-9-1-19.html share/doc/postgresql/html/release-9-1-2.html share/doc/postgresql/html/release-9-1-3.html share/doc/postgresql/html/release-9-1-4.html @@ -858,6 +861,7 @@ share/doc/postgresql/html/release-9-2-10 share/doc/postgresql/html/release-9-2-11.html share/doc/postgresql/html/release-9-2-12.html share/doc/postgresql/html/release-9-2-13.html +share/doc/postgresql/html/release-9-2-14.html share/doc/postgresql/html/release-9-2-2.html share/doc/postgresql/html/release-9-2-3.html share/doc/postgresql/html/release-9-2-4.html @@ -868,6 +872,7 @@ share/doc/postgresql/html/release-9-2-8. share/doc/postgresql/html/release-9-2-9.html share/doc/postgresql/html/release-9-2.html share/doc/postgresql/html/release-9-3-1.html +share/doc/postgresql/html/release-9-3-10.html share/doc/postgresql/html/release-9-3-2.html share/doc/postgresql/html/release-9-3-3.html share/doc/postgresql/html/release-9-3-4.html @@ -881,6 +886,7 @@ share/doc/postgresql/html/release-9-4-1. sha
Re: Clarification about out-of-date script
On Tue, Nov 03, 2015 at 02:19:51AM +0100, Juan Francisco Cantero Hurtado wrote: > On Sun, Nov 01, 2015 at 11:41:21PM +0500, Артур Истомин wrote: > > Here is output on my system, OpenBSD 5.8, from out-of-date script: > > > > databases/postgresql,-server # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > > devel/quirks # always-update -> quirks-2.114 > > editors/libreoffice,-main # @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > > misc/shared-mime-info # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > > multimedia/libbluray # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > > print/cups,-libs # @gnutls-3.3.16 -> @gnutls-3.3.16p0 > > textproc/raptor# @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > > x11/gnome/librsvg # @gdk-pixbuf-2.30.8p1,@libxml-2.9.2p1 -> > > @gdk-pixbuf-2.30.8p3,@libxml-2.9.2p2 > > x11/gtk+2,-main# @gdk-pixbuf-2.30.8p1 -> > > @gdk-pixbuf-2.30.8p3 > > x11/gtk+3,-guic# @gdk-pixbuf-2.30.8p1 -> > > @gdk-pixbuf-2.30.8p3 > > x11/kde/libs3,-main# @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > > > > Am I right, that left column is ports/packages that can be updated; right > > column is reason why they need to be updated? > > Yes. > > > Also is it true that in my case I can ignore all this updates because > > all ports from left column are dynamicaly linked with already updated > > library from right column? > > No. Those ports use the outdated version of the library. Can You elaborate, please, I don't understand. E.g. shared-mime-info. $ ldd /usr/local/bin/update-mime-database | grep libxml 1d0114c0 1d011515f000 rlib 01 0 /usr/local/lib/libxml2.so.15.1 $ pkg_info | grep libxml libxml-2.9.2p2 XML parsing library So libxml already updated. If I understand correctly: if libxml updated and update-mime-database _dynamicaly_ linked to it there is no need further intervention, is not is so? Thanks.
[UPDATE] sysutils/tarsnap-gui
Updated to version 0.7. Tested on amd64, with both a simple tiling window manager and also with Gnome, to test a new notification feature. A pkg-readme was added with one paragraph of upgrade notes, excerpted from the upstream CHANGELOG. OK? Index: Makefile === RCS file: /systems/cvs/ports/sysutils/tarsnap-gui/Makefile,v retrieving revision 1.2 diff -u -p -r1.2 Makefile --- Makefile25 Aug 2015 06:09:37 - 1.2 +++ Makefile2 Nov 2015 21:43:09 - @@ -2,7 +2,7 @@ COMMENT = frontend to the popular Tarsnap backup service -V =0.6 +V =0.7 DISTNAME = tarsnap-gui-${V} CATEGORIES = sysutils Index: distinfo === RCS file: /systems/cvs/ports/sysutils/tarsnap-gui/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- distinfo25 Aug 2015 00:19:42 - 1.1.1.1 +++ distinfo2 Nov 2015 21:50:44 - @@ -1,2 +1,2 @@ -SHA256 (tarsnap-gui-0.6.tar.gz) = 03hwCVC90M9qRr5rOBnSt8JQND3UEGcZfTfDWyJ8ruM= -SIZE (tarsnap-gui-0.6.tar.gz) = 498174 +SHA256 (tarsnap-gui-0.7.tar.gz) = /oGXBYmZi29YSzYw/SxbwnD1z0WeCFcvIxUcWjCdLjM= +SIZE (tarsnap-gui-0.7.tar.gz) = 538960 Index: pkg/PLIST === RCS file: /systems/cvs/ports/sysutils/tarsnap-gui/pkg/PLIST,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 PLIST --- pkg/PLIST 25 Aug 2015 00:19:42 - 1.1.1.1 +++ pkg/PLIST 3 Nov 2015 03:49:10 - @@ -1,2 +1,3 @@ @comment $OpenBSD: PLIST,v 1.1.1.1 2015/08/25 00:19:42 jturner Exp $ @bin bin/tarsnap-gui +share/doc/pkg-readmes/${FULLPKGNAME} Index: pkg/README === RCS file: pkg/README diff -N pkg/README --- /dev/null 1 Jan 1970 00:00:00 - +++ pkg/README 3 Nov 2015 03:51:23 - @@ -0,0 +1,15 @@ +$OpenBSD: + ++--- +| Running ${FULLPKGNAME} on OpenBSD ++--- + +Upgrading from an earlier version += + +Some internally used settings keys have been renamed for consistency and +upon upgrading from an older version the setup wizard dialog will pop +up. Follow the prompts and select "Yes" when asked if you have used +Tarsnap on this machine in the past and have a key. Select the previous +key if available in the dropdown list or locate it manually and proceed. +Your jobs and settings should remain unchanged.
Re: Clarification about out-of-date script
On Sun, Nov 01, 2015 at 11:41:21PM +0500, Артур Истомин wrote: > Here is output on my system, OpenBSD 5.8, from out-of-date script: > > databases/postgresql,-server # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > devel/quirks # always-update -> quirks-2.114 > editors/libreoffice,-main # @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > misc/shared-mime-info # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > multimedia/libbluray # @libxml-2.9.2p1 -> @libxml-2.9.2p2 > print/cups,-libs # @gnutls-3.3.16 -> @gnutls-3.3.16p0 > textproc/raptor# @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > x11/gnome/librsvg # @gdk-pixbuf-2.30.8p1,@libxml-2.9.2p1 -> > @gdk-pixbuf-2.30.8p3,@libxml-2.9.2p2 > x11/gtk+2,-main# @gdk-pixbuf-2.30.8p1 -> @gdk-pixbuf-2.30.8p3 > x11/gtk+3,-guic# @gdk-pixbuf-2.30.8p1 -> @gdk-pixbuf-2.30.8p3 > x11/kde/libs3,-main# @libxslt-1.1.28p2 -> @libxslt-1.1.28p3 > > Am I right, that left column is ports/packages that can be updated; right > column is reason why they need to be updated? Yes. > Also is it true that in my case I can ignore all this updates because > all ports from left column are dynamicaly linked with already updated > library from right column? No. Those ports use the outdated version of the library. -- Juan Francisco Cantero Hurtado http://juanfra.info
Vulnerable packages in ports tree 03/11
net/miniupnpc - http://talosintel.com/reports/TALOS-2015-0035/ databases/postgresql - http://www.postgresql.org/about/news/1615/
Re: Update: graphics/dpic
On 09/03/15 22:04, Nigel wrote: > Update to version 2015.08.31 > > Minor changes > 2015 08 31 Ljust and rjust text offset equal for single and multiple > strings. > 2015 08 13 Catch return value of the sh command. > 2015 06 29 Fixed a bug in svg output. > 2015 06 15 Undeferred error messaging. Improved readability of C code. > 2015 04 01 Fix comment lines containing braces in macro and for bodies. > Revised messages for some errors. > 2015 02 13 Reworked the handling of backslashes in strings in macro > arguments. > 2015 02 04 PDF output. Built-in variable dpicopt and variables added for > detecting command options. Linear objects reworked for consistent fill. > 2014 01 26 Tweak svg string output. > > > Added some testing by using make on the examples. > (Used browser/inkscape/ghostscript etc to view generated files.) > > Only tested on amd64. Please test on other. > > Ok? > There is a newer version 2015.10.28 available, attached a new diff for this version. Index: Makefile === RCS file: /home/cvs/ports/graphics/dpic/Makefile,v retrieving revision 1.5 diff -u -p -r1.5 Makefile --- Makefile 23 Oct 2014 13:43:04 - 1.5 +++ Makefile 2 Nov 2015 16:37:25 - @@ -2,8 +2,7 @@ COMMENT = pic-like interpreter for producing line graphics -DISTNAME = dpic-2014.Jan.01 -PKGNAME = ${DISTNAME:S/Jan/01/} +DISTNAME = dpic-2015.10.28 CATEGORIES = graphics @@ -19,12 +18,18 @@ ALL_TARGET = dpic MASTER_SITES = ${HOMEPAGE} + +TEST_DEPENDS = print/texlive/base \ + print/texlive/texmf,-main + do-install: ${INSTALL_PROGRAM} ${WRKSRC}/dpic ${PREFIX}/bin ${INSTALL_MAN} ${WRKSRC}/doc/dpic.1 ${PREFIX}/man/man1 ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/dpic/ - cd ${WRKSRC}/examples/ && pax -rw * ${PREFIX}/share/examples/dpic/ + cd ${WRKSRC}/examples/ && pax -rw sources Examples.txt Makefile README ${PREFIX}/share/examples/dpic/ -NO_TEST = Yes +do-test: + cd ${WRKSRC}/examples/ && \ + make -e DPIC=${WRKSRC}/dpic all .include Index: distinfo === RCS file: /home/cvs/ports/graphics/dpic/distinfo,v retrieving revision 1.4 diff -u -p -r1.4 distinfo --- distinfo 23 Oct 2014 13:43:05 - 1.4 +++ distinfo 2 Nov 2015 16:37:47 - @@ -1,2 +1,2 @@ -SHA256 (dpic-2014.Jan.01.tar.gz) = Bb5z+hrYrkPonP4cDqkF0RtL5eezWcbn805Rpx6nv8U= -SIZE (dpic-2014.Jan.01.tar.gz) = 584351 +SHA256 (dpic-2015.10.28.tar.gz) = uI4+N0HMgqghC+4fvtCgtFePbr8Pwv2PazUvX1Y2hpI= +SIZE (dpic-2015.10.28.tar.gz) = 624682 Index: pkg/PLIST === RCS file: /home/cvs/ports/graphics/dpic/pkg/PLIST,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 PLIST --- pkg/PLIST 15 May 2011 18:49:41 - 1.1.1.1 +++ pkg/PLIST 20 Jun 2015 16:02:30 - @@ -15,6 +15,7 @@ share/examples/dpic/sources/diag8.pic share/examples/dpic/sources/diag9.pic share/examples/dpic/sources/diagA.pic share/examples/dpic/sources/diagB.pic +share/examples/dpic/sources/diagC.pic share/examples/dpic/sources/test1.tex share/examples/dpic/sources/test2.tex share/examples/dpic/sources/test3.tex
Re: NEW: net/tinc
On 2015/11/02 22:08, Stuart Henderson wrote: > I've got a bit more on top of this, will send it in a bit.. > - remove pointless lines from Makefile - install sample config - patch out mentions of '/dev/tun* link0' for OpenBSD, this is now /dev/tap* - add a uid, use it and chroot in tincd.rc - no need to override the standard functions in tincd.rc It could maybe also do with a little README showing people which files to edit and how to set tincd_flags in rc.conf.local to override the default config. So far I've only tested starting one side, not actually passing any traffic. tinc.tgz Description: application/tar-gz
Re: [update] Imapfilter 2.6.3
On 2015/11/02 22:58, Jérémie Courrèges-Anglas wrote: > Michael McConville writes: > > > They added some new SSL conditions that don't compile. I took the simple > > route in the attached patches and defaulted to SSL23. > > Well, simple but a bit intrusive... > > > That uses the best > > available cipher, right? > > That uses the default cipher suite. > > > This approach is a little iffy because I think > > it ignores the user's cipher prefs. I wanted to get a working WiP so > > that people could review it because I haven't worked with SSL/TLS APIs > > before. > > > > What's attached builds and runs fine for me. > > Here's an less intrusive diff that should be easy to push upstream. yep, I much prefer this. > (Except in special cases, please send diffs instead of tarballs for > existing ports). cvs add $file cvs rm $file cvs diff -uNp for openbsd devs: do your adds against the master repo unless you are sure that you're not re-adding a file from the Attic.
Re: NEW: net/tinc
I've got a bit more on top of this, will send it in a bit..
Re: [update] Imapfilter 2.6.3
Michael McConville writes: > They added some new SSL conditions that don't compile. I took the simple > route in the attached patches and defaulted to SSL23. Well, simple but a bit intrusive... > That uses the best > available cipher, right? That uses the default cipher suite. > This approach is a little iffy because I think > it ignores the user's cipher prefs. I wanted to get a working WiP so > that people could review it because I haven't worked with SSL/TLS APIs > before. > > What's attached builds and runs fine for me. Here's an less intrusive diff that should be easy to push upstream. (Except in special cases, please send diffs instead of tarballs for existing ports). If SSLv3 isn't available, this should print an error message an aborts the connection. Disclaimer: not tested yet. Index: Makefile === RCS file: /cvs/ports/mail/imapfilter/Makefile,v retrieving revision 1.17 diff -u -p -r1.17 Makefile --- Makefile18 Jul 2015 23:11:01 - 1.17 +++ Makefile2 Nov 2015 21:50:50 - @@ -2,8 +2,7 @@ COMMENT= remote IMAP filtering utility -V= 2.6.1 -REVISION= 0 +V= 2.6.3 DISTNAME= imapfilter-${V} GH_TAGNAME=v${V} Index: distinfo === RCS file: /cvs/ports/mail/imapfilter/distinfo,v retrieving revision 1.9 diff -u -p -r1.9 distinfo --- distinfo29 Jun 2015 09:52:25 - 1.9 +++ distinfo2 Nov 2015 21:50:50 - @@ -1,2 +1,2 @@ -SHA256 (imapfilter-2.6.1.tar.gz) = 2UlKUgg3aWh+eA2kHPmk0hvrVq9YY6+z28SiEJ7VwdM= -SIZE (imapfilter-2.6.1.tar.gz) = 55450 +SHA256 (imapfilter-2.6.3.tar.gz) = EXSGLW1cpJiyWnixJ8Jba/vUwM7DD439S2sQ+GlM0kQ= +SIZE (imapfilter-2.6.3.tar.gz) = 55757 Index: patches/patch-src_imapfilter_c === RCS file: /cvs/ports/mail/imapfilter/patches/patch-src_imapfilter_c,v retrieving revision 1.2 diff -u -p -r1.2 patch-src_imapfilter_c --- patches/patch-src_imapfilter_c 18 Jul 2015 23:11:01 - 1.2 +++ patches/patch-src_imapfilter_c 2 Nov 2015 21:50:50 - @@ -1,6 +1,9 @@ $OpenBSD: patch-src_imapfilter_c,v 1.2 2015/07/18 23:11:01 sthen Exp $ src/imapfilter.c.orig Mon Jun 29 02:33:17 2015 -+++ src/imapfilter.c Sat Jul 18 18:34:04 2015 + +Cope with SSLv3 removal. + +--- src/imapfilter.c.orig Wed Sep 30 22:55:26 2015 src/imapfilter.c Mon Nov 2 22:37:03 2015 @@ -21,7 +21,10 @@ extern buffer ibuf, obuf, nbuf, cbuf; @@ -13,16 +16,7 @@ $OpenBSD: patch-src_imapfilter_c,v 1.2 2 #if OPENSSL_VERSION_NUMBER >= 0x01000100fL extern SSL_CTX *tls11ctx, *tls12ctx; #endif -@@ -52,7 +55,7 @@ main(int argc, char *argv[]) - opts.config = NULL; - opts.oneline = NULL; - opts.debug = NULL; -- opts.truststore = "/etc/ssl/certs"; -+ opts.truststore = "/etc/ssl/cert.pem"; - - env.home = NULL; - env.pathmax = -1; -@@ -109,7 +112,9 @@ main(int argc, char *argv[]) +@@ -114,7 +117,9 @@ main(int argc, char *argv[]) SSL_library_init(); SSL_load_error_strings(); @@ -32,9 +26,9 @@ $OpenBSD: patch-src_imapfilter_c,v 1.2 2 ssl23ctx = SSL_CTX_new(SSLv23_client_method()); tls1ctx = SSL_CTX_new(TLSv1_client_method()); #if OPENSSL_VERSION_NUMBER >= 0x01000100fL -@@ -121,7 +126,9 @@ main(int argc, char *argv[]) +@@ -125,7 +130,9 @@ main(int argc, char *argv[]) capath = opts.truststore; - if (exists_file(opts.truststore)) + else if (exists_file(opts.truststore)) cafile = opts.truststore; +#ifndef OPENSSL_NO_SSL3_METHOD SSL_CTX_load_verify_locations(ssl3ctx, cafile, capath); @@ -42,7 +36,7 @@ $OpenBSD: patch-src_imapfilter_c,v 1.2 2 SSL_CTX_load_verify_locations(ssl23ctx, cafile, capath); SSL_CTX_load_verify_locations(tls1ctx, cafile, capath); #if OPENSSL_VERSION_NUMBER >= 0x01000100fL -@@ -146,7 +153,9 @@ main(int argc, char *argv[]) +@@ -150,7 +157,9 @@ main(int argc, char *argv[]) #endif stop_lua(); Index: patches/patch-src_socket_c === RCS file: patches/patch-src_socket_c diff -N patches/patch-src_socket_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_socket_c 2 Nov 2015 21:50:50 - @@ -0,0 +1,32 @@ +$OpenBSD$ + +Cope with SSLv3 removal. + +--- src/socket.c.orig Wed Sep 30 22:55:26 2015 src/socket.c Mon Nov 2 22:47:35 2015 +@@ -16,8 +16,10 @@ + #include "imapfilter.h" + #include "session.h" + +- +-SSL_CTX *ssl3ctx, *ssl23ctx, *tls1ctx; ++SSL_CTX *ssl23ctx, *tls1ctx; ++#ifndef OPENSSL_NO_SSL3_METHOD ++SSL_CTX *ssl3ctx; ++#endif + #if OPENSSL_VERSION_NUMBER >= 0x01000100fL + SSL_CTX *tls11ctx, *tls12ctx; + #endif +@@ -95,7 +97,12 @@ open_secure_connection(session *ssn) + if (!ssn->sslproto) { +
[update] Imapfilter 2.6.3
They added some new SSL conditions that don't compile. I took the simple route in the attached patches and defaulted to SSL23. That uses the best available cipher, right? This approach is a little iffy because I think it ignores the user's cipher prefs. I wanted to get a working WiP so that people could review it because I haven't worked with SSL/TLS APIs before. What's attached builds and runs fine for me. imapfilter.tgz Description: application/tar-gz
Re: NEW: net/tinc
Rafael Sadowski writes: > Hey @ports, Hi, > after really long time in jasperla/openbsd-wip and intensive testing from an > openbsd-wip-user, I'm happy to push a ready tinc port. > > I hope this nice stuff will find some Okays or feedback. I have been reviewing this port already, sadly the machine I tested it on has since vanished. Here are the tweaks I found, mostly from memory: - kill useless trailing backslashes - fix tincd.rc header - use ${rcexec} to start tincd, so that people can eg. put tincd in a specific login class (eg. to have more file descriptors available) tincd can change its uid after startup, is there any reason not to enable this in the default config, by providing a dedicated _tincd:_tincd user? Updated tarball attached, diff below. Cheers, diff -pruN tinc.orig/Makefile tinc/Makefile --- tinc.orig/Makefile Fri Oct 9 00:40:38 2015 +++ tinc/Makefile Mon Nov 2 22:06:59 2015 @@ -15,9 +15,9 @@ WANTLIB += c crypto lzo2 z MASTER_SITES = http://www.tinc-vpn.org/packages/ -MODULES = converters/libiconv \ +MODULES = converters/libiconv -LIB_DEPENDS += archivers/lzo2 \ +LIB_DEPENDS += archivers/lzo2 USE_GMAKE =Yes USE_LIBTOOL= gnu @@ -28,7 +28,7 @@ CONFIGURE_ENV=CPPFLAGS="-I${LOCALBASE}/include" \ LDFLAGS="-L${LOCALBASE}/lib" CONFIGURE_ARGS = --sysconfdir=/etc \ ---prefix=${LOCALBASE} \ +--prefix=${LOCALBASE} .include diff -pruN tinc.orig/pkg/tincd.rc tinc/pkg/tincd.rc --- tinc.orig/pkg/tincd.rc Fri Oct 9 00:40:38 2015 +++ tinc/pkg/tincd.rc Mon Nov 2 22:08:40 2015 @@ -1,13 +1,13 @@ -# $OpenBSD: #!/bin/sh +# +# $OpenBSD$ daemon="${TRUEPREFIX}/sbin/tincd" . /etc/rc.d/rc.subr - rc_start() { - ${daemon} + ${rcexec} "${daemon}" } rc_reload() { tinc.tgz Description: Binary data -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: www/youtube-dl fetch fails due to ssl handshake failure
On 2015/11/02 19:45, Markus Lude wrote: > On Sat, Oct 24, 2015 at 09:05:27PM +0200, Markus Lude wrote: > > Hello Paul, > > Hello again, > > > make fetch fails for recent youtube-dl: > > > > ===> Checking files for youtube-dl-2015.10.24 > > >> Fetch https://yt-dl.org/downloads/2015.10.24/youtube-dl-2015.10.24.tar.gz > > ftp: SSL read error: read failed: error:140940E5:SSL > > routines:SSL3_READ_BYTES:ssl handshake failure > > recent update to youtube-dl-2015.11.01 fails too at the dowenload stage: > > ===> Checking files for youtube-dl-2015.11.01 > >> Fetch https://yt-dl.org/downloads/2015.11.01/youtube-dl-2015.11.01.tar.gz > ftp: SSL read error: read failed: error:140940E5:SSL > routines:SSL3_READ_BYTES:ssl handshake failure > > > quick workaround: use http instead? > > Regards, > Markus > The https server for yt-dl.org requires SNI, is there anything unusual about the way you're connecting to it (weird proxy or something)? It would be interesting to see what 'nc -vvc yt-dl.org 443' says.
[update] perl6: rakudo/nqp/moarvm to 2015.10, parrot to 7.9.0
Updates everything to the latest (October) release. The path patches for nqp and moarvm are no longer needed as those paths are used upstream. Index: lang/moarvm/Makefile === RCS file: /cvs/ports/lang/moarvm/Makefile,v retrieving revision 1.7 diff -u -p -u -r1.7 Makefile --- lang/moarvm/Makefile17 Aug 2015 09:02:36 - 1.7 +++ lang/moarvm/Makefile2 Nov 2015 20:10:24 - @@ -8,11 +8,11 @@ BROKEN-sparc64 = undefined reference to COMMENT = virtual machine for nqp/rakudo -V =2015.03 +V =2015.10 DISTNAME = MoarVM-$V PKGNAME = moarvm-$V -SHARED_LIBS = moar2.0 +SHARED_LIBS = moar3.0 CATEGORIES = lang Index: lang/moarvm/distinfo === RCS file: /cvs/ports/lang/moarvm/distinfo,v retrieving revision 1.3 diff -u -p -u -r1.3 distinfo --- lang/moarvm/distinfo9 Apr 2015 17:20:50 - 1.3 +++ lang/moarvm/distinfo2 Nov 2015 20:10:24 - @@ -1,2 +1,2 @@ -SHA256 (MoarVM-2015.03.tar.gz) = /Ev66aAEyfJmxTiBrjdZVdrrhJNrkFWuSGGU4GyuxKA= -SIZE (MoarVM-2015.03.tar.gz) = 3071511 +SHA256 (MoarVM-2015.10.tar.gz) = LQX7rHqkMdWhBiWVjfHz1Hlj157eLIdfUv7D6mXqRF8= +SIZE (MoarVM-2015.10.tar.gz) = 3247914 Index: lang/moarvm/patches/patch-build_probe_pm === RCS file: lang/moarvm/patches/patch-build_probe_pm diff -N lang/moarvm/patches/patch-build_probe_pm --- /dev/null 1 Jan 1970 00:00:00 - +++ lang/moarvm/patches/patch-build_probe_pm2 Nov 2015 20:10:24 - @@ -0,0 +1,12 @@ +$OpenBSD$ +--- build/probe.pm.orig Tue Nov 3 15:56:04 2015 build/probe.pm Tue Nov 3 15:56:46 2015 +@@ -57,7 +57,7 @@ + push @objs, $obj; + } + +-my $command = "$config->{ld} $config->{ldout}$leaf @objs $config->{ldlibs} >$devnull 2>&1"; ++my $command = "$config->{ld} $config->{ldout}$leaf @objs $config->{lddir}$config->{prefix}/lib $config->{ldlibs} >$devnull 2>&1"; + system $command + and return; + return 1; Index: lang/moarvm/patches/patch-build_setup_pm === RCS file: /cvs/ports/lang/moarvm/patches/patch-build_setup_pm,v retrieving revision 1.1 diff -u -p -u -r1.1 patch-build_setup_pm --- lang/moarvm/patches/patch-build_setup_pm3 Feb 2015 13:24:19 - 1.1 +++ lang/moarvm/patches/patch-build_setup_pm2 Nov 2015 20:10:24 - @@ -1,11 +1,11 @@ $OpenBSD: patch-build_setup_pm,v 1.1 2015/02/03 13:24:19 pascal Exp $ build/setup.pm.origFri Dec 12 17:40:52 2014 -+++ build/setup.pm Fri Dec 12 17:41:14 2014 -@@ -129,7 +129,7 @@ our %TC_POSIX = ( +--- build/setup.pm.orig Tue Nov 3 15:51:06 2015 build/setup.pm Tue Nov 3 15:51:40 2015 +@@ -125,7 +125,7 @@ ccshared => '-fPIC', ldshared => '-shared @ccshared@', moarshared => '', --ldrpath=> '-Wl,-rpath,@libdir@', +-ldrpath=> '-Wl,-rpath,@libdir@ -Wl,-rpath,@prefix@/share/perl6/site/lib', +ldrpath=> '-Wl,-rpath,@libdir@ @lddir@@libdir@', arflags => 'rcs', Index: lang/moarvm/pkg/PLIST === RCS file: /cvs/ports/lang/moarvm/pkg/PLIST,v retrieving revision 1.3 diff -u -p -u -r1.3 PLIST --- lang/moarvm/pkg/PLIST 9 Apr 2015 17:20:51 - 1.3 +++ lang/moarvm/pkg/PLIST 2 Nov 2015 20:10:24 - @@ -97,8 +97,6 @@ include/libuv/uv-unix.h include/libuv/uv-version.h include/libuv/uv-win.h include/libuv/uv.h -include/linenoise/ -include/linenoise/linenoise.h include/moar/ include/moar/6model/ include/moar/6model/6model.h @@ -109,9 +107,11 @@ include/moar/6model/reprconv.h include/moar/6model/reprs/ include/moar/6model/reprs.h include/moar/6model/reprs/CArray.h +include/moar/6model/reprs/CPPStruct.h include/moar/6model/reprs/CPointer.h include/moar/6model/reprs/CStr.h include/moar/6model/reprs/CStruct.h +include/moar/6model/reprs/CUnion.h include/moar/6model/reprs/ConcBlockingQueue.h include/moar/6model/reprs/ConditionVariable.h include/moar/6model/reprs/HashAttrStore.h @@ -136,6 +136,7 @@ include/moar/6model/reprs/MVMOSHandle.h include/moar/6model/reprs/MVMStaticFrame.h include/moar/6model/reprs/MVMString.h include/moar/6model/reprs/MVMThread.h +include/moar/6model/reprs/MultiDimArray.h include/moar/6model/reprs/NFA.h include/moar/6model/reprs/NativeCall.h include/moar/6model/reprs/NativeRef.h @@ -172,6 +173,8 @@ include/moar/core/intcache.h include/moar/core/interp.h include/moar/core/loadbytecode.h include/moar/core/nativecall.h +include/moar/core/nativecall_dyncall.h +include/moar/core/nativecall_libffi.h include/moar/core/oplabels.h include/moar/core/ops.h include/moar/core/threadcontext.h @@ -191,6 +194,8 @@ include/moar/gc/worklist.h inc
NEW: net/tinc
Hey @ports, after really long time in jasperla/openbsd-wip and intensive testing from an openbsd-wip-user, I'm happy to push a ready tinc port. I hope this nice stuff will find some Okays or feedback. Cheers, Rafael Virtual Private Network (VPN) daemon -- tinc-1.0.26 cat pkg/DESCR: tinc is a Virtual Private Network (VPN) daemon that uses tunnelling and encryption to create a secure private network between hosts on the Internet. Because the tunnel appears to the IP level network code as a normal network device, there is no need to adapt any existing software. This tunnelling allows VPN sites to share information with each other over the Internet without exposing any information to others. A single tinc daemon can accept more than one connection at a time, thus making it possible to create larger virtual networks, because some limitations are circumvented. Instead of most other VPN implementations, tinc encapsulates each network packet in its own UDP packet, instead of encapsulating all into one TCP or even PPP over TCP stream. This results in lower latencies, less overhead, and in general better responsiveness and throughput. tinc-1.0.26.tar.gz Description: application/tar-gz
Re: www/youtube-dl fetch fails due to ssl handshake failure
Hi Markus, I tried with older and newer versions and multiple youtube.com videos and it just works for me. I don't know why you're seeing that error. Paul
UPDATE: editors/calligra
Hey @ports, here is a very simple maintainer update to the last stable version. Tested over weeks @amd64. Okay? Cheers, Rafael Index: Makefile === RCS file: /cvs/ports/editors/calligra/Makefile,v retrieving revision 1.12 diff -u -p -u -p -r1.12 Makefile --- Makefile12 Sep 2015 17:37:03 - 1.12 +++ Makefile2 Nov 2015 19:51:13 - @@ -2,7 +2,7 @@ COMMENT = K Desktop Environment, office suite HOMEPAGE = https://www.calligra-suite.org/ -DISTNAME = calligra-2.9.7 +DISTNAME = calligra-2.9.8 CATEGORIES = editors DIST_SUBDIR = kde Index: distinfo === RCS file: /cvs/ports/editors/calligra/distinfo,v retrieving revision 1.6 diff -u -p -u -p -r1.6 distinfo --- distinfo12 Sep 2015 17:37:03 - 1.6 +++ distinfo2 Nov 2015 19:51:13 - @@ -1,2 +1,2 @@ -SHA256 (kde/calligra-2.9.7.tar.xz) = emQaFmlzn/VYCf1vLCLWc4Q6xB9k6C9cpss+YMfIJ4E= -SIZE (kde/calligra-2.9.7.tar.xz) = 194348264 +SHA256 (kde/calligra-2.9.8.tar.xz) = bM4UThK4BYykb+Z/BHvt+7bDdbjAd0Pw9+n+Kh+aRSE= +SIZE (kde/calligra-2.9.8.tar.xz) = 194666588
Re: Firefox 41.0.2 with W^X
David Coppa wrote: > On Fri, Oct 23, 2015 at 2:01 PM, Martin Pieuchot wrote: > > On 22/10/15(Thu) 21:40, Amit Kulkarni wrote: > >> On Thu, Oct 22, 2015 at 12:26 PM, David Coppa wrote: > >> > >> > On Thu, Oct 22, 2015 at 3:45 PM, Ed Ahlsen-Girard > >> > wrote: > >> > > I have noticed a performance hit since the switch was flipped. Firefox > >> > > stays at the top of top most of the time, and its CPU percentages have > >> > > spiked to 175% if multiple tabs were being opened. dmesg below the sig. > >> > > >> > Can you try if the attached patch is an improvement? > >> > > >> > >> Hi, > >> > >> This CPU spike is present with October 11 packages (Firefox 41.0.1) on > >> amd64, so it will be difficult to isolate the performance impact of the W > >> ^X vs the existing situation. > > > > FWIW I found that firefox is (ab)using pthread_mutex_trylock(3) a lot > > resulting in a storm of sched_yield(2) triggering a lot (dozen to > > hundreds of thousands) of IPIs on my x220. > > > > I tried to look at the source code but couldn't figure out where the > > call of pthread_mutex_trylock(3) are coming from. Firefox is just a > > monster. > > > > I'm sorry but I agree that if nobody is taking care of this regression > > it will be really hard to measure the impact of the W^X change. > > > > Martin, > > Has this problem manifested itself with firefox-41 or was it already > present with 40.x ? ktrace is pretty, uh, "enlightening"... This is a firefox process that's idle, and not even displayed on screen. Calling gettimeofday in a busy loop is probably not the most efficient means of implementing a timeout, or whatever it's up to. 26660 firefox 1446492775.550222 RET gettimeofday 0 26660 firefox 1446492775.550258 CALL gettimeofday(0x4210c4ef548,0) 26660 firefox 1446492775.550264 RET gettimeofday 0 26660 firefox 1446492775.550268 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550273 RET gettimeofday 0 26660 firefox 1446492775.550276 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550280 RET gettimeofday 0 26660 firefox 1446492775.550284 CALL gettimeofday(0x4210c4ef548,0) 26660 firefox 1446492775.550289 RET gettimeofday 0 26660 firefox 1446492775.550292 CALL gettimeofday(0x4210c4ef548,0) 26660 firefox 1446492775.550297 RET gettimeofday 0 26660 firefox 1446492775.550300 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550304 RET gettimeofday 0 26660 firefox 1446492775.550308 CALL gettimeofday(0x4210c4ef548,0) 26660 firefox 1446492775.550312 RET gettimeofday 0 26660 firefox 1446492775.550318 CALL gettimeofday(0x4210c4ef528,0) 26660 firefox 1446492775.550322 RET gettimeofday 0 26660 firefox 1446492775.550325 CALL gettimeofday(0x4210c4ef548,0) 26660 firefox 1446492775.550330 RET gettimeofday 0 26660 firefox 1446492775.550333 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550337 RET gettimeofday 0 26660 firefox 1446492775.550342 CALL gettimeofday(0x4210c4ef548,0) 26660 firefox 1446492775.550346 RET gettimeofday 0 26660 firefox 1446492775.550350 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550354 RET gettimeofday 0 26660 firefox 1446492775.550358 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550362 RET gettimeofday 0 26660 firefox 1446492775.550365 CALL gettimeofday(0x4210c4ef568,0) 26660 firefox 1446492775.550370 RET gettimeofday 0 26660 firefox 1446492775.550373 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550378 RET gettimeofday 0 26660 firefox 1446492775.550381 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550386 RET gettimeofday 0 26660 firefox 1446492775.550389 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550393 RET gettimeofday 0 26660 firefox 1446492775.550397 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550401 RET gettimeofday 0 26660 firefox 1446492775.550404 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550409 RET gettimeofday 0 26660 firefox 1446492775.550412 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550416 RET gettimeofday 0 26660 firefox 1446492775.550420 CALL gettimeofday(0x4210c4ef538,0) 26660 firefox 1446492775.550424 RET gettimeofday 0 26660 firefox 1446492775.550428 CALL gettimeofday(0x4210c4ef528,0) 26660 firefox 1446492775.550432 RET gettimeofday 0 26660 firefox 1446492775.550435 CALL gettimeofday(0x4210c4ef548,0) 26660 firefox 1446492775.550440 RET gettimeofday 0 26660 firefox 1446492775.550443 CALL gettimeofday(0x4210c4ef568,0) 26660 firefox 1446492775.550447 RET gettimeofday 0 26660 firefox 1446492775.550451 CALL gettimeofday(0x4210c4ef498,0) 26660 firefox 1446492775.550455 RET gettimeofday 0 26660 firefox 1446492775.550459 CALL gettimeofday(0x4210c4ef4a8,0) 26660 firefox 1446492775.550463 RET gettimeofday 0 26660 firefox 1446492775.550467 CALL getti
Re: www/youtube-dl fetch fails due to ssl handshake failure
Works for me. May need to update your snapshot. ===> Checking files for youtube-dl-2015.11.01 >> Fetch >> https://yt-dl.org/downloads/2015.11.01/youtube-dl-2015.11.01.tar.gz youtube-dl-2015.11.01 100%|***| 1737KB 00:03 On Mon, Nov 02, 2015 at 07:45:06PM +0100, Markus Lude wrote: > On Sat, Oct 24, 2015 at 09:05:27PM +0200, Markus Lude wrote: > > Hello Paul, > > Hello again, > > > make fetch fails for recent youtube-dl: > > > > ===> Checking files for youtube-dl-2015.10.24 > > >> Fetch https://yt-dl.org/downloads/2015.10.24/youtube-dl-2015.10.24.tar.gz > > ftp: SSL read error: read failed: error:140940E5:SSL > > routines:SSL3_READ_BYTES:ssl handshake failure > > recent update to youtube-dl-2015.11.01 fails too at the dowenload stage: > > ===> Checking files for youtube-dl-2015.11.01 > >> Fetch https://yt-dl.org/downloads/2015.11.01/youtube-dl-2015.11.01.tar.gz > ftp: SSL read error: read failed: error:140940E5:SSL > routines:SSL3_READ_BYTES:ssl handshake failure > > > quick workaround: use http instead? > > Regards, > Markus > -- James Turner
Re: www/youtube-dl fetch fails due to ssl handshake failure
On Sat, Oct 24, 2015 at 09:05:27PM +0200, Markus Lude wrote: > Hello Paul, Hello again, > make fetch fails for recent youtube-dl: > > ===> Checking files for youtube-dl-2015.10.24 > >> Fetch https://yt-dl.org/downloads/2015.10.24/youtube-dl-2015.10.24.tar.gz > ftp: SSL read error: read failed: error:140940E5:SSL > routines:SSL3_READ_BYTES:ssl handshake failure recent update to youtube-dl-2015.11.01 fails too at the dowenload stage: ===> Checking files for youtube-dl-2015.11.01 >> Fetch https://yt-dl.org/downloads/2015.11.01/youtube-dl-2015.11.01.tar.gz ftp: SSL read error: read failed: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure quick workaround: use http instead? Regards, Markus
[NEW] www/logswan
Hello ports@, Here is a new port attached : www/logswan Tested on amd64. >From DESCR : Logswan is a fast Web log analyzer using probabilistic data structures. It is targeted at very large log files, typically APIs logs. It has constant memory usage regardless of the log file size, and takes approximatively 4MB of RAM. Unique visitors counting is performed using two HyperLogLog counters (one for IPv4, and another one for IPv6), providing a relative accuracy of 0.10%. Cheers, Frederic logswan.tar.gz Description: application/tar-gz
Re: mail/claws-mail update
On Thu, 17 Sep 2015 20:29:08 +0200 Daniel Jakots wrote: > > Hi, > > Thanks for your report. > > I talked with people from upstream about the trace and they asked if you > could try a newer version of libetpan. > > jca@ kindly did the hard work for it so you can either take the patch > there https://marc.info/?l=openbsd-ports&m=144251205430518&w=2 and > build a new libetpan and then rebuild claws-mail or hope it goes in > and wait for new packages. > > According to the page https://github.com/dinhviethoa/libetpan/releases > it talks about new gmail features and according to `dig mx` you use > gmail so hopefully it solved your problem. > > Cheers, > Daniel > Hi Daniel, Thank you all for the follow up on this and taking port maintainership. After libetpan update, the crashes continued (very similar traces) and even the new version of claws-mail keeps crashing consistently. Did not want to lose track of progress on this thread, so replying here with a back trace and some details related. Reminder, the crashes happen with NNTP enabled when opening a mailing list, or when updating the list of messages from the news server (GMANE). This can cause the program to crash when replying or composing, as soon as in the background it gets into checking for new news messages. Also while running on its own, without any user interaction. I've not been able to find a specific method to trigger the crash on purpose (while reading mailing lists browsing messages replying etc), but the program can not be ran for more than a couple of minutes/hours at most as it certainly does crash. Please see if this can be brought upstream and followed up until to a solution. Can help further with back traces and suggesting you toggle debug symbols for claws-mail (libetpan?) for a couple of builds in the packages to help get to the actual cause of this reliability problem in claws-mail. Regards, Anton Lazarov OpenBSD GENERIC.MP#1554 amd64 running claws-mail-3.13.0 from packages $ claws-mail -V Claws Mail version 3.13.0 runtime GTK+ 2.24.28 / GLib 2.46.1 buildtime GTK+ 2.24.28 / GLib 2.46.1 Compiled-in features: Enchant GnuTLS IPv6 iconv libetpan 1.6 libSM $ /usr/bin/gdb /usr/local/bin/claws-mail ~/claws-mail.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd5.8"...(no debugging symbols found) Core was generated by `claws-mail'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libpthread.so.20.0...done. Loaded symbols for /usr/lib/libpthread.so.20.0 Loaded symbols for /usr/local/bin/claws-mail Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.2400.0...done. Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.2400.0 Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.2400.0...done. Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.2400.0 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.3800.0...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.3800.0 Reading symbols from /usr/local/lib/libpango-1.0.so.3800.0...done. Loaded symbols for /usr/local/lib/libpango-1.0.so.3800.0 Reading symbols from /usr/local/lib/libgobject-2.0.so.4200.2...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.4200.2 Reading symbols from /usr/local/lib/libglib-2.0.so.4200.2...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.4200.2 Reading symbols from /usr/local/lib/libiconv.so.6.0...done. Loaded symbols for /usr/local/lib/libiconv.so.6.0 Reading symbols from /usr/local/lib/libpcre.so.3.0...done. Loaded symbols for /usr/local/lib/libpcre.so.3.0 Reading symbols from /usr/local/lib/libintl.so.6.0...done. Loaded symbols for /usr/local/lib/libintl.so.6.0 Reading symbols from /usr/local/lib/libffi.so.1.2...done. Loaded symbols for /usr/local/lib/libffi.so.1.2 Reading symbols from /usr/local/lib/libgthread-2.0.so.4200.2...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.4200.2 Reading symbols from /usr/lib/libm.so.9.0...done. Loaded symbols for /usr/lib/libm.so.9.0 Reading symbols from /usr/local/lib/libcairo.so.12.3...done. Loaded symbols for /usr/local/lib/libcairo.so.12.3 Symbols already loaded for /usr/lib/libpthread.so.20.0 Reading symbols from /usr/X11R6/lib/libpixman-1.so.32.6...done. Loaded symbols for /usr/X11R6/lib/libpixman-1.so.32.6 Reading symbols from /usr/X11R6/lib/libpthread-stubs.so.2.0...done. Loaded symbols for /usr/X11R6/lib/libpthread-stubs.so.2.0 Reading symbols from /usr/X11R6/lib/libfontconfig.so.9.1...done. Loaded symbols for /usr/X11R6/lib/libfontconfig.so.9.1 Reading symbols from /usr/X11R6/lib/libfreetype.so.24.1...done. Loaded symbols for /usr/X11R6/lib/libfreetype.so.24.1 Reading symbols from /usr/lib/lib
Re: [update] lang/rust 1.4.0
On Sun, Nov 01, 2015 at 04:49:08PM -0500, Michael McConville wrote: Hello Michael, > It's hard to find a big stress-tester program to build without Cargo. Steven McDonald is working on a Cargo port, which is in openbsd-wip. It's more than good enough to compile every Rust program I've chucked at it. As I remember things, the WIP version isn't far off being good enough to consider for importing into ports. There are still a number of Rust libraries which have Linux-specific bits in, but a) the offending parts are nearly always easily fixed b) they're gradually reducing in number. So more and more things run out of the box on OpenBSD. Laurie -- Personal http://tratt.net/laurie/ Software Development Teamhttp://soft-dev.org/ https://github.com/ltratt http://twitter.com/laurencetratt
Re: Firefox 41.0.2 with W^X
On 02/11/15(Mon) 13:21, David Coppa wrote: > On Fri, Oct 23, 2015 at 2:01 PM, Martin Pieuchot wrote: > > On 22/10/15(Thu) 21:40, Amit Kulkarni wrote: > >> On Thu, Oct 22, 2015 at 12:26 PM, David Coppa wrote: > >> > >> > On Thu, Oct 22, 2015 at 3:45 PM, Ed Ahlsen-Girard > >> > wrote: > >> > > I have noticed a performance hit since the switch was flipped. Firefox > >> > > stays at the top of top most of the time, and its CPU percentages have > >> > > spiked to 175% if multiple tabs were being opened. dmesg below the sig. > >> > > >> > Can you try if the attached patch is an improvement? > >> > > >> > >> Hi, > >> > >> This CPU spike is present with October 11 packages (Firefox 41.0.1) on > >> amd64, so it will be difficult to isolate the performance impact of the W > >> ^X vs the existing situation. > > > > FWIW I found that firefox is (ab)using pthread_mutex_trylock(3) a lot > > resulting in a storm of sched_yield(2) triggering a lot (dozen to > > hundreds of thousands) of IPIs on my x220. > > > > I tried to look at the source code but couldn't figure out where the > > call of pthread_mutex_trylock(3) are coming from. Firefox is just a > > monster. > > > > I'm sorry but I agree that if nobody is taking care of this regression > > it will be really hard to measure the impact of the W^X change. > > > > Martin, > > Has this problem manifested itself with firefox-41 or was it already > present with 40.x ? I don't remember, I can try to figure out but I'd be happy if somebody else would do it 8)
Re: Firefox 41.0.2 with W^X
On Mon, Nov 2, 2015 at 6:21 AM, David Coppa wrote: > On Fri, Oct 23, 2015 at 2:01 PM, Martin Pieuchot wrote: > > On 22/10/15(Thu) 21:40, Amit Kulkarni wrote: > >> On Thu, Oct 22, 2015 at 12:26 PM, David Coppa wrote: > >> > >> > On Thu, Oct 22, 2015 at 3:45 PM, Ed Ahlsen-Girard > >> > wrote: > >> > > I have noticed a performance hit since the switch was flipped. > Firefox > >> > > stays at the top of top most of the time, and its CPU percentages > have > >> > > spiked to 175% if multiple tabs were being opened. dmesg below the > sig. > >> > > >> > Can you try if the attached patch is an improvement? > >> > > >> > >> Hi, > >> > >> This CPU spike is present with October 11 packages (Firefox 41.0.1) on > >> amd64, so it will be difficult to isolate the performance impact of the > W > >> ^X vs the existing situation. > > > > FWIW I found that firefox is (ab)using pthread_mutex_trylock(3) a lot > > resulting in a storm of sched_yield(2) triggering a lot (dozen to > > hundreds of thousands) of IPIs on my x220. > > > > I tried to look at the source code but couldn't figure out where the > > call of pthread_mutex_trylock(3) are coming from. Firefox is just a > > monster. > > > > I'm sorry but I agree that if nobody is taking care of this regression > > it will be really hard to measure the impact of the W^X change. > > > > Martin, > > Has this problem manifested itself with firefox-41 or was it already > present with 40.x ? > > ciao > David > > Hi David, Please see Erling Westenvik's email "wip: firefox 40" dated September 30, 2015. According to him it started in the 39-40 timeframe. It is getting so unbearable that I have switched to iridium (thanks robert@). Thanks
Re: SDL2 Fix
On 2015/11/01 23:49, Al Poole wrote: > > On Sat, Oct 31, 2015 at 07:34:13PM +, Stuart Henderson wrote: > > On 2015/10/31 14:38, Al Poole wrote: > > > Hello, > > > > > > There seems to be an issue with dlopen() in SDL2 on OpenBSD. > > > I found libXcursor.so was loading successfully via the same call multiple > > > times, then failing and producing SIGBUS error. > > > > > > The quick solution which allowed my own program to compile with sdl2 is > > > here: http://haxlab.org/patches/sdl2-2.0.2p4.tar.gz. > > > > > > I disabled the use of libXcursor... > > > > > > It contains the port files for sdl2. libXcursor.so seems to cause > > > problems. > > > Maybe this is useful. I hope so! > > > > > > Thanks for such a great OS! > > > > > > Alastair > > > > > > > There's a fix (rather than a workaround) for this issue on tech@, but it > > needs careful review. > > > > https://marc.info/?l=openbsd-tech&m=144576799413459&w=2 > > Hello again, > > The previous (workaround), disables using libXcursor. Tonight I had some time > to have a look at SDL2-2.0.4 (upstream), on an old machine running OpenBSD > 5.8. > > It seems there is an issue with ld.so. It's triggered by loading/unloading > symbols. SDL2 does this twice, firstly to test for the video device, then > it unloads, and it will load the symbols again for the X11 video for use. > The following patch will only load and unload once. > > This is another simple temporary workaround for some (using SDL2), while > the ld.so change is being reviewed/tested etc. > > As I prefer this solution, I'm sharing. > > Here is the URL: > > http://haxlab.org/patches/SDL-2.0.4-upstream-OpenBSD.5.8.patch > > > Bonne chance! > > Alastair > Ah that's much better, I think we could live with that until ld.so is fixed.. Let's update to a newer release while there. Any OKs? Index: Makefile === RCS file: /cvs/ports/devel/sdl2/Makefile,v retrieving revision 1.7 diff -u -p -r1.7 Makefile --- Makefile25 Aug 2015 13:18:25 - 1.7 +++ Makefile2 Nov 2015 12:41:45 - @@ -1,12 +1,9 @@ # $OpenBSD: Makefile,v 1.7 2015/08/25 13:18:25 sthen Exp $ -BROKEN=issue with ld.so - COMMENT= cross-platform multimedia library -V= 2.0.2 +V= 2.0.3 DISTNAME= SDL2-${V} -REVISION= 3 PKGNAME= sdl2-${V} CATEGORIES=devel MASTER_SITES= http://www.libsdl.org/release/ Index: distinfo === RCS file: /cvs/ports/devel/sdl2/distinfo,v retrieving revision 1.2 diff -u -p -r1.2 distinfo --- distinfo12 Mar 2014 03:56:32 - 1.2 +++ distinfo2 Nov 2015 12:41:45 - @@ -1,2 +1,2 @@ -SHA256 (SDL2-2.0.2.tar.gz) = WQFX+FqKi1JyOEgWmnTuxsoHq0p1zsFb7t3mSPmA6FA= -SIZE (SDL2-2.0.2.tar.gz) = 3812882 +SHA256 (SDL2-2.0.3.tar.gz) = pr+AvM5xP6hzYHc1/nEvRCdqfwSNYKYbsvazyQw= +SIZE (SDL2-2.0.3.tar.gz) = 3871267 Index: patches/patch-src_video_x11_SDL_x11video_c === RCS file: patches/patch-src_video_x11_SDL_x11video_c diff -N patches/patch-src_video_x11_SDL_x11video_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_video_x11_SDL_x11video_c 2 Nov 2015 12:41:45 - @@ -0,0 +1,29 @@ +$OpenBSD$ + +Avoid loading/unloading/reloading symbols, it crashes ld.so: +https://marc.info/?l=openbsd-tech&m=144576799413459&w=2 + +--- src/video/x11/SDL_x11video.c.orig Mon Nov 2 11:52:57 2015 src/video/x11/SDL_x11video.c Mon Nov 2 11:56:27 2015 +@@ -311,7 +311,9 @@ X11_Available(void) + if (display != NULL) { + X11_XCloseDisplay(display); + } ++#ifndef __OpenBSD__ + SDL_X11_UnloadSymbols(); ++#endif + } + return (display != NULL); + } +@@ -367,9 +369,11 @@ X11_CreateDevice(int devindex) + SDL_VideoData *data; + const char *display = NULL; /* Use the DISPLAY environment variable */ + ++#ifndef __OpenBSD__ + if (!SDL_X11_LoadSymbols()) { + return NULL; + } ++#endif + + /* Need for threading gl calls. This is also required for the proprietary + nVidia driver to be threaded. */
Re: Firefox 41.0.2 with W^X
On Fri, Oct 23, 2015 at 2:01 PM, Martin Pieuchot wrote: > On 22/10/15(Thu) 21:40, Amit Kulkarni wrote: >> On Thu, Oct 22, 2015 at 12:26 PM, David Coppa wrote: >> >> > On Thu, Oct 22, 2015 at 3:45 PM, Ed Ahlsen-Girard >> > wrote: >> > > I have noticed a performance hit since the switch was flipped. Firefox >> > > stays at the top of top most of the time, and its CPU percentages have >> > > spiked to 175% if multiple tabs were being opened. dmesg below the sig. >> > >> > Can you try if the attached patch is an improvement? >> > >> >> Hi, >> >> This CPU spike is present with October 11 packages (Firefox 41.0.1) on >> amd64, so it will be difficult to isolate the performance impact of the W >> ^X vs the existing situation. > > FWIW I found that firefox is (ab)using pthread_mutex_trylock(3) a lot > resulting in a storm of sched_yield(2) triggering a lot (dozen to > hundreds of thousands) of IPIs on my x220. > > I tried to look at the source code but couldn't figure out where the > call of pthread_mutex_trylock(3) are coming from. Firefox is just a > monster. > > I'm sorry but I agree that if nobody is taking care of this regression > it will be really hard to measure the impact of the W^X change. > Martin, Has this problem manifested itself with firefox-41 or was it already present with 40.x ? ciao David
Re: php-fpm 403 errors with httpd on amd64-current
On Sat, Oct 31, 2015 at 09:20:02PM +1100, Brett Mahar wrote: > On Fri, 30 Oct 2015 17:27:06 +1100 >> | I upgraded my mailserver >> yesterday to -current (last upgrade was around 11th Sept) and now my >> squirrelmail no longer works :-(. >> | >> | The problem is, going to my normal login screen nothing displays but >> "access denied". It is not a permissions issue as when I put an index.html >> file in the same directory httpd(8) displays it as normal. >> | >> >> Seems php throws a fit in it newest releases when there no fastcgi-params >> passed to it. > Can you retry httpd in -current please? > I reverted -r1.42 which was likely the culprit for your problems. Hi Joerg and Ports@, I've just tried httpd(8) with today's -current and it is working again, thank you!
Re: [update] lang/rust 1.4.0
On Sun, Nov 01, 2015 at 04:49:08PM -0500, Michael McConville wrote: > Sebastien Marie wrote: > > Hi, > > > > Here a patch for updating lang/rust to latest stable version: 1.4.0 > > > > Testing would be welcome. > > > > An intermittent failure on `net::addr::tests::to_socket_addr_str_bad' > > test is possible. It isn't a regress (this problem seems to be present > > long time ago), but I would like to investigate it a bit with people > > that are able to reproduce it (my buildhost don't trigger it). > > Built fine for me, after a couple laptop deaths from going >100°C. It's > hard to find a big stress-tester program to build without Cargo. Does > anyone have suggestions? > The port comes with a regress test (it is the official regress test of rustc), so just launch "make test" should be enough for run it. Thanks for testing. -- Sebastien Marie