CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/09 00:33:34 Modified files: textproc/link-grammar: Makefile Log message: Fix previous, RUN_DEPENDS-main should not be empty.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/09 02:05:02 Modified files: devel/ptlib: Makefile Log message: Don't pick up libv8; spotted by espie@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2014/05/09 02:47:48 Modified files: databases/mariadb: Makefile databases/mariadb/pkg: PLIST-main PLIST-server Log message: Only build the server (and tests) on archs that have atomic ops. ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/05/09 03:00:19 Modified files: audio/chromaprint: Makefile distinfo audio/chromaprint/pkg: DESCR PLIST Added files: audio/chromaprint/patches: patch-cmake_modules_FindGTest_cmake patch-tests_CMakeLists_txt Log message: Update to chromaprint 1.1, and build the fpcalc tool. From Nils R with a few tweaks by me.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/09 03:03:50 Modified files: security/gnutls: Makefile distinfo Log message: Bugfix update to gnutls-3.2.14.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/05/09 03:13:47 Modified files: www/squid/snapshot: Makefile Log message: Add a build dependency on cppunit. Not required for Squid itself, but tests are enabled if it's present at configure time, and junking it mid-build causes a failure. Found by espie@.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/09 03:16:10 Modified files: x11/gnome/tracker: Makefile distinfo x11/gnome/tracker/pkg: PLIST Log message: Update to meta-tracker-1.0.1.
Re: CVS: cvs.openbsd.org: ports
On Fri, May 09, 2014 at 03:13:47AM -0600, Stuart Henderson wrote: CVSROOT: /cvs Module name: ports Changes by: st...@cvs.openbsd.org 2014/05/09 03:13:47 Modified files: www/squid/snapshot: Makefile Log message: Add a build dependency on cppunit. Not required for Squid itself, but tests are enabled if it's present at configure time, and junking it mid-build causes a failure. Found by espie@. I'm not a big fan of adding dependencies just for tests... I'm sure the dependency of gstreamer-plugins on gtk+3 is what causes both webkit to be buildable at the same time, and since webkit takes so long to build, it currently consumes an extra hour on a bulk build on my cluster (webkit,gtk3 builds first, locks webkit, then webkit builds near the end of the build, and I wait an extra 10 mn for stuff that depends on it... if the plugins would not need gtk+3, then webkit, would be unlocked earlier, start building concurrently to gtk+3, and the build would finish synchronously... That said, cppunit is probably small enough that in this case, it doesn't matter.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/05/09 04:06:46 Modified files: www/squid/snapshot: Makefile Log message: add a comment about ac_cv_path_CPPUNITCONFIG=false which I may switch to instead of a build dep on cppunit when the devel version becomes stable.
Re: CVS: cvs.openbsd.org: ports
On 2014/05/09 11:44, Marc Espie wrote: On Fri, May 09, 2014 at 03:13:47AM -0600, Stuart Henderson wrote: CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/05/09 03:13:47 Modified files: www/squid/snapshot: Makefile Log message: Add a build dependency on cppunit. Not required for Squid itself, but tests are enabled if it's present at configure time, and junking it mid-build causes a failure. Found by espie@. I'm not a big fan of adding dependencies just for tests... I'm sure the dependency of gstreamer-plugins on gtk+3 is what causes both webkit to be buildable at the same time, and since webkit takes so long to build, it currently consumes an extra hour on a bulk build on my cluster (webkit,gtk3 builds first, locks webkit, then webkit builds near the end of the build, and I wait an extra 10 mn for stuff that depends on it... if the plugins would not need gtk+3, then webkit, would be unlocked earlier, start building concurrently to gtk+3, and the build would finish synchronously... That said, cppunit is probably small enough that in this case, it doesn't matter. In this case, since it's a development version of squid, and because cppunit is fairly small, I think it makes sense - I can use an autoconf cache to disable it when it's time to move that version to squid/stable.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/09 05:40:12 Modified files: databases/virtuoso/patches: patch-configure_in Log message: Tweak comment.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: flor...@cvs.openbsd.org 2014/05/09 05:40:45 Modified files: www/apache-httpd-openbsd: Makefile distinfo Removed files: www/apache-httpd-openbsd/patches: patch-src_modules_ssl_ssl_engine_rand_c Log message: No need for HAVE_SSL_RAND_EGD local patch, change pushed upstream (by just removing the code). While here switch naming scheme to MMDD, so no need for PKGNAME and REVISION. input/ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2014/05/09 06:55:41 Modified files: x11/spectrwm : Makefile distinfo Log message: Update for Spectrwm to 2.5.1: * Add clarification for the 'name' option to man page. * Add default maximize_toggle binding to man page. * Fix segfault in fullscreen layout when a window with transient(s) unmap. * Set stacking order when setting up a new status bar. * Improve stacking for windows with multiple transients. * Fix segfault when loading layout with non-zero parameters. OK benoit@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/09 06:59:50 Modified files: sysutils/accountsservice: Makefile sysutils/accountsservice/patches: patch-src_Makefile_in patch-src_util_c Log message: No need for libkvm.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/05/09 07:54:06 Modified files: security/gnutls: Makefile Log message: add an http mirror, for people on ftp-challenged nets ok ajacoutot@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/09 08:43:20 Modified files: x11/gnome/gvfs : Makefile distinfo Log message: Update to gvfs-1.20.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/09 09:28:58 Log message: Import git-bz-20130906. git-bz is a tool for integrating the Git command line with the Bugzilla bug-tracking system. Operations such as attaching patches to bugs, applying patches in bugs to your current tree, and closing bugs once you've pushed the fixes publicly can be done completely from the command line without having to go to your web browser. ok jasper@ Status: Vendor Tag: ajacoutot Release Tags: ajacoutot_20140509 N ports/devel/git-bz/Makefile N ports/devel/git-bz/distinfo N ports/devel/git-bz/patches/patch-git-bz N ports/devel/git-bz/pkg/DESCR N ports/devel/git-bz/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/09 09:29:23 Modified files: devel : Makefile Log message: +git-bz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/09 10:48:33 Modified files: audio/easytag : Makefile distinfo audio/easytag/pkg: PLIST Log message: Update to easytag-2.2.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2014/05/09 14:29:05 Removed files: databases/mariadb/patches: patch-sql_mysqld_cc Log message: Remove a patch to fix the build with TCP Wrappers no longer being used. ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: ki...@cvs.openbsd.org 2014/05/09 14:34:36
Modified files:
infrastructure/bin: portcheck
Log message:
compileall.py should be run with ${MODPY_BIN}
okay zhuk@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2014/05/09 15:33:44 Modified files: devel/eclipse/sdk: Makefile Log message: -swt needs a bump, too ok kurt@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2014/05/09 19:54:20 Log message: Import devel/p5-Test-Warnings-0.014 ok benoit@ Status: Vendor Tag: afresh1 Release Tags: afresh1_20140509 N ports/devel/p5-Test-Warnings/Makefile N ports/devel/p5-Test-Warnings/distinfo N ports/devel/p5-Test-Warnings/pkg/DESCR N ports/devel/p5-Test-Warnings/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2014/05/09 19:56:47 Modified files: devel : Makefile Log message: +p5-Test-Warnings ok benoit@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2014/05/09 19:57:49 Modified files: devel/p5-Clone : Makefile distinfo Log message: Update p5-Clone to 0.36 ok benoit@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2014/05/09 20:04:41 Modified files: devel/p5-Test-Exception: Makefile distinfo Log message: Update p5-Test-Exception to 0.32 and take maintainership ok benoit@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2014/05/09 21:02:08 Modified files: devel/p5-Sub-Install: Makefile distinfo Log message: Update p5-Sub-Install to 0.927 and take maintainership OK bluhm@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: afre...@cvs.openbsd.org 2014/05/09 21:06:31 Modified files: devel/p5-Sub-Exporter: Makefile distinfo Log message: Update p5-Sub-Exporter to 0.987 and take maintainer OK bluhm@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2014/05/09 23:50:56 Modified files: www/mozilla-firefox: Makefile distinfo www/mozilla-firefox/patches: patch-media_libvpx_Makefile_in www/firefox-i18n: Makefile.inc distinfo Log message: Bugfix update to firefox 29.0.1. - see http://www.mozilla.org/en-US/firefox/29.0.1/releasenotes/ - mostly fixes two annoying bugs with broken session restore (#1001167), pdf.js printing (#1003707), and disables seer for causing some slow shutdowns (#1005958).
Re: new: reop-1.0.0
James Turner writes:
New port of tedu's reop is attached. Tested on amd64.
${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
This line should not be necessary.
Since we are in control of upstream... Ted, can you upload a plain
.tar.gz to Github via the releases page? That way we can avoid the ugly
distfile hackery. If you feel like it, you can provide a reop signature
for it too :)
This is not exactly common practice on Github, but in my opinion it is
the right thing to do. And some people do practice it, e.g.,
https://github.com/mupen64plus/mupen64plus-core/releases ... notice how
in addition to the Github-provided .zip and .tar.gz there is a tarball
uploaded by the project maintainers. It's my understanding that Github
tarballs are still theoretically prone to checksum issues should they
update any of {git,gzip,tar} on their servers...
--
Anthony J. Bentley
Re: [UPDATE] chromaprint 1.1
09.05.2014 4:30 пользователь Stuart Henderson st...@openbsd.org написал:
On 2014/05/07 18:24, Nils R wrote:
Hi ports@,
this is an update of chromaprint to the latest version.
It builds on amd64, and the tests run fine with `make test`
(the command for running the tests in the current port
doesn't work).
I will try this out now with puddletag ;)
Any comments? Please test.
Nils
PS. I would have sent diffs, but i could not add the patch
directory to cvs, so i made a tarball.
Puddletag needs the fpcalc utility program that ships with
chromaprint. With this tarball, it gets build and installed
by default.
Now, tagging through AcousticID works in puddletag.
Nils
Just been looking at this; it seems wrong that gtest should become
a LIB_DEPENDS ... and building it and running port-lib-depends-check
it doesn't seem that installed files actually do link to it.
Since it's an update to an existing port I've tweaked it a bit to
reduce the diff, and also added a perl subst to replace /usr/local
with LOCALBASE in FindGTest.cmake. (I've done it this way rather
than using SUBST_CMD so that make update-patches gives less
trouble).
I don't know what abi-compliance-checker was saying, but this *is*
an ABI change (two additional functions; chromaprint_set_option and
Chromaprint::FingerprinterConfigurationTest4::FingerprinterConfigurationTest4
also Chromaprint::SilenceRemover::SilenceRemover takes an additional
parameter) so I've bumped shlib major.
I'm building clementine now. Assuming that goes OK, any comments/
objections/OKs to this version?
Instead of calling SUBST_CMD you could just add -D LOCALBASE=${LOCALBASE}
to CONFIGURE_ARGS. :)
Otherwise, if Clementine will work (my laptop almost gone crazy, so I'm out
of development for a few days), here is my okay, too.
Index: Makefile
===
RCS file: /cvs/ports/audio/chromaprint/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile10 Mar 2013 22:55:01 - 1.2
+++ Makefile9 May 2014 00:22:48 -
@@ -1,19 +1,20 @@
# $OpenBSD: Makefile,v 1.2 2013/03/10 22:55:01 espie Exp $
+
SHARED_ONLY = Yes
+
COMMENT = audio fingerprint extraction library
-CATEGORIES = audio devel
-HOMEPAGE = http://acoustid.org/chromaprint/
-DISTNAME = chromaprint-0.6
-MASTER_SITES = http://www.ohvost.ru/dnl/ \
- http://malcolm.ecentrum.hu/distfiles/
+DISTNAME = chromaprint-1.1
+CATEGORIES = audio devel
+HOMEPAGE = https://acoustid.org/chromaprint/
+MASTER_SITES =
https://bitbucket.org/acoustid/chromaprint/downloads/
-SHARED_LIBS = chromaprint 0.0 # 0.1
+SHARED_LIBS = chromaprint 1.0 # 0.1
# LGPL2.1+
PERMIT_PACKAGE_CDROM = Yes
-WANTLIB = avcodec avutil m stdc++
+WANTLIB += avcodec avformat avutil c m pthread stdc++ swresample
MODULES = devel/cmake
@@ -24,9 +25,13 @@ LIB_DEPENDS =graphics/ffmpeg
# gtest presence is checked in configure stage, so this cannot be in
TEST_DEPENDS
BUILD_DEPENDS += devel/gtest
-CONFIGURE_ARGS = -DBUILD_TESTS:Bool=Yes
+CONFIGURE_ARGS = -DBUILD_TESTS:Bool=Yes -DBUILD_EXAMPLES=ON
+
+post-patch:
+ perl -pi -e 's,/usr/local,${LOCALBASE},' \
+ ${WRKSRC}/cmake/modules/FindGTest.cmake
do-test:
- cd ${WRKBUILD}/tests ${MAKE_PROGRAM} check
+ cd ${WRKBUILD}/tests ./all_tests
.include bsd.port.mk
Index: distinfo
===
RCS file: /cvs/ports/audio/chromaprint/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo5 Feb 2013 11:09:11 - 1.1.1.1
+++ distinfo9 May 2014 00:22:48 -
@@ -1,2 +1,2 @@
-SHA256 (chromaprint-0.6.tar.gz) =
XZuC2iJkUMFOQ0gjcaGyoXjiYEq1suklnzOxtGHunWM=
-SIZE (chromaprint-0.6.tar.gz) = 542366
+SHA256 (chromaprint-1.1.tar.gz) =
axTX6klkWBtzvT+AOMiFfAHkRkIcGumcu/ZN4mtHzRI=
+SIZE (chromaprint-1.1.tar.gz) = 542360
Index: patches/patch-cmake_modules_FindGTest_cmake
===
RCS file: patches/patch-cmake_modules_FindGTest_cmake
diff -N patches/patch-cmake_modules_FindGTest_cmake
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-cmake_modules_FindGTest_cmake 9 May 2014 00:22:48 -
@@ -0,0 +1,31 @@
+$OpenBSD$
+--- cmake/modules/FindGTest.cmake.orig Sat Nov 23 16:43:42 2013
cmake/modules/FindGTest.cmake Wed May 7 16:29:15 2014
+@@ -71,12 +71,24 @@ find_path(GTEST_INCLUDE_DIR
+ )
+ mark_as_advanced(GTEST_INCLUDE_DIR)
+
++MACRO(GTEST_FIND varname shortname)
++
++FIND_LIBRARY(${varname}
++NAMES ${shortname}
++PATHS
++/usr/local/lib
++
Re: POSIX standard as manual pages
09.05.2014 2:03 пользователь Dmitrij D. Czarkoff czark...@gmail.com
написал:
Ingo Schwarze said:
Looking again, i think it is better to shorten this to
share/doc/man-pages-posix/man{1,3}/*.{1,3}
Why not shorten man-pages-posix to just posix?
It's upstream name, FWIW. I won't mind to change actual folder if there
will be a real reason. You won't go to this folder directly anyway, will
you?
Re: new: reop-1.0.0
On Fri, May 09, 2014 at 00:53, Anthony J. Bentley wrote: Since we are in control of upstream... Ted, can you upload a plain .tar.gz to Github via the releases page? That way we can avoid the ugly distfile hackery. If you feel like it, you can provide a reop signature for it too :) That was weird. Figured it out. Now there's a green button on the web site too.
Re: POSIX standard as manual pages
Hi Dmitrij and Vadim,
Vadim Zhukov wrote on Fri, May 09, 2014 at 11:57:28AM +0400:
09.05.2014 2:03 Dmitrij D. Czarkoff czark...@gmail.com:
Why not shorten man-pages-posix to just posix?
That's what i originally suggested, too:
From: Ingo Schwarze schwa...@usta.de
Date: Fri, 24 Jan 2014 00:45:56 +0100
To: Vadim Zhukov persg...@gmail.com
Cc: ports@openbsd.org
Subject: Re: POSIX standard as manual pages
[...]
Do not install these manuals to /usr/local/man/,
but to a dedicated directory, something like
/usr/local/share/doc/posix/man/man{1,3}/*.{1,3}
One advantage is that if any other POSIX documentation should ever
show up in ports, it could go into share/doc/posix, too.
There is no danger of clashes, posix/man is quite clear,
man-pages-posix/man somewhat redundant.
It's upstream name, FWIW.
The argument that a port should follow upstream's name (unless it is
very badly chosen) and that most subdirectories of /usr/local/share/doc/
follow the respective ports' names is a valid one.
I won't mind to change actual folder if there will be a real reason.
You won't go to this folder directly anyway, will you?
I already have your port installed because it is useful for me
when doing work regarding POSIX conformance and when doing work
regarding HISTORY sections. I already cd'ed into that directory
several times, mostly to do multiple consecutive grep -R commands.
Given that all this is still man(7), not mdoc(7), the new apropos
is not yet very helpful, so searching still needs to be done the
old way.
Then again, i don't feel strongly either way, both paths seem
acceptable to me. It's your port, and you are more used to ports
naming conventions, so you should decide this detail, i think.
Yours,
Ingo
Re: new: reop-1.0.0
On Fri, May 09, 2014 at 12:53:14AM -0600, Anthony J. Bentley wrote:
James Turner writes:
New port of tedu's reop is attached. Tested on amd64.
${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
This line should not be necessary.
Since we are in control of upstream... Ted, can you upload a plain
.tar.gz to Github via the releases page? That way we can avoid the ugly
distfile hackery. If you feel like it, you can provide a reop signature
for it too :)
Updated port attached with Anthony's suggestions and using the newly
rolled .tgz. ok?
--
James Turner
reop-1.0.0.tar.gz
Description: application/tar-gz
Re: POSIX standard as manual pages
09.05.2014 17:17 пользователь Ingo Schwarze schwa...@usta.de написал:
Hi Dmitrij and Vadim,
Vadim Zhukov wrote on Fri, May 09, 2014 at 11:57:28AM +0400:
09.05.2014 2:03 Dmitrij D. Czarkoff czark...@gmail.com:
Why not shorten man-pages-posix to just posix?
That's what i originally suggested, too:
From: Ingo Schwarze schwa...@usta.de
Date: Fri, 24 Jan 2014 00:45:56 +0100
To: Vadim Zhukov persg...@gmail.com
Cc: ports@openbsd.org
Subject: Re: POSIX standard as manual pages
[...]
Do not install these manuals to /usr/local/man/,
but to a dedicated directory, something like
/usr/local/share/doc/posix/man/man{1,3}/*.{1,3}
One advantage is that if any other POSIX documentation should ever
show up in ports, it could go into share/doc/posix, too.
There is no danger of clashes, posix/man is quite clear,
man-pages-posix/man somewhat redundant.
It's upstream name, FWIW.
The argument that a port should follow upstream's name (unless it is
very badly chosen) and that most subdirectories of /usr/local/share/doc/
follow the respective ports' names is a valid one.
I won't mind to change actual folder if there will be a real reason.
You won't go to this folder directly anyway, will you?
I already have your port installed because it is useful for me
when doing work regarding POSIX conformance and when doing work
regarding HISTORY sections. I already cd'ed into that directory
several times, mostly to do multiple consecutive grep -R commands.
Given that all this is still man(7), not mdoc(7), the new apropos
is not yet very helpful, so searching still needs to be done the
old way.
This is a good point, thank you for input. The packages are for people, not
the other direction. So if people use this directory, err, directly, then
it's better to have an exception. I'll rename the folder when I'll get my
laptop back to normal operation.
Then again, i don't feel strongly either way, both paths seem
acceptable to me. It's your port, and you are more used to ports
naming conventions, so you should decide this detail, i think.
Yours,
Ingo
lang/ruby/2.* updates
This updates lang/ruby/2.0 and lang/ruby/2.1 to the latest version:
https://www.ruby-lang.org/en/news/2014/05/09/ruby-2-0-0-p481-is-released/
https://www.ruby-lang.org/en/news/2014/05/09/ruby-2-1-2-is-released/
This is mostly bugfixes, including a fairly important fix for a
regression in Hash#reject that occurred in ruby 2.1.1.
Tested on amd64 and i386. Will probably commit this weekend unless I
hear objections.
Thanks,
Jeremy
Index: lang/ruby/2.0/Makefile
===
RCS file: /cvs/ports/lang/ruby/2.0/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- lang/ruby/2.0/Makefile 11 Mar 2014 20:08:45 - 1.11
+++ lang/ruby/2.0/Makefile 9 May 2014 14:10:31 -
@@ -9,7 +9,7 @@ COMMENT-tk =tk interface for ruby
COMMENT-ri_docs = ri documentation files for ruby
VERSION = 2.0.0
-PATCHLEVEL = 451
+PATCHLEVEL = 481
RUBYLIBREV = 2.0
DISTNAME = ruby-${VERSION}-p${PATCHLEVEL}
Index: lang/ruby/2.0/distinfo
===
RCS file: /cvs/ports/lang/ruby/2.0/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- lang/ruby/2.0/distinfo 11 Mar 2014 20:08:45 - 1.5
+++ lang/ruby/2.0/distinfo 9 May 2014 14:11:21 -
@@ -1,2 +1,2 @@
-SHA256 (ruby-2.0.0-p451.tar.gz) = 5taQDrQIQFMFg0nP2/Y60UFLao111YtH7YEBCplH5zs=
-SIZE (ruby-2.0.0-p451.tar.gz) = 13587580
+SHA256 (ruby-2.0.0-p481.tar.gz) = AN09ckNet38r2UU3wXOOUhnKQrbWjfPU8gwYP0vRLQ8=
+SIZE (ruby-2.0.0-p481.tar.gz) = 13586757
Index: lang/ruby/2.1/Makefile
===
RCS file: /cvs/ports/lang/ruby/2.1/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- lang/ruby/2.1/Makefile 18 Mar 2014 07:25:53 - 1.6
+++ lang/ruby/2.1/Makefile 9 May 2014 14:11:04 -
@@ -9,7 +9,7 @@ COMMENT-gdbm = gdbm interface for ruby
COMMENT-tk = tk interface for ruby
COMMENT-ri_docs = ri documentation files for ruby
-VERSION = 2.1.1
+VERSION = 2.1.2
RUBYLIBREV = 2.1
DISTNAME = ruby-${VERSION}
Index: lang/ruby/2.1/distinfo
===
RCS file: /cvs/ports/lang/ruby/2.1/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- lang/ruby/2.1/distinfo 11 Mar 2014 20:10:40 - 1.2
+++ lang/ruby/2.1/distinfo 9 May 2014 14:11:18 -
@@ -1,2 +1,2 @@
-SHA256 (ruby-2.1.1.tar.gz) = yEPfMa6I7Un1OTFCsCuan1plV0U4Bf1Imnb7r+roiUE=
-SIZE (ruby-2.1.1.tar.gz) = 15092388
+SHA256 (ruby-2.1.2.tar.gz) = 8ipkR4EagfPICNHCpc47X18JVcaMmnSRgv60JVieZjU=
+SIZE (ruby-2.1.2.tar.gz) = 15096114
Index: lang/ruby/2.1/pkg/PLIST-main
===
RCS file: /cvs/ports/lang/ruby/2.1/pkg/PLIST-main,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST-main
--- lang/ruby/2.1/pkg/PLIST-main11 Mar 2014 20:10:40 - 1.2
+++ lang/ruby/2.1/pkg/PLIST-main9 May 2014 14:40:59 -
@@ -1039,19 +1039,19 @@ lib/ruby/gems/${RUBYLIBREV}/gems/rdoc-4.
lib/ruby/gems/${RUBYLIBREV}/gems/rdoc-4.1.0/bin/
lib/ruby/gems/${RUBYLIBREV}/gems/rdoc-4.1.0/bin/rdoc
lib/ruby/gems/${RUBYLIBREV}/gems/rdoc-4.1.0/bin/ri
-lib/ruby/gems/${RUBYLIBREV}/gems/test-unit-${RUBYLIBREV}.1.0/
-lib/ruby/gems/${RUBYLIBREV}/gems/test-unit-${RUBYLIBREV}.1.0/bin/
-lib/ruby/gems/${RUBYLIBREV}/gems/test-unit-${RUBYLIBREV}.1.0/bin/testrb
+lib/ruby/gems/${RUBYLIBREV}/gems/test-unit-${RUBYLIBREV}.2.0/
+lib/ruby/gems/${RUBYLIBREV}/gems/test-unit-${RUBYLIBREV}.2.0/bin/
+lib/ruby/gems/${RUBYLIBREV}/gems/test-unit-${RUBYLIBREV}.2.0/bin/testrb
lib/ruby/gems/${RUBYLIBREV}/specifications/
lib/ruby/gems/${RUBYLIBREV}/specifications/default/
lib/ruby/gems/${RUBYLIBREV}/specifications/default/bigdecimal-1.2.4.gemspec
lib/ruby/gems/${RUBYLIBREV}/specifications/default/io-console-0.4.2.gemspec
lib/ruby/gems/${RUBYLIBREV}/specifications/default/json-1.8.1.gemspec
lib/ruby/gems/${RUBYLIBREV}/specifications/default/minitest-4.7.5.gemspec
-lib/ruby/gems/${RUBYLIBREV}/specifications/default/psych-2.0.3.gemspec
+lib/ruby/gems/${RUBYLIBREV}/specifications/default/psych-2.0.5.gemspec
lib/ruby/gems/${RUBYLIBREV}/specifications/default/rake-10.1.0.gemspec
lib/ruby/gems/${RUBYLIBREV}/specifications/default/rdoc-4.1.0.gemspec
-lib/ruby/gems/${RUBYLIBREV}/specifications/default/test-unit-${RUBYLIBREV}.1.0.gemspec
+lib/ruby/gems/${RUBYLIBREV}/specifications/default/test-unit-${RUBYLIBREV}.2.0.gemspec
lib/ruby/site_ruby/
lib/ruby/site_ruby/${RUBYLIBREV}/
lib/ruby/site_ruby/${RUBYLIBREV}/${SUB}/
Index: lang/ruby/2.1/pkg/PLIST-ri_docs
===
RCS file: /cvs/ports/lang/ruby/2.1/pkg/PLIST-ri_docs,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST-ri_docs
--- lang/ruby/2.1/pkg/PLIST-ri_docs
Re: POSIX standard as manual pages
Just curious, are the older POSIX standards available as man pages
too? Is there a way to install them side-by-side?
I'm by far most interested in the current up-to-date standard, but
being able to easily cross-reference older revisions is sometimes
handy. (E.g., when trying to make sure we're still compliant with
older standards.)
On Fri, May 9, 2014 at 8:18 AM, Vadim Zhukov persg...@gmail.com wrote:
09.05.2014 17:17 пользователь Ingo Schwarze schwa...@usta.de написал:
Hi Dmitrij and Vadim,
Vadim Zhukov wrote on Fri, May 09, 2014 at 11:57:28AM +0400:
09.05.2014 2:03 Dmitrij D. Czarkoff czark...@gmail.com:
Why not shorten man-pages-posix to just posix?
That's what i originally suggested, too:
From: Ingo Schwarze schwa...@usta.de
Date: Fri, 24 Jan 2014 00:45:56 +0100
To: Vadim Zhukov persg...@gmail.com
Cc: ports@openbsd.org
Subject: Re: POSIX standard as manual pages
[...]
Do not install these manuals to /usr/local/man/,
but to a dedicated directory, something like
/usr/local/share/doc/posix/man/man{1,3}/*.{1,3}
One advantage is that if any other POSIX documentation should ever
show up in ports, it could go into share/doc/posix, too.
There is no danger of clashes, posix/man is quite clear,
man-pages-posix/man somewhat redundant.
It's upstream name, FWIW.
The argument that a port should follow upstream's name (unless it is
very badly chosen) and that most subdirectories of /usr/local/share/doc/
follow the respective ports' names is a valid one.
I won't mind to change actual folder if there will be a real reason.
You won't go to this folder directly anyway, will you?
I already have your port installed because it is useful for me
when doing work regarding POSIX conformance and when doing work
regarding HISTORY sections. I already cd'ed into that directory
several times, mostly to do multiple consecutive grep -R commands.
Given that all this is still man(7), not mdoc(7), the new apropos
is not yet very helpful, so searching still needs to be done the
old way.
This is a good point, thank you for input. The packages are for people, not
the other direction. So if people use this directory, err, directly, then
it's better to have an exception. I'll rename the folder when I'll get my
laptop back to normal operation.
Then again, i don't feel strongly either way, both paths seem
acceptable to me. It's your port, and you are more used to ports
naming conventions, so you should decide this detail, i think.
Yours,
Ingo
Re: POSIX standard as manual pages
09.05.2014 21:18 пользователь Matthew Dempsky matt...@dempsky.org
написал:
Just curious, are the older POSIX standards available as man pages
too? Is there a way to install them side-by-side?
I'm by far most interested in the current up-to-date standard, but
being able to easily cross-reference older revisions is sometimes
handy. (E.g., when trying to make sure we're still compliant with
older standards.)
There is one more release from the same project, from 2003 year, IIRC. I do
not know about any other successful POSIX-as-a-man projects; feel free to
point me at those, and I'll prepare ports for them, too.
On Fri, May 9, 2014 at 8:18 AM, Vadim Zhukov persg...@gmail.com wrote:
09.05.2014 17:17 пользователь Ingo Schwarze schwa...@usta.de
написал:
Hi Dmitrij and Vadim,
Vadim Zhukov wrote on Fri, May 09, 2014 at 11:57:28AM +0400:
09.05.2014 2:03 Dmitrij D. Czarkoff czark...@gmail.com:
Why not shorten man-pages-posix to just posix?
That's what i originally suggested, too:
From: Ingo Schwarze schwa...@usta.de
Date: Fri, 24 Jan 2014 00:45:56 +0100
To: Vadim Zhukov persg...@gmail.com
Cc: ports@openbsd.org
Subject: Re: POSIX standard as manual pages
[...]
Do not install these manuals to /usr/local/man/,
but to a dedicated directory, something like
/usr/local/share/doc/posix/man/man{1,3}/*.{1,3}
One advantage is that if any other POSIX documentation should ever
show up in ports, it could go into share/doc/posix, too.
There is no danger of clashes, posix/man is quite clear,
man-pages-posix/man somewhat redundant.
It's upstream name, FWIW.
The argument that a port should follow upstream's name (unless it is
very badly chosen) and that most subdirectories of
/usr/local/share/doc/
follow the respective ports' names is a valid one.
I won't mind to change actual folder if there will be a real reason.
You won't go to this folder directly anyway, will you?
I already have your port installed because it is useful for me
when doing work regarding POSIX conformance and when doing work
regarding HISTORY sections. I already cd'ed into that directory
several times, mostly to do multiple consecutive grep -R commands.
Given that all this is still man(7), not mdoc(7), the new apropos
is not yet very helpful, so searching still needs to be done the
old way.
This is a good point, thank you for input. The packages are for people,
not
the other direction. So if people use this directory, err, directly,
then
it's better to have an exception. I'll rename the folder when I'll get
my
laptop back to normal operation.
Then again, i don't feel strongly either way, both paths seem
acceptable to me. It's your port, and you are more used to ports
naming conventions, so you should decide this detail, i think.
Yours,
Ingo
Re: UPDATE: Haproxy-1.4.25
Anyone? :) On Tue, Apr 29, 2014 at 11:54:45AM -0300, Gonzalo L. R. wrote: ; Hi, ; ; Update for HAproxy to 1.4.25: ; ; http://haproxy.1wt.eu/download/1.4/src/CHANGELOG ; ; Ok? Comments? ; ; Cheers.- ; ; -- ; Sending from my toaster. ; Index: Makefile ; === ; RCS file: /cvs/ports/net/haproxy/Makefile,v ; retrieving revision 1.13 ; diff -u -p -r1.13 Makefile ; --- Makefile 13 Mar 2014 08:58:14 - 1.13 ; +++ Makefile 29 Apr 2014 14:54:29 - ; @@ -2,8 +2,7 @@ ; ; COMMENT =reliable, high performance TCP/HTTP load balancer ; ; -DISTNAME = haproxy-1.4.24 ; -REVISION = 0 ; +DISTNAME = haproxy-1.4.25 ; CATEGORIES = net www ; HOMEPAGE = http://haproxy.1wt.eu/ ; ; Index: distinfo ; === ; RCS file: /cvs/ports/net/haproxy/distinfo,v ; retrieving revision 1.6 ; diff -u -p -r1.6 distinfo ; --- distinfo 17 Jul 2013 02:52:53 - 1.6 ; +++ distinfo 29 Apr 2014 14:54:29 - ; @@ -1,2 +1,2 @@ ; -SHA256 (haproxy-1.4.24.tar.gz) = aAko9NABvjtZtp1FAfQa7qaefla/GD+gMq1hRM+Xx+8= ; -SIZE (haproxy-1.4.24.tar.gz) = 836768 ; +SHA256 (haproxy-1.4.25.tar.gz) = hECOweN78wjGtFrjx+ZvKp0vdiy2iattMixnu6aR22I= ; +SIZE (haproxy-1.4.25.tar.gz) = 838775 -- Sending from my toaster.
Re: new: reop-1.0.0
On 2014/05/09 09:55, James Turner wrote:
On Fri, May 09, 2014 at 12:53:14AM -0600, Anthony J. Bentley wrote:
James Turner writes:
New port of tedu's reop is attached. Tested on amd64.
${INSTALL_PROGRAM_DIR} ${PREFIX}/bin
This line should not be necessary.
Since we are in control of upstream... Ted, can you upload a plain
.tar.gz to Github via the releases page? That way we can avoid the ugly
distfile hackery. If you feel like it, you can provide a reop signature
for it too :)
Updated port attached with Anthony's suggestions and using the newly
rolled .tgz. ok?
--
James Turner
Works on amd64, but macppc fails tests:
=== Regression tests for reop-1.0.0
reop: decryption failed
Re: mips64[el] for gcc 4.8 (unfinished)
On Fri, 09 May 2014 01:22:45 -0400, Brian Callahan wrote: On 05/08/14 19:39, Tobias Ulmer wrote: I've invested some time into adding the mips64(el) backend. It gets quite far (xgcc seems to be fine), but then our ld takes a dump: /usr/bin/ld: not enough GOT space for local GOT entries /usr/bin/ld: BFD 2.15 internal error, aborting at /usr/src/gnu/usr.bin/binutils /bfd/elfxx-mips.c line 6483 in _bfd_mips_elf_relocate_section /usr/bin/ld: Please report this bug. Log: http://www.tmux.org/~tobiasu/tmp/gcc48-mips64-build.txt Others have run into this, and it's possibly fixed in newer binutils, but I have not been able to make sense of the BFD guts enough to fix ld. Question is, should I commit this in its current form so others can try their luck? I'm pretty sure this patch is 95% there. Yes, please. Seconded. It's a known bug that's fixed in 2.17, iirc.
Re: Problems using SSL libraries
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: Stuart Henderson st...@openbsd.org writes: On 2014/05/06 19:41, viq wrote: Thanks. You think this patch would show same behaviour on the updated version? If so I could try spend some time with that, see whether that helps. I can't remember if I tried that or not, but I think it will be the same .. Given that OpenSSL seems to favour backwards compatibility cruft over clean code, there isn't much incentive for downstream users to replace old APIs with newer slightly-less-bad ones. But do the latter exist? 8) So, as it stands, this knocks out py-boto / duplicity / saltstack. As I said to viq privately, I intend to try to fix it very soon (or propose that we reinstall the defines in safestack.h). Unless someone already has a fix now... :) I quit, I'm not sic^Wsmart enough. :) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: mips64[el] for gcc 4.8 (unfinished)
On 05/09/14 14:41, Pascal Stumpf wrote: On Fri, 09 May 2014 01:22:45 -0400, Brian Callahan wrote: On 05/08/14 19:39, Tobias Ulmer wrote: I've invested some time into adding the mips64(el) backend. It gets quite far (xgcc seems to be fine), but then our ld takes a dump: /usr/bin/ld: not enough GOT space for local GOT entries /usr/bin/ld: BFD 2.15 internal error, aborting at /usr/src/gnu/usr.bin/binutils /bfd/elfxx-mips.c line 6483 in _bfd_mips_elf_relocate_section /usr/bin/ld: Please report this bug. Log: http://www.tmux.org/~tobiasu/tmp/gcc48-mips64-build.txt Others have run into this, and it's possibly fixed in newer binutils, but I have not been able to make sense of the BFD guts enough to fix ld. Question is, should I commit this in its current form so others can try their luck? I'm pretty sure this patch is 95% there. Yes, please. Seconded. It's a known bug that's fixed in 2.17, iirc. Yup. I can confirm that.
Re: [new] mpv 0.3.9, sndio still an issue
On Sat, May 03, 2014 at 06:15:31PM +0200, frantisek holop wrote: here is the latest release of mpv. to remind all willing developers about the sndio issue: https://github.com/mpv-player/mpv/issues/531 to make possible debugging even quicker, the mp3 file in question that always triggers this issue is available from (remove spaces): obiit . org/f/ 03-believe.notmp3 I made some changes to your port and fixed a little bug. I have two questions: - Where are you seeing the error 'undefined reference to __sync_fetch_and_add_8'? - Why the assembler code is disabled? -- Juan Francisco Cantero Hurtado http://juanfra.info mpv.tar.gz Description: application/tar-gz
Re: APE Server
On 2014/05/07 13:05, Henning Brauer wrote: hey, it doesn't look like we have a port for APE Server, ape-project.org, unless I am blind. That right? If so, is somebody more experienced in ports willing to make one? That might save time over having to deal with my naive porting attempts afterwards ;) http://ape-project.org/download/stable/APE_Server-1.1.2.tar.gz It works on FreeBSD, should be straightforward. Thanks! Henning It's not particularly simple; apart from the messy build script (which we can replace in the port Makefile), they use an embedded copy of spidermonkey 1.8.5 which isn't going to build without patching and we can't just use a newer version of spidermonkey from ports to replace it as it's not api-compatible, so will probably need to steal patches from an old version of spidermonkey from the Attic. Some pieces in the attached tgz, but I suspect it's going to need a whole bunch more.. ape_server.tgz Description: application/tar-gz
Re: new: reop-1.0.0
On Fri, May 09, 2014 at 19:49, Stuart Henderson wrote: Works on amd64, but macppc fails tests: === Regression tests for reop-1.0.0 reop: decryption failed I'll one up that. It segfaults on sparc64. :(
Re: Problems using SSL libraries
On Fri, May 9, 2014 at 9:16 PM, Jérémie Courrèges-Anglas j...@wxcvbn.org wrote: j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: Stuart Henderson st...@openbsd.org writes: So, as it stands, this knocks out py-boto / duplicity / saltstack. As I said to viq privately, I intend to try to fix it very soon (or propose that we reinstall the defines in safestack.h). Unless someone already has a fix now... :) I quit, I'm not sic^Wsmart enough. :) Say it ain't so! ;) I do hope someone can figure this out... -- viq
Re: new: reop-1.0.0
On Fri, May 09, 2014 at 18:09, Ted Unangst wrote: On Fri, May 09, 2014 at 19:49, Stuart Henderson wrote: Works on amd64, but macppc fails tests: === Regression tests for reop-1.0.0 reop: decryption failed I'll one up that. It segfaults on sparc64. :( This will fix it, at the cost of making startup slow as balls. The one second test.sh now takes over 15 seconds to run. The libsodium documentation says this isn't required. Obviously, it's a crypto library, therefore it lies. diff -r b7b0f515429c reop.c --- a/reop.cSat Apr 19 11:32:25 2014 -0400 +++ b/reop.cFri May 09 18:17:07 2014 -0400 @@ -1054,6 +1054,7 @@ VERIFY } verb = NONE; + sodium_init(); rounds = 42;
Re: new: reop-1.0.0
On Fri, May 09, 2014 at 06:21:04PM -0400, Ted Unangst wrote: On Fri, May 09, 2014 at 18:09, Ted Unangst wrote: On Fri, May 09, 2014 at 19:49, Stuart Henderson wrote: Works on amd64, but macppc fails tests: === Regression tests for reop-1.0.0 reop: decryption failed I'll one up that. It segfaults on sparc64. :( This will fix it, at the cost of making startup slow as balls. The one second test.sh now takes over 15 seconds to run. The libsodium documentation says this isn't required. Obviously, it's a crypto library, therefore it lies. diff -r b7b0f515429c reop.c --- a/reop.cSat Apr 19 11:32:25 2014 -0400 +++ b/reop.cFri May 09 18:17:07 2014 -0400 @@ -1054,6 +1054,7 @@ VERIFY } verb = NONE; + sodium_init(); rounds = 42; Even with this I'm getting a Bus error (core dumped) on loongson. Sounds like we may need to wait for a more up to date libsodium? -- James Turner
Re: new: reop-1.0.0
On Fri, May 09, 2014 at 10:28:18PM -0400, James Turner wrote: On Fri, May 09, 2014 at 06:21:04PM -0400, Ted Unangst wrote: On Fri, May 09, 2014 at 18:09, Ted Unangst wrote: On Fri, May 09, 2014 at 19:49, Stuart Henderson wrote: Works on amd64, but macppc fails tests: === Regression tests for reop-1.0.0 reop: decryption failed I'll one up that. It segfaults on sparc64. :( This will fix it, at the cost of making startup slow as balls. The one second test.sh now takes over 15 seconds to run. The libsodium documentation says this isn't required. Obviously, it's a crypto library, therefore it lies. diff -r b7b0f515429c reop.c --- a/reop.cSat Apr 19 11:32:25 2014 -0400 +++ b/reop.cFri May 09 18:17:07 2014 -0400 @@ -1054,6 +1054,7 @@ VERIFY } verb = NONE; + sodium_init(); rounds = 42; Even with this I'm getting a Bus error (core dumped) on loongson. Sounds like we may need to wait for a more up to date libsodium? It looks like the git version of libsodium fixes my loongson issues. All tests pass now. I also did not need to add sodium_init(). It sounds like libsodium 0.5.0 might be released over the next couple of days so why don't we hold off on reop until then and circle back around once a new version of libsodium is out. -- James Turner
Re: mips64[el] for gcc 4.8 (unfinished)
On Fri, May 09, 2014 at 03:39:50PM -0400, Brian Callahan wrote: On 05/09/14 14:41, Pascal Stumpf wrote: On Fri, 09 May 2014 01:22:45 -0400, Brian Callahan wrote: On 05/08/14 19:39, Tobias Ulmer wrote: I've invested some time into adding the mips64(el) backend. It gets quite far (xgcc seems to be fine), but then our ld takes a dump: /usr/bin/ld: not enough GOT space for local GOT entries /usr/bin/ld: BFD 2.15 internal error, aborting at /usr/src/gnu/usr.bin/binutils /bfd/elfxx-mips.c line 6483 in _bfd_mips_elf_relocate_section /usr/bin/ld: Please report this bug. Log: http://www.tmux.org/~tobiasu/tmp/gcc48-mips64-build.txt Others have run into this, and it's possibly fixed in newer binutils, but I have not been able to make sense of the BFD guts enough to fix ld. Question is, should I commit this in its current form so others can try their luck? I'm pretty sure this patch is 95% there. Yes, please. Seconded. It's a known bug that's fixed in 2.17, iirc. Yup. I can confirm that. Wait, so did you try this patch? Does it build? mips64 or mips64el?
[UPDATE] p5-Parse-RecDescent to 1.967009
Seemingly lots of fairly important changes, nothing in particular that stands out but it does clean up some memory leaks. https://metacpan.org/changes/distribution/Parse-RecDescent And take maintainership OK? Index: devel/p5-Parse-RecDescent/Makefile === RCS file: /cvs/ports/devel/p5-Parse-RecDescent/Makefile,v retrieving revision 1.14 diff -u -p -u -r1.14 Makefile --- devel/p5-Parse-RecDescent/Makefile 11 Mar 2013 10:50:20 - 1.14 +++ devel/p5-Parse-RecDescent/Makefile 2 May 2014 16:15:15 - @@ -1,13 +1,17 @@ # $OpenBSD: Makefile,v 1.14 2013/03/11 10:50:20 espie Exp $ -COMMENT= perl module to generate recursive descent parsers +COMMENT = perl module to generate recursive descent parsers -MODULES= cpan -DISTNAME= Parse-RecDescent-1.965001 -CATEGORIES=devel perl5 -USE_GROFF= Yes +MODULES = cpan +DISTNAME = Parse-RecDescent-1.967009 +CATEGORIES = devel + +MAINTAINER = Andrew Fresh afre...@openbsd.org # Artistic -PERMIT_PACKAGE_CDROM= Yes +PERMIT_PACKAGE_CDROM = Yes + +TEST_DEPENDS = devel/p5-Test-Pod=1.14 \ + devel/p5-Test-Warn .include bsd.port.mk Index: devel/p5-Parse-RecDescent/distinfo === RCS file: /cvs/ports/devel/p5-Parse-RecDescent/distinfo,v retrieving revision 1.5 diff -u -p -u -r1.5 distinfo --- devel/p5-Parse-RecDescent/distinfo 10 Mar 2011 22:51:29 - 1.5 +++ devel/p5-Parse-RecDescent/distinfo 2 May 2014 16:15:15 - @@ -1,5 +1,2 @@ -MD5 (Parse-RecDescent-1.965001.tar.gz) = 6RNRrReaOEP76OUhsTWsrw== -RMD160 (Parse-RecDescent-1.965001.tar.gz) = ZLrLtYEYNsBTW7H6DctSyLZpB8c= -SHA1 (Parse-RecDescent-1.965001.tar.gz) = vsR/agEbHC3RF1sVwQb73VHLzVU= -SHA256 (Parse-RecDescent-1.965001.tar.gz) = APpjA5sGJFLWdXEuWPAxHXMjN3rzzdD9zLHs/mS2jWQ= -SIZE (Parse-RecDescent-1.965001.tar.gz) = 154813 +SHA256 (Parse-RecDescent-1.967009.tar.gz) = 4QAPC4IlYmn7japDqrFmp4MvwYtGia98jW0aSf51xoc= +SIZE (Parse-RecDescent-1.967009.tar.gz) = 170858
Re: mips64[el] for gcc 4.8 (unfinished)
On 05/09/14 23:20, Tobias Ulmer wrote: On Fri, May 09, 2014 at 03:39:50PM -0400, Brian Callahan wrote: On 05/09/14 14:41, Pascal Stumpf wrote: On Fri, 09 May 2014 01:22:45 -0400, Brian Callahan wrote: On 05/08/14 19:39, Tobias Ulmer wrote: I've invested some time into adding the mips64(el) backend. It gets quite far (xgcc seems to be fine), but then our ld takes a dump: /usr/bin/ld: not enough GOT space for local GOT entries /usr/bin/ld: BFD 2.15 internal error, aborting at /usr/src/gnu/usr.bin/binutils /bfd/elfxx-mips.c line 6483 in _bfd_mips_elf_relocate_section /usr/bin/ld: Please report this bug. Log: http://www.tmux.org/~tobiasu/tmp/gcc48-mips64-build.txt Others have run into this, and it's possibly fixed in newer binutils, but I have not been able to make sense of the BFD guts enough to fix ld. Question is, should I commit this in its current form so others can try their luck? I'm pretty sure this patch is 95% there. Yes, please. Seconded. It's a known bug that's fixed in 2.17, iirc. Yup. I can confirm that. Wait, so did you try this patch? Does it build? mips64 or mips64el? I'm just confirming that the ld error is fixed with binutils-2.17: it's the exact same error as gcc-4.6 and I did have a built gcc-4.6/binutils-2.17 combo on loongson. No reason to suspect that gcc-4.8 won't build with binutils-2.17 as well. I don't have the time to test gcc-4.8/binutils-2.17 right now but I will if people really want.
Re: mips64[el] for gcc 4.8 (unfinished)
On Fri, May 09, 2014 at 11:24:34PM -0400, Brian Callahan wrote: On 05/09/14 23:20, Tobias Ulmer wrote: On Fri, May 09, 2014 at 03:39:50PM -0400, Brian Callahan wrote: On 05/09/14 14:41, Pascal Stumpf wrote: On Fri, 09 May 2014 01:22:45 -0400, Brian Callahan wrote: On 05/08/14 19:39, Tobias Ulmer wrote: I've invested some time into adding the mips64(el) backend. It gets quite far (xgcc seems to be fine), but then our ld takes a dump: /usr/bin/ld: not enough GOT space for local GOT entries /usr/bin/ld: BFD 2.15 internal error, aborting at /usr/src/gnu/usr.bin/binutils /bfd/elfxx-mips.c line 6483 in _bfd_mips_elf_relocate_section /usr/bin/ld: Please report this bug. Log: http://www.tmux.org/~tobiasu/tmp/gcc48-mips64-build.txt Others have run into this, and it's possibly fixed in newer binutils, but I have not been able to make sense of the BFD guts enough to fix ld. Question is, should I commit this in its current form so others can try their luck? I'm pretty sure this patch is 95% there. Yes, please. Seconded. It's a known bug that's fixed in 2.17, iirc. Yup. I can confirm that. Wait, so did you try this patch? Does it build? mips64 or mips64el? I'm just confirming that the ld error is fixed with binutils-2.17: it's the exact same error as gcc-4.6 and I did have a built gcc-4.6/binutils-2.17 combo on loongson. No reason to suspect that gcc-4.8 won't build with binutils-2.17 as well. I don't have the time to test gcc-4.8/binutils-2.17 right now but I will if people really want. Thanks, I'll try that myself for now :)
[UPDATE] devel/p5-Params-Validate to 1.09
Try this again, hopefully can get it in before there is another new
version this time.
This changes, in addition to all the other fixes, some potential
segfaults.
https://metacpan.org/changes/distribution/Params-Validate
Plus take maintainership.
OK?
Index: devel/p5-Params-Validate//Makefile
===
RCS file: /cvs/ports/devel/p5-Params-Validate/Makefile,v
retrieving revision 1.31
diff -u -p -u -r1.31 Makefile
--- devel/p5-Params-Validate//Makefile 11 Mar 2013 10:50:20 - 1.31
+++ devel/p5-Params-Validate//Makefile 10 May 2014 04:12:38 -
@@ -1,24 +1,31 @@
# $OpenBSD: Makefile,v 1.31 2013/03/11 10:50:20 espie Exp $
-SHARED_ONLY= Yes
+SHARED_ONLY = Yes
-COMMENT= perl module to validate function/method parameters
+COMMENT = perl module to validate function/method parameters
-MODULES= cpan
-DISTNAME= Params-Validate-0.95
-REVISION= 3
-CATEGORIES=devel
-USE_GROFF =Yes
+DISTNAME = Params-Validate-1.09
+CATEGORIES = devel
-# perl
-PERMIT_PACKAGE_CDROM= Yes
+MAINTAINER = Andrew Fresh afre...@openbsd.org
+
+# artistic_2
+PERMIT_PACKAGE_CDROM = Yes
+
+MODULES = cpan
WANTLIB += c
-TEST_DEPENDS= devel/p5-Test-Taint=1.04 \
- devel/p5-Readonly=1.03 \
- devel/p5-Readonly-XS=1.05
+CONFIGURE_STYLE = modbuild
+
+RUN_DEPENDS = devel/p5-Module-Implementation
+
+TEST_DEPENDS = devel/p5-Test-Fatal \
+ devel/p5-Test-Requires
-CONFIGURE_STYLE= modbuild
+# Optional depends to avoid skipping tests
+TEST_DEPENDS +=devel/p5-Test-Taint=0.02 \
+ devel/p5-Readonly \
+ devel/p5-Readonly-XS
.include bsd.port.mk
Index: devel/p5-Params-Validate//distinfo
===
RCS file: /cvs/ports/devel/p5-Params-Validate/distinfo,v
retrieving revision 1.13
diff -u -p -u -r1.13 distinfo
--- devel/p5-Params-Validate//distinfo 30 Jun 2010 18:20:52 - 1.13
+++ devel/p5-Params-Validate//distinfo 10 May 2014 04:12:38 -
@@ -1,5 +1,2 @@
-MD5 (Params-Validate-0.95.tar.gz) = 9UTxI1euS6RARM2Msrg6nw==
-RMD160 (Params-Validate-0.95.tar.gz) = DWpmlhkPQ+xFsu8aiGanRrHQOcA=
-SHA1 (Params-Validate-0.95.tar.gz) = YAEVL2AnXyJMv8ivuCEpgyhpN0Y=
-SHA256 (Params-Validate-0.95.tar.gz) =
BznM0OfHwP/A4q15fXjkLAUOYperWNVvkKDk3mI/iUI=
-SIZE (Params-Validate-0.95.tar.gz) = 120408
+SHA256 (Params-Validate-1.09.tar.gz) =
3XtCSWTg39u/Sx8ZnoTdyjZVnHGLNqfnyId1+ijSgOY=
+SIZE (Params-Validate-1.09.tar.gz) = 103984
Index: devel/p5-Params-Validate//pkg/PLIST
===
RCS file: /cvs/ports/devel/p5-Params-Validate/pkg/PLIST,v
retrieving revision 1.10
diff -u -p -u -r1.10 PLIST
--- devel/p5-Params-Validate//pkg/PLIST 8 Jan 2006 16:20:49 - 1.10
+++ devel/p5-Params-Validate//pkg/PLIST 10 May 2014 04:12:38 -
@@ -4,15 +4,18 @@ ${P5ARCH}/Attribute/
${P5ARCH}/Attribute/Params/
${P5ARCH}/Attribute/Params/Validate.pm
${P5ARCH}/Params/
+${P5ARCH}/Params/Validate/
${P5ARCH}/Params/Validate.pm
+${P5ARCH}/Params/Validate/Constants.pm
+${P5ARCH}/Params/Validate/PP.pm
+${P5ARCH}/Params/Validate/XS.pm
${P5ARCH}/Params/ValidatePP.pm
${P5ARCH}/Params/ValidateXS.pm
${P5ARCH}/auto/
${P5ARCH}/auto/Params/
${P5ARCH}/auto/Params/Validate/
-${P5ARCH}/auto/Params/Validate/Validate.bs
-${P5ARCH}/auto/Params/Validate/Validate.so
+${P5ARCH}/auto/Params/Validate/XS/
+${P5ARCH}/auto/Params/Validate/XS/XS.bs
+${P5ARCH}/auto/Params/Validate/XS/XS.so
@man man/man3p/Attribute::Params::Validate.3p
@man man/man3p/Params::Validate.3p
-@man man/man3p/Params::ValidatePP.3p
-@man man/man3p/Params::ValidateXS.3p
[NEW] devel/p5-Package-Variant
A new dependency for the upcoming p5-SQL-Translator update. This module allows you to build packages that return different variations depending on what parameters are given. Users of your package will receive a subroutine able to take parameters and return the name of a suitable variant package. The implementation does not care about what kind of package it builds. OK? p5-Package-Variant.tar.gz Description: application/tar-gz
Re: new: reop-1.0.0
On 5/9/14, Ted Unangst t...@tedunangst.com wrote:
On Fri, May 09, 2014 at 18:09, Ted Unangst wrote:
On Fri, May 09, 2014 at 19:49, Stuart Henderson wrote:
Works on amd64, but macppc fails tests:
=== Regression tests for reop-1.0.0
reop: decryption failed
I'll one up that. It segfaults on sparc64. :(
This will fix it, at the cost of making startup slow as balls. The one
second test.sh now takes over 15 seconds to run.
The libsodium documentation says this isn't required. Obviously, it's
a crypto library, therefore it lies.
diff -r b7b0f515429c reop.c
--- a/reop.cSat Apr 19 11:32:25 2014 -0400
+++ b/reop.cFri May 09 18:17:07 2014 -0400
@@ -1054,6 +1054,7 @@
VERIFY
} verb = NONE;
+ sodium_init();
rounds = 42;
Ted, what is the purpose of the first if-statement
in readident()?
static char *
readident(char *buf, char *ident)
{
if (IDENTLEN != 64)
errx(1, wrong IDENTLEN);
...
given on line 62:
#define IDENTLEN 64
$ cc -E /tmp/reop.c | grep -A3 ^readident
/tmp/reop.c:36:20: error: sodium.h: No such file or directory
readident(char *buf, char *ident)
{
if (64 != 64)
errx(1, wrong IDENTLEN);
just curious.
--patrick
Re: APE Server
On 2014/05/07 13:05, Henning Brauer wrote: is somebody more experienced in ports willing to make one? SNIP On Fri, May 09, 2014 at 10:01:02PM +0100, Stuart Henderson wrote: It's not particularly simple; Do you *need* APE or just something to do Comet Push? You can fairly easily write a Comet server in Mojolicious, plus it supports websockets. There may be other, better options, depending on what you're trying to accomplish. http://toroid.org/ams/etc/mojolicious-http-streaming l8rZ, -- andrew - http://afresh1.com A printer consists of three main parts: the case, the jammed paper tray and the blinking red light.
[UPDATE] p5-MooseX-Types-LoadableClass to 0.012
Minor update, bugfixes, required for the upcoming p5- DBIx-Class update. https://metacpan.org/changes/distribution/MooseX-Types-LoadableClass Plus take maintainership OK? Index: devel/p5-MooseX-Types-LoadableClass/Makefile === RCS file: /cvs/ports/devel/p5-MooseX-Types-LoadableClass/Makefile,v retrieving revision 1.2 diff -u -p -u -r1.2 Makefile --- devel/p5-MooseX-Types-LoadableClass/Makefile11 Mar 2013 10:50:19 - 1.2 +++ devel/p5-MooseX-Types-LoadableClass/Makefile2 May 2014 16:15:13 - @@ -3,14 +3,22 @@ COMMENT = ClassName type constraint with coercion to load the class MODULES = cpan -DISTNAME = MooseX-Types-LoadableClass-0.006 +DISTNAME = MooseX-Types-LoadableClass-0.012 CATEGORIES = devel -# same as perl +MAINTAINER = Andrew Fresh and...@cpan.org + +# perl_5 PERMIT_PACKAGE_CDROM = Yes RUN_DEPENDS = devel/p5-Class-Load \ + devel/p5-Module-Runtime \ + devel/p5-Moose \ devel/p5-MooseX-Types \ - devel/p5-namespace-clean + devel/p5-namespace-autoclean + +BUILD_DEPENDS =devel/p5-Module-Build-Tiny=0.030 + +TEST_DEPENDS = devel/p5-Test-Fatal .include bsd.port.mk Index: devel/p5-MooseX-Types-LoadableClass/distinfo === RCS file: /cvs/ports/devel/p5-MooseX-Types-LoadableClass/distinfo,v retrieving revision 1.1.1.1 diff -u -p -u -r1.1.1.1 distinfo --- devel/p5-MooseX-Types-LoadableClass/distinfo8 Apr 2012 21:05:28 - 1.1.1.1 +++ devel/p5-MooseX-Types-LoadableClass/distinfo2 May 2014 16:15:13 - @@ -1,5 +1,2 @@ -MD5 (MooseX-Types-LoadableClass-0.006.tar.gz) = 9c8m2Pa65WGV/13shINR6A== -RMD160 (MooseX-Types-LoadableClass-0.006.tar.gz) = 6csklda41U44dl9JS6OQmv2hHzw= -SHA1 (MooseX-Types-LoadableClass-0.006.tar.gz) = P8KH1bz5s/717ZDhG01ObmNuDYs= -SHA256 (MooseX-Types-LoadableClass-0.006.tar.gz) = RD+fv4MKbjaYk65WvBOGoS9tshRbyTTs1MDIgP8TrQw= -SIZE (MooseX-Types-LoadableClass-0.006.tar.gz) = 20303 +SHA256 (MooseX-Types-LoadableClass-0.012.tar.gz) = odKxhsK2n0FrsMknHchpLCKHwvbOFEzDubLJIkJwYN8= +SIZE (MooseX-Types-LoadableClass-0.012.tar.gz) = 20629
[UPDATE] p5-MRO-Compat to 0.12
Minor update required for upcoming p5-DBIx-Class update.
https://metacpan.org/changes/distribution/MRO-Compat
OK?
Index: devel/p5-MRO-Compat/Makefile
===
RCS file: /cvs/ports/devel/p5-MRO-Compat/Makefile,v
retrieving revision 1.10
diff -u -p -u -r1.10 Makefile
--- devel/p5-MRO-Compat/Makefile11 Oct 2013 23:48:58 - 1.10
+++ devel/p5-MRO-Compat/Makefile2 May 2014 16:15:12 -
@@ -1,20 +1,25 @@
# $OpenBSD: Makefile,v 1.10 2013/10/11 23:48:58 naddy Exp $
-COMMENT= mro::* interface compatibility for Perl 5.9.5
+COMMENT = mro::* interface compatibility for Perl 5.9.5
-MODULES= cpan
-DISTNAME= MRO-Compat-0.11
-REVISION= 0
-CATEGORIES=devel
+DISTNAME = MRO-Compat-0.12
+CATEGORIES = devel
-CPAN_AUTHOR= FLORA
+CPAN_AUTHOR = BOBTFISH
-# Perl
-PERMIT_PACKAGE_CDROM= Yes
+MAINTAINER = Andrew Fresh afre...@openbsd.org
-RUN_DEPENDS= devel/p5-Class-C3=0.20
-BUILD_DEPENDS= ${RUN_DEPENDS}
+# perl_5
+PERMIT_PACKAGE_CDROM = Yes
-CONFIGURE_STYLE= modinst
+MODULES = cpan
+
+CONFIGURE_STYLE = modinst
+
+RUN_DEPENDS = devel/p5-Class-C3=0.20
+
+# Optional depends to avoid skipping tests
+TEST_DEPENDS = devel/p5-Test-Pod \
+ devel/p5-Test-Pod-Coverage
.include bsd.port.mk
Index: devel/p5-MRO-Compat/distinfo
===
RCS file: /cvs/ports/devel/p5-MRO-Compat/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- devel/p5-MRO-Compat/distinfo19 Jun 2009 00:25:39 - 1.3
+++ devel/p5-MRO-Compat/distinfo2 May 2014 16:15:12 -
@@ -1,5 +1,2 @@
-MD5 (MRO-Compat-0.11.tar.gz) = RitoYx1b74yAcZDxxcFzBg==
-RMD160 (MRO-Compat-0.11.tar.gz) = j+mwT1RdtmhvsKaDkwvsZTdnmio=
-SHA1 (MRO-Compat-0.11.tar.gz) = KVlU484M1bHfHpksmHqJ5cb7dxM=
-SHA256 (MRO-Compat-0.11.tar.gz) = B0snVDEQ09bfkUxJ71r8e0hx2mSKq4GlHLqx5xmgUFw=
-SIZE (MRO-Compat-0.11.tar.gz) = 20474
+SHA256 (MRO-Compat-0.12.tar.gz) = u6W5OGmqU3oziZSWadaC8EfTAU1TvDotcgnGgZ5QFdY=
+SIZE (MRO-Compat-0.12.tar.gz) = 24230
