CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/01/02 02:41:59 Modified files: productivity/zeitgeist: Makefile Added files: productivity/zeitgeist/patches: patch-libzeitgeist_event_vala Log message: Do not optimize the event variant because that would lead to a segfault when converting back via from_variant with several events (upstream). This fixes an empathy and gnome-contacts crash. ok jasper@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2014/01/02 04:35:18 Modified files: net/gajim : Makefile distinfo Added files: net/gajim/patches: patch-src_common_helpers_py Log message: - update to gajim-0.15.4 - add missing dependency needed for ssl cert verification ok pea@ (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/01/02 04:54:43 Modified files: net/openconnect: Makefile distinfo Log message: update to OpenConnect 5.02 notable changes: - workaround for XML POST issues with authgroups (full fix in a future release, but this interim release has been made to avoid an ABI break) - fix potential memory corruption which could be triggered by a malicious server
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/01/02 05:21:49 Modified files: x11/mplayer: Makefile emulators/openmsx: Makefile graphics/rawstudio: Makefile distinfo Log message: Fix some of the ports broken by the move to PIE on i386. This fixes those ports where there are now insufficient registers, for which using -fomit-frame-pointer (to free up ebp) is enough to get them building again. Regen distinfo while there.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2014/01/02 06:04:34 Modified files: net/bitlbee: Makefile distinfo net/bitlbee/patches: patch-configure patch-lib_misc_c Removed files: net/bitlbee/patches: patch-otr_c patch-otr_h Log message: Update to bitlbee 3.2.1, from maintainer Tom Doherty.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2014/01/02 06:28:22 Modified files: x11/gigolo : Makefile x11/gigolo/pkg : PLIST Removed files: x11/gigolo/patches: patch-wscript Log message: Switch from waf to use autoconf/automake. While here fix WANTLIB PLIST.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2014/01/02 06:50:31 Modified files: net/pidgin-sipe: Makefile distinfo Log message: Update to pidgin-sipe 1.17.3, from maintainer Tom Doherty
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2014/01/02 07:01:53 Modified files: www/vteplugin : Makefile Log message: Stop using waf, it's actually much simpler to write a do-build target rather than dealing with a piece-of-crap build system hostile towards packagers. Fix WANTLIB while here. Nothing uses devel/waf in tree anymore now. VS: --
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2014/01/02 07:02:17 Removed files: www/vteplugin/patches: patch-wscript Log message: Forgotten in previous
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2014/01/02 15:01:24 Modified files: net/curl : Makefile distinfo net/curl/pkg : PLIST Added files: net/curl/patches: patch-docs_libcurl_curl_easy_setopt_3 Removed files: net/curl/patches: patch-include_curl_curl_h Log message: maintenance update to 7.34.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2014/01/02 18:36:39 Log message: Import Livestreamer-curses, a curses-based UI for livestreamer that allows you to manage your favorite streams. reads good to landry@ Status: Vendor Tag: bcallah Release Tags: bcallah_2014-Jan-02 N ports/multimedia/livestreamer-curses/Makefile N ports/multimedia/livestreamer-curses/distinfo N ports/multimedia/livestreamer-curses/files/livestreamer-curses N ports/multimedia/livestreamer-curses/pkg/PLIST N ports/multimedia/livestreamer-curses/pkg/DESCR No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2014/01/02 18:37:03 Modified files: multimedia : Makefile Log message: +livestreamer-curses
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/01/02 23:21:04 Modified files: net/gnugk : Makefile distinfo net/gnugk/patches: patch-ProxyChannel_cxx patch-configure Removed files: net/gnugk/patches: patch-docs_gnugk_1 patch-gk_cxx Log message: Update to gnugk-3.5.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/01/02 23:39:57 Modified files: security/libgpg-error: Makefile Log message: Fix HOMEPAGE.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/01/02 23:43:06 Modified files: security/libtasn1: Makefile distinfo security/libtasn1/pkg: PLIST Log message: Update to libtasn1-3.4.
Re: Update net/tintin++ to 2.00.9
On Jan 1, 2014 9:32 PM, Brian Callahan bcal...@devio.us wrote: On 1/1/2014 11:35 PM, Ted Roby wrote: This diff was run against -current. It updates net/tintin++ to 2.00.9. Any reason not to have updated to 2.01.0? I missed this very recent update. Pedantic nit: the license is actually GPLv2+ Thanks!
Re: i386 bulk build failures
hmm, on Wed, Jan 01, 2014 at 09:38:48PM +, Stuart Henderson said that Following are PIE-related, in some cases use of -fomit-frame-pointer for i386 may help, others will need more. devel/hasktags: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' devel/hs-ghc-paths: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' emulators/dosbox: PIC register '%ebx' clobbered in 'asm' emulators/mupen64plus/core: now uses PIC #ifdef in src/r4300/x86/rjump.c:104 which needs newer GCC (about to send diff for this). emulators/openmsx: out of reg's emulators/xnp2: PIC register 'ebx' clobbered in 'asm' games/eduke32: out of reg's games/megaglest/base: out of reg's games/openarena: out of reg's graphics/cqcam: PIC register 'bx' clobbered in 'asm' graphics/rawstudio: out of reg's multimedia/avidemux: out of reg's sysutils/grub: GRUB requires a working absolute objcopy x11/mplayer: out of reg's x11/xdesktopwaves: PIC register 'ebx' clobbered in 'asm' the mpv port i submitted gets out of reg's now as well. the project told me they have added a --disable-asm configure switch (because of openbsd's old toolchain) and also they plan to move to ffmpeg stuff instead of the builtin asm stuff. working on their new release now but waf is in my way... -f -- the devil can cite scripture for his purpose.
Re: PostgreSQL: Critical update !
On k, dec 29, 2013 at 22:37:16 +0100, Pierre-Emmanuel André wrote: [...] I made a diff for: [...] + 5.3 -stable (PostgreSQL 9.2.6, NOT tested but it should work. If anyone has a 5.3 system it would be nice to give it a try) Hey guys, I hope I'm not too late for the party. The build and install went fine (although I was not able to `make package` from ports/mystuff, it needed the ports/database/postgresql to be patched also). The server and the client library works as expected on 5.3. Thank you, Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: Work on mongodb
A new patch, it is working on i386 ( I can start, connect, create a
database, insert elements and query):
$ cvs diff -Nup .
Index: Makefile
===
RCS file: /cvs/ports/databases/mongodb/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile10 Dec 2013 17:30:40 - 1.11
+++ Makefile2 Jan 2014 10:52:13 -
@@ -1,13 +1,13 @@
# $OpenBSD: Makefile,v 1.11 2013/12/10 17:30:40 joshe Exp $
-BROKEN = broken after rthreads switch
+#BROKEN = broken after rthreads switch
#atomic_int.h: error unsupported compiler or platform on other archs
ONLY_FOR_ARCHS = i386 amd64
COMMENT = scalable, high-performance document-oriented database
-DISTNAME = mongodb-src-r2.4.7
+DISTNAME = mongodb-src-r2.4.8
PKGNAME = ${DISTNAME:S/src-r//}
SHARED_LIBS = mongoclient 2.0
@@ -25,8 +25,13 @@ WANTLIB =boost_filesystem-mt boost_prog
MASTER_SITES = http://downloads.mongodb.org/src/
-MODULES = devel/scons
+MODULES = devel/scons
+MODULES += gcc4
+MODGCC4_ARCHS = i386 amd64
+MODGCC4_LANGS = c c++
+
MODSCONS_FLAGS = --prefix=${PREFIX} \
+--cc=egcc --cxx=eg++ \
--cpppath=${LOCALBASE}/include/nspr \
--extralib=pcrecpp \
--usev8 \
Index: distinfo
===
RCS file: /cvs/ports/databases/mongodb/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo10 Dec 2013 17:30:41 - 1.5
+++ distinfo2 Jan 2014 10:52:13 -
@@ -1,2 +1,2 @@
-SHA256 (mongodb-src-r2.4.7.tar.gz) =
aePPaXIl76Lm5l9c/cMXQvPksuBpwn2E/HE6vgv2fKc=
-SIZE (mongodb-src-r2.4.7.tar.gz) = 14157198
+SHA256 (mongodb-src-r2.4.8.tar.gz) =
/XA85eU936DMqcf7qaDEzqQXnTiXKpjGdfRdnxW0z9w=
+SIZE (mongodb-src-r2.4.8.tar.gz) = 14157223
2013/12/31, Amit Kulkarni amitk...@gmail.com:
On Tue, Dec 31, 2013 at 9:59 AM, Rodrigo Mosconi
open...@mosconi.mat.brwrote:
I`ve made some changes on MongoDB port, and I could compile and started
it.
This are my changes:
$ cvs diff -u databases/mongodb
No comment about the port but in future send a cvs diff -Nup
Re: UPDATE: fonts/dina-fonts
On Wed, Jan 01, 2014 at 08:34:02PM +0100, Rafael Sadowski wrote: [...] Looks almost good to me, but you added a new font and there is no PLIST change. Spot the error ;) Index: pkg/PLIST === RCS file: /cvs/ports/fonts/dina-fonts/pkg/PLIST,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 PLIST --- pkg/PLIST 7 Dec 2011 09:27:16 - 1.1.1.1 +++ pkg/PLIST 1 Jan 2014 19:32:33 - @@ -14,3 +14,5 @@ lib/X11/fonts/dina/DinaMedium10.pcf.gz lib/X11/fonts/dina/DinaMedium8.pcf.gz lib/X11/fonts/dina/DinaMedium9.pcf.gz lib/X11/fonts/dina/fonts.alias-dina +share/doc/dina-fonts/ +share/doc/dina-fonts/LICENSE
Re: NEW: multimedia/livestreamer-curses
On Tue, Dec 31, 2013 at 12:08:42PM -0500, Brian Callahan wrote: On 12/25/2013 10:33 PM, Brian Callahan wrote: Hi ports -- Attached is a new port, multimedia/livestreamer-curses. Livestreamer-curses is a curses-based front-end for livestreamer which allows easy administration of your favorite live streams. Works good on amd64. OK? I'm not fond of running compileall.py during do-install, but i've never understood how/why python ports liked rebuilding stuff all the time during fake.. other than that reads good to me. Landry
Re: [Update] Zsh 5.0.3
On Thu, Dec 19, 2013 at 04:47:14PM +0100, Pierre-Emmanuel André wrote:
Hi,
Small diff to update Zsh to it's latest version. I added a new
MASTER_SITE because the tarball has not yet reached the sourceforge sites.
Tested on @amd64.
Updated diff to the latest version (5.0.4).
Spotted by Theo Buehler, thanks.
--
Pierre-Emmanuel André pea at raveland.org
GPG key: 0xBB8D3F0E
Index: Makefile
===
RCS file: /cvs/ports/shells/zsh/Makefile,v
retrieving revision 1.69
diff -u -p -u -p -r1.69 Makefile
--- Makefile 2 Oct 2013 19:49:11 - 1.69
+++ Makefile 2 Jan 2014 08:16:09 -
@@ -2,7 +2,7 @@
COMMENT= Z shell, Bourne shell-compatible
-V= 5.0.2
+V= 5.0.4
DISTNAME= zsh-$V
CATEGORIES= shells
@@ -10,7 +10,8 @@ MAINTAINER= Pierre-Emmanuel Andre pea@o
HOMEPAGE= http://www.zsh.org/
-MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=zsh/}
+MASTER_SITES= ${HOMEPAGE}/pub/ \
+ ${MASTER_SITE_SOURCEFORGE:=zsh/}
# BSD
PERMIT_PACKAGE_CDROM= Yes
Index: distinfo
===
RCS file: /cvs/ports/shells/zsh/distinfo,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 distinfo
--- distinfo 2 Oct 2013 19:49:12 - 1.18
+++ distinfo 2 Jan 2014 08:16:09 -
@@ -1,2 +1,2 @@
-SHA256 (zsh-5.0.2.tar.gz) = rcDHiBUyQZeXcTt8UDvMVnTIj5OhkeJvcAtCwRoagW4=
-SIZE (zsh-5.0.2.tar.gz) = 3823234
+SHA256 (zsh-5.0.4.tar.gz) = 7Rzu/B9blfaRgd9iyquZFcwMqo9GdNa3mzl+hjC3BuY=
+SIZE (zsh-5.0.4.tar.gz) = 3912090
Index: patches/patch-Doc_Makefile_in
===
RCS file: /cvs/ports/shells/zsh/patches/patch-Doc_Makefile_in,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 patch-Doc_Makefile_in
--- patches/patch-Doc_Makefile_in 4 Nov 2008 10:00:59 - 1.5
+++ patches/patch-Doc_Makefile_in 2 Jan 2014 08:16:09 -
@@ -1,17 +1,17 @@
$OpenBSD: patch-Doc_Makefile_in,v 1.5 2008/11/04 10:00:59 pea Exp $
Doc/Makefile.in.orig Thu Oct 30 12:56:08 2008
-+++ Doc/Makefile.in Mon Nov 3 22:44:41 2008
-@@ -275,11 +275,11 @@ Zsh/manmodmenu.yo: $(MODDOCSRC)
+--- Doc/Makefile.in.orig Wed Nov 27 20:00:20 2013
Doc/Makefile.in Thu Dec 19 13:25:27 2013
+@@ -296,11 +296,11 @@ Zsh/manmodmenu.yo: $(MODDOCSRC)
# == DEPENDENCIES FOR INSTALLING ==
- # install just installs the manual pages
--install: install.man
-+install: install.man install.info
+ # install just installs the manual and runhelp pages
+-install: install.man install.runhelp
++install: install.man install.runhelp install.info
.PHONY: install
- # uninstall just unistalls the manual pages
--uninstall: uninstall.man
-+uninstall: uninstall.man uninstall.info
+ # uninstall just uninstalls the manual and runhelp pages
+-uninstall: uninstall.man uninstall.runhelp
++uninstall: uninstall.man uninstall.runhelp install.info
.PHONY: uninstall
# install man pages, creating install directory if necessary
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/shells/zsh/patches/patch-Makefile_in,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-Makefile_in
--- patches/patch-Makefile_in 12 Jul 2004 19:46:52 - 1.1
+++ patches/patch-Makefile_in 2 Jan 2014 08:16:09 -
@@ -1,14 +1,14 @@
$OpenBSD: patch-Makefile_in,v 1.1 2004/07/12 19:46:52 lebel Exp $
Makefile.in.orig Mon Sep 10 06:48:44 2001
-+++ Makefile.in Sun Nov 18 12:17:48 2001
+--- Makefile.in.orig Wed Nov 27 20:00:20 2013
Makefile.in Thu Dec 19 13:25:58 2013
@@ -63,8 +63,8 @@ install-strip:
$(MAKE) install STRIPFLAGS=-s
# install/uninstall most things
--install: install.bin install.modules install.fns install.man
--uninstall: uninstall.bin uninstall.modules uninstall.fns uninstall.man
-+install: install.bin install.modules install.fns install.man install.info
-+uninstall: uninstall.bin uninstall.modules uninstall.fns uninstall.man uninstall.info
+-install: install.bin install.modules install.fns install.man install.runhelp
+-uninstall: uninstall.bin uninstall.modules uninstall.fns uninstall.man uninstall.runhelp
++install: install.bin install.modules install.fns install.man install.runhelp install.info
++uninstall: uninstall.bin uninstall.modules uninstall.fns uninstall.man uninstall.runhelp install.info
# install/uninstall just the binary
install.bin uninstall.bin:
Index: pkg/PLIST
===
RCS file: /cvs/ports/shells/zsh/pkg/PLIST,v
retrieving revision 1.37
diff -u -p -u -p -r1.37 PLIST
--- pkg/PLIST 2 Oct 2013 19:49:14 - 1.37
+++ pkg/PLIST 2 Jan 2014 08:16:09 -
@@ -122,6 +122,7 @@ share/zsh/${V}/functions/_calendar
share/zsh/${V}/functions/_call_function
share/zsh/${V}/functions/_call_program
share/zsh/${V}/functions/_canonical_paths
+share/zsh/${V}/functions/_cat
share/zsh/${V}/functions/_ccal
share/zsh/${V}/functions/_cd
Re: i386 bulk build failures
Stuart Henderson st...@openbsd.org wrote: Not sure about cause yet, some may be PIE-related too: These are not: lang/gcc/4.8: gcj: fatal error: can't specify '-D' without '--main' Sporadic build failure; also happens on amd64. mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. Also on amd64. Likely fallout from the devel/swig update a week ago. -- Christian naddy Weisgerber na...@mips.inka.de
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 01:52:03PM +, Christian Weisgerber wrote: Stuart Henderson st...@openbsd.org wrote: Not sure about cause yet, some may be PIE-related too: These are not: lang/gcc/4.8: gcj: fatal error: can't specify '-D' without '--main' Sporadic build failure; also happens on amd64. mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. Also on amd64. Likely fallout from the devel/swig update a week ago. I Haven't seen them in the bulk build i ran with the swig update diff.. Landry
Re: waf woes
On 1/01/2014 7:00 AM, Brad Smith wrote: snip Sadly enough autohell is the suck least of build infrastructure and there is a lot of documentation and knowledge regarding its inner workings. IMO not something that can be said about the other build infrastructure whether it is relatively common or not. It might not be m4, but it is python, that's a pretty heavy dependency for build infrastructure. Yup and any new samba + external samba deps is riddled with it. It's what is stopping me from moving forward atm. Need to learn python. At least I have a few weeks to pull out some python books. A newer in tree waf, or multiple versions would help ease the situation rather than patch the hell out of samba build infrastructure. Ian McWilliam
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 02:58:55PM +0100, Landry Breuil wrote: mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. Also on amd64. Likely fallout from the devel/swig update a week ago. I Haven't seen them in the bulk build i ran with the swig update diff.. Well, they are there anyways. I see them too.
Re: waf woes
On Thu, Jan 02, 2014 at 11:40:40PM +1100, Ian McWilliam wrote: On 1/01/2014 7:00 AM, Brad Smith wrote: snip Sadly enough autohell is the suck least of build infrastructure and there is a lot of documentation and knowledge regarding its inner workings. IMO not something that can be said about the other build infrastructure whether it is relatively common or not. It might not be m4, but it is python, that's a pretty heavy dependency for build infrastructure. Yup and any new samba + external samba deps is riddled with it. It's what is stopping me from moving forward atm. Need to learn python. At least I have a few weeks to pull out some python books. A newer in tree waf, or multiple versions would help ease the situation rather than patch the hell out of samba build infrastructure. I've moved away all waf users from it (ie x11/gigolo www/vteplugin) but i'd rather remove waf from the tree instead of having someone losing time on that crap. Given that it's clearly hostile to any packaging effort, why bother with it ? Just do the minimum and patch all the bundled copies. Landry
Re: waf woes
On Thu, Jan 02, 2014 at 03:19:16PM +0100, Landry Breuil wrote: On Thu, Jan 02, 2014 at 11:40:40PM +1100, Ian McWilliam wrote: On 1/01/2014 7:00 AM, Brad Smith wrote: snip Sadly enough autohell is the suck least of build infrastructure and there is a lot of documentation and knowledge regarding its inner workings. IMO not something that can be said about the other build infrastructure whether it is relatively common or not. It might not be m4, but it is python, that's a pretty heavy dependency for build infrastructure. Yup and any new samba + external samba deps is riddled with it. It's what is stopping me from moving forward atm. Need to learn python. At least I have a few weeks to pull out some python books. A newer in tree waf, or multiple versions would help ease the situation rather than patch the hell out of samba build infrastructure. I've moved away all waf users from it (ie x11/gigolo www/vteplugin) but i'd rather remove waf from the tree instead of having someone losing time on that crap. Given that it's clearly hostile to any packaging effort, why bother with it ? Just do the minimum and patch all the bundled copies. I agree. -- Antoine
Re: JDK 1.6 Broken
I'm in the same boat as Scott (running jdk-1.7.0.21v0 on i386 that now fails with thread error mentioned after upgrading to the Dec. 28 snapshots). I was previously running a snapshot from October so I doubt that helps all that much, but I thought I'd toss it out there. I'd sure like to get my Tomcat server up and running again :) -Nick On Jan 1, 2014 3:38 PM, Scott Vanderbilt li...@datagenic.com wrote: On 1/1/2014 1:21 PM, Stuart Henderson wrote: If anyone is able to help track down the timeframe this got broken (or even pin it to a particular commit in base), that would be extremely helpful... I was previously running a snapshot from Dec. 7 that did not exhibit the error. Sorry I can't be more specific than that.
Re: i386 bulk build failures
Stuart Henderson st...@openbsd.org wrote:
lang/nhc98: segfaults in build
NOT_FOR_ARCHS= ${LP64_ARCHS} powerpc
BROKEN-hppa=Segfault during build since the PIE switch
Do we need this for bootstrapping or reference purposes or can we
just remove it?
lang/petite-chez: undefined reference to `__guard'
ONLY_FOR_ARCHS =i386
Hmm, FreeBSD has a port of 8.4 that at least adds amd64.
Frankly, I would like to kill the remaining !LP64 and i386-only
ports. (Excluding such things as tpwireless.)
--
Christian naddy Weisgerber na...@mips.inka.de
tedu lang/nhc98 (was: i386 bulk build failures)
On Thu, Jan 02, 2014 at 03:16:16PM +, Christian Weisgerber wrote:
lang/nhc98: segfaults in build
NOT_FOR_ARCHS= ${LP64_ARCHS} powerpc
BROKEN-hppa=Segfault during build since the PIE switch
Do we need this for bootstrapping or reference purposes or can we
just remove it?
It's not used for any bootstrapping, it just was meant as a way to
play with Haskell on at least *some* other archs than ghc runs on.
I wouldn't miss it, so feel free to mark it completely broken for
now; its removal also requires some cleanup in devel/cpphs and the
removal of devel/hmake, which I'll can take care of this evening
or tomorrow.
Ciao,
Kili
Re: i386 bulk build failures
On Wed, Jan 01, 2014 at 09:38:48PM +, Stuart Henderson wrote: devel/hasktags: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' devel/hs-ghc-paths: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' I'll update my i386 test installation and have a look. Until then, can you point me to the log files of those two? (FYI: breakage in hs-ghc-paths disables almost all hs-* libraries to be unbuildable, because they depend on haddock which depends on hs-ghc-paths) Ciao, Kili
[SECURITY UPDATE] misc/memcached (STABLE)
Hi,
The following diff fixes CVE-2011-4971 and CVE-2013-0179 for 5.4-STABLE.
They are respectively fixed in Memcached 1.4.16 and 1.4.17 upstream, but
I'm avoiding the update here because I'm targeting -STABLE, and 1.4.15
made things more experimental so 1.4.17 might not be ready yet.
These fixes come from Debian Wheezy, which applied them for
Memcached 1.4.13. Debian also has a patch for CVE-2013-7239, but this
is for SASL which isn't enabled here.
Some links from upstream:
https://code.google.com/p/memcached/issues/detail?id=192
https://code.google.com/p/memcached/issues/detail?id=306
The diff probably applies cleanly for -current as well (MASTER_SITES was
the only change AFAICS).
Index: Makefile
===
RCS file: /cvs/ports/misc/memcached/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile25 Apr 2013 21:33:21 - 1.22
+++ Makefile2 Jan 2014 16:14:48 -
@@ -2,8 +2,8 @@
COMMENT= distributed memory object caching system
-DISTNAME = memcached-1.4.14
-REVISION = 0
+DISTNAME= memcached-1.4.14
+REVISION= 1
CATEGORIES=misc
HOMEPAGE= http://www.memcached.org/
Index: patches/patch-items_c
===
RCS file: /cvs/ports/misc/memcached/patches/patch-items_c,v
retrieving revision 1.5
diff -u -p -r1.5 patch-items_c
--- patches/patch-items_c 25 Apr 2013 21:33:21 - 1.5
+++ patches/patch-items_c 2 Jan 2014 16:14:48 -
@@ -1,6 +1,11 @@
$OpenBSD: patch-items_c,v 1.5 2013/04/25 21:33:21 sthen Exp $
items.c.orig Thu Apr 25 22:31:03 2013
-+++ items.cThu Apr 25 22:31:47 2013
+
+printf format string fix for long long time_t
+
+and fix buffer-overrun when logging keys (CVE-2013-0179)
+
+--- items.c.orig Mon Jul 30 22:23:37 2012
items.cThu Jan 2 17:02:16 2014
@@ -389,9 +389,9 @@ char *do_item_cachedump(const unsigned int slabs_clsid
/* Copy the key since it may not be null-terminated in the struct */
strncpy(key_temp, ITEM_key(it), it-nkey);
@@ -13,3 +18,23 @@ $OpenBSD: patch-items_c,v 1.5 2013/04/25
if (bufcurr + len + 6 memlimit) /* 6 is END\r\n\0 */
break;
memcpy(buffer + bufcurr, temp, len);
+@@ -510,9 +510,17 @@ item *do_item_get(const char *key, const size_t nkey,
+
+ if (settings.verbose 2) {
+ if (it == NULL) {
+-fprintf(stderr, NOT FOUND %s, key);
++int ii;
++fprintf(stderr, NOT FOUND );
++for (ii = 0; ii nkey; ++ii) {
++fprintf(stderr, %c, key[ii]);
++}
+ } else {
+-fprintf(stderr, FOUND KEY %s, ITEM_key(it));
++int ii;
++fprintf(stderr, FOUND KEY );
++for (ii = 0; ii it-nkey; ++ii) {
++fprintf(stderr, %c, ITEM_key(it)[ii]);
++}
+ was_found++;
+ }
+ }
Index: patches/patch-memcached_c
===
RCS file: patches/patch-memcached_c
diff -N patches/patch-memcached_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-memcached_c 2 Jan 2014 16:14:48 -
@@ -0,0 +1,39 @@
+$OpenBSD$
+
+buffer-overrun when logging keys (CVE-2013-0179)
+
+and fix segfault on specially crafted packet (CVE-2011-4971)
+
+--- memcached.c.orig Mon Jul 30 22:26:47 2012
memcached.cThu Jan 2 16:59:32 2014
+@@ -2149,7 +2149,12 @@ static void process_bin_delete(conn *c) {
+ assert(c != NULL);
+
+ if (settings.verbose 1) {
+-fprintf(stderr, Deleting %s\n, key);
++int ii;
++fprintf(stderr, Deleting );
++for (ii = 0; ii nkey; ++ii) {
++fprintf(stderr, %c, key[ii]);
++}
++fprintf(stderr, \n);
+ }
+
+ if (settings.detail_enabled) {
+@@ -3863,6 +3868,16 @@ static void drive_machine(conn *c) {
+ complete_nread(c);
+ break;
+ }
++
++/* Check if rbytes 0, to prevent crash */
++if (c-rlbytes 0) {
++if (settings.verbose) {
++fprintf(stderr, Invalid rlbytes to read: len %d\n,
c-rlbytes);
++}
++conn_set_state(c, conn_closing);
++break;
++}
++
+ /* first check if we have leftovers in the conn_read buffer */
+ if (c-rbytes 0) {
+ int tocopy = c-rbytes c-rlbytes ? c-rlbytes : c-rbytes;
Index: patches/patch-t_issue_192_t
===
RCS file: patches/patch-t_issue_192_t
diff -N patches/patch-t_issue_192_t
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-t_issue_192_t 2 Jan 2014 16:14:48 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+
+Test case for CVE-2011-4971
+
+--- t/issue_192.t.orig Thu Jan 2 16:48:36 2014
Re: UPDATE: fonts/dina-fonts
On Thu Jan 02, 2014 at 01:05:44PM +0100, Tobias Ulmer wrote:
On Wed, Jan 01, 2014 at 08:34:02PM +0100, Rafael Sadowski wrote:
[...]
Looks almost good to me, but you added a new font and there is no PLIST
change. Spot the error ;)
oh sorry. diff with fix:
Index: Makefile
===
RCS file: /cvs/ports/fonts/dina-fonts/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile11 Mar 2013 11:06:05 - 1.3
+++ Makefile2 Jan 2014 17:25:06 -
@@ -1,32 +1,49 @@
# $OpenBSD: Makefile,v 1.3 2013/03/11 11:06:05 espie Exp $
-COMMENT = monospace bitmap font, primarily aimed at programmers
+COMMENT = monospace bitmap font, primarily aimed at programmers
-V =2.89
-PKGNAME = dina-fonts-$V
-DISTNAME = dina-pcf-$V
-CATEGORIES = fonts
+V =2.92
+PKGNAME = dina-fonts-$V
+DISTFILES= dina-fonts-${V}.zip
+CATEGORIES = fonts
-HOMEPAGE = http://www.donationcoder.com/Software/Jibz/Dina/
+HOMEPAGE = http://www.donationcoder.com/Software/Jibz/Dina/
-MAINTAINER = Rafael Sadowski raf...@sizeofvoid.org
+MAINTAINER = Rafael Sadowski raf...@sizeofvoid.org
-# FREE (c) Jorgen Ibsen (Though no license included in distribution)
-PERMIT_PACKAGE_CDROM = No
-PERMIT_PACKAGE_FTP = No
-PERMIT_DISTFILES_FTP = No
+# MIT
+PERMIT_PACKAGE_CDROM = Yes
-MASTER_SITES = http://ftp.fi.debian.org/gentoo/distfiles/
+EXTRACT_SUFX = .zip
+MASTER_SITES = http://sizeofvoid.org/pub/OpenBSD/distfiles/
-NO_BUILD = Yes
-NO_TEST = Yes
+NO_BUILD = Yes
+NO_TEST = Yes
USE_X11 = Yes
FONTDIR= ${PREFIX}/lib/X11/fonts/dina
-WRKSRC = ${WRKDIR}/Dina-PCF
+WRKSRC = ${WRKDIST}/BDF
+
+do-extract:
+ mkdir -p ${WRKDIST}
+ unzip -oq -d ${WRKDIST} ${FULLDISTDIR}/${EXTRACT_ONLY}
+
do-install:
+ bdftopcf -t -o ${WRKSRC}/DinaItalic10.pcf ${WRKSRC}/Dina_i400-10.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaItalic8.pcf ${WRKSRC}/Dina_i400-8.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaItalic9.pcf ${WRKSRC}/Dina_i400-9.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaBoldItalic10.pcf ${WRKSRC}/Dina_i700-10.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaBoldItalic8.pcf ${WRKSRC}/Dina_i700-8.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaBoldItalic9.pcf ${WRKSRC}/Dina_i700-9.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaMedium10.pcf ${WRKSRC}/Dina_r400-10.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaMedium8.pcf ${WRKSRC}/Dina_r400-8.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaMedium9.pcf ${WRKSRC}/Dina_r400-9.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaMedium6.pcf ${WRKSRC}/Dina_r400-6.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaBold10.pcf ${WRKSRC}/Dina_r700-10.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaBold8.pcf ${WRKSRC}/Dina_r700-8.bdf
+ bdftopcf -t -o ${WRKSRC}/DinaBold9.pcf ${WRKSRC}/Dina_r700-9.bdf
${GZIP_CMD} ${WRKSRC}/*.pcf
${X11BASE}/bin/mkfontdir ${WRKSRC}
egrep '\.pcf\.gz' ${WRKSRC}/fonts.dir | \
@@ -34,5 +51,8 @@ do-install:
${INSTALL_DATA_DIR} ${FONTDIR}
${INSTALL_DATA} ${WRKSRC}/*.pcf.gz ${FONTDIR}
${INSTALL_DATA} ${WRKSRC}/fonts.alias ${FONTDIR}/fonts.alias-dina
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/dina-fonts
+ ${INSTALL_DATA} ${WRKDIST}/LICENSE ${PREFIX}/share/doc/dina-fonts
+
.include bsd.port.mk
Index: distinfo
===
RCS file: /cvs/ports/fonts/dina-fonts/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo7 Dec 2011 09:27:16 - 1.1.1.1
+++ distinfo2 Jan 2014 17:25:06 -
@@ -1,5 +1,2 @@
-MD5 (dina-pcf-2.89.tar.gz) = 1sQlwAeppXa0u4jIjPVwdg==
-RMD160 (dina-pcf-2.89.tar.gz) = bQLzN2RIzzKstI5LpGS3Pmc3Ek8=
-SHA1 (dina-pcf-2.89.tar.gz) = dw8YqDJJCiLMjKWfCS7EAe72uEA=
-SHA256 (dina-pcf-2.89.tar.gz) = KYnGi8Tm8xQ1/nwnMNluZO8xlLEiNl8p+vBsS6xwGaY=
-SIZE (dina-pcf-2.89.tar.gz) = 36442
+SHA256 (dina-fonts-2.92.zip) = H1G7pT91pk0ti9A36OD4S2+AZOUKcu6VQDO+3hc1CM8=
+SIZE (dina-fonts-2.92.zip) = 68023
Index: pkg/PLIST
===
RCS file: /cvs/ports/fonts/dina-fonts/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 7 Dec 2011 09:27:16 - 1.1.1.1
+++ pkg/PLIST 2 Jan 2014 17:25:06 -
@@ -1,6 +1,6 @@
-@comment $OpenBSD: PLIST,v 1.1.1.1 2011/12/07 09:27:16 jasper Exp $
+@comment $OpenBSD$
lib/X11/fonts/
-@fontdir lib/X11/fonts/dina/
+lib/X11/fonts/dina/
lib/X11/fonts/dina/DinaBold10.pcf.gz
lib/X11/fonts/dina/DinaBold8.pcf.gz
lib/X11/fonts/dina/DinaBold9.pcf.gz
@@ -11,6 +11,9 @@ lib/X11/fonts/dina/DinaItalic10.pcf.gz
lib/X11/fonts/dina/DinaItalic8.pcf.gz
lib/X11/fonts/dina/DinaItalic9.pcf.gz
lib/X11/fonts/dina/DinaMedium10.pcf.gz
+lib/X11/fonts/dina/DinaMedium6.pcf.gz
Re: waf woes
2014/1/2 Landry Breuil lan...@rhaalovely.net: On Thu, Jan 02, 2014 at 11:40:40PM +1100, Ian McWilliam wrote: On 1/01/2014 7:00 AM, Brad Smith wrote: snip Sadly enough autohell is the suck least of build infrastructure and there is a lot of documentation and knowledge regarding its inner workings. IMO not something that can be said about the other build infrastructure whether it is relatively common or not. It might not be m4, but it is python, that's a pretty heavy dependency for build infrastructure. Yup and any new samba + external samba deps is riddled with it. It's what is stopping me from moving forward atm. Need to learn python. At least I have a few weeks to pull out some python books. A newer in tree waf, or multiple versions would help ease the situation rather than patch the hell out of samba build infrastructure. I've moved away all waf users from it (ie x11/gigolo www/vteplugin) but i'd rather remove waf from the tree instead of having someone losing time on that crap. Given that it's clearly hostile to any packaging effort, why bother with it ? Just do the minimum and patch all the bundled copies. I'll learn jig to dance it on the WAF grave. -- WBR, Vadim Zhukov
Re: waf woes
I'll learn jig to dance it on the WAF grave. Can't wait to see that ;-) -- Antoine
Re: waf woes
hmm, on Thu, Jan 02, 2014 at 03:19:16PM +0100, Landry Breuil said that
I've moved away all waf users from it (ie x11/gigolo www/vteplugin)
but i'd rather remove waf from the tree instead of having someone losing
time on that crap. Given that it's clearly hostile to any packaging
effort, why bother with it ? Just do the minimum and patch all the
bundled copies.
i would bother with it because more and more projects
will go with it. it would be nice if all of them
bundled it (as its author advises) but that is not the
case. that is what my question was about.
should it be downloaded at compile time? i am no fan of
hidden online dependencies as i am offline quite a lot.
should it be included under files/? cvs will go crazy
with this hybrid file..
so i think a package that contains multiple needed
versions (patched so they would unpack their library
into ${WRKDIST}) is the least painful way to go. i am
working on that now, but it is not finished.
just by hating it it won't go away. none of the gnu
stuff did..
-f
--
how much can i get away with and still go to heaven?
Re: waf woes
On Thu, Jan 02, 2014 at 06:59:02PM +0100, frantisek holop wrote: hmm, on Thu, Jan 02, 2014 at 03:19:16PM +0100, Landry Breuil said that I've moved away all waf users from it (ie x11/gigolo www/vteplugin) but i'd rather remove waf from the tree instead of having someone losing time on that crap. Given that it's clearly hostile to any packaging effort, why bother with it ? Just do the minimum and patch all the bundled copies. i would bother with it because more and more projects will go with it. it would be nice if all of them bundled it (as its author advises) but that is not the case. that is what my question was about. How about you talk to those projects and tell them waf is a bad idea ? or do you want to be part of the problem ?
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 04:52:51PM +0100, Matthias Kilian wrote: On Wed, Jan 01, 2014 at 09:38:48PM +, Stuart Henderson wrote: devel/hasktags: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' devel/hs-ghc-paths: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' I'll update my i386 test installation and have a look. Until then, can you point me to the log files of those two? No more need for log files, I could reproduce the problem now and it's ghci (and runghc) which is broken. A quick workaround would be to (again) change lang/ghc/ghc.port.mk to compile the Setup.hs or Setup.lhs files instead of trying to interpret them. I'll give this a try, soon. However, ports loading hs-* libraries at runtime (like www/hs-snap-loader-dynamic) will not work on i386. Ciao Kili
amd64 bulk breakage 2014-01-01
Failures in the latest amd64 bulk build: textproc/redland-bindings swig: -php4 is no longer supported mail/zarafa/zarafa 'SWIG_From_long' was not declared in this scope x11/py-wxPython ld: cannot find -lwx_gtk2_media Logs on request. -- Christian naddy Weisgerber na...@mips.inka.de
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 02:58:55PM +0100, Landry Breuil wrote: On Thu, Jan 02, 2014 at 01:52:03PM +, Christian Weisgerber wrote: Stuart Henderson st...@openbsd.org wrote: Not sure about cause yet, some may be PIE-related too: These are not: lang/gcc/4.8: gcj: fatal error: can't specify '-D' without '--main' Sporadic build failure; also happens on amd64. mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. Also on amd64. Likely fallout from the devel/swig update a week ago. I Haven't seen them in the bulk build i ran with the swig update diff.. Hm, in fact i hadnt seen those failures because for some reason dpb didnt try building those pkgpaths for reasons unknown to me. Yay dpb. Landry
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 03:16:16PM +, Christian Weisgerber wrote:
Stuart Henderson st...@openbsd.org wrote:
lang/nhc98: segfaults in build
NOT_FOR_ARCHS= ${LP64_ARCHS} powerpc
BROKEN-hppa=Segfault during build since the PIE switch
Do we need this for bootstrapping or reference purposes or can we
just remove it?
lang/petite-chez: undefined reference to `__guard'
ONLY_FOR_ARCHS =i386
Hmm, FreeBSD has a port of 8.4 that at least adds amd64.
The license of Petite Chez is weird and the port is very outdated. We
have better scheme interpreters/compilers like gambit, chicken or
racket. So, ok juanfra@ if someone wants delete the port :)
Frankly, I would like to kill the remaining !LP64 and i386-only
ports. (Excluding such things as tpwireless.)
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 11:19:57PM +0100, Landry Breuil wrote: I Haven't seen them in the bulk build i ran with the swig update diff.. Hm, in fact i hadnt seen those failures because for some reason dpb didnt try building those pkgpaths for reasons unknown to me. Yay dpb. Surprisingly enough, it tries to build them here (amd64, like opi). You probably have something broken on your side. Wouldn't be the first time. As for reasons unknown to you, hey, look at the logs, check your patches. Figure out what you're doing different...
Re: JDK 1.6 Broken
On 1/1/2014 1:21 PM, Stuart Henderson wrote: Your current options are: - move to amd64. - move back to code from a month or two ago. If anyone is able to help track down the timeframe this got broken (or even pin it to a particular commit in base), that would be extremely helpful... I have rolled back to an early December snapshot and then built a new GENERIC kernel from a set of the source and ports trees that I downloaded at ~ 17:45 PST on 10 December. I then did fresh builds of the JDK 1.6 and 1.7 ports. My machine is now happily running Apache Solr without the dreaded threading error. Consequently, I would venture to say that 10 Dec. is the terminus post quem for when things went sideways. Not that it narrows the window significantly, but that's all I have to go on. Thanks.
Re: waf woes
hmm, on Thu, Jan 02, 2014 at 07:32:19PM +0100, Marc Espie said that
On Thu, Jan 02, 2014 at 06:59:02PM +0100, frantisek holop wrote:
hmm, on Thu, Jan 02, 2014 at 03:19:16PM +0100, Landry Breuil said that
I've moved away all waf users from it (ie x11/gigolo www/vteplugin)
but i'd rather remove waf from the tree instead of having someone losing
time on that crap. Given that it's clearly hostile to any packaging
effort, why bother with it ? Just do the minimum and patch all the
bundled copies.
i would bother with it because more and more projects
will go with it. it would be nice if all of them
bundled it (as its author advises) but that is not the
case. that is what my question was about.
How about you talk to those projects and tell them waf is a bad idea ?
or do you want to be part of the problem ?
i dont *know* if waf is a bad idea. have you tried
using it? or is it just because it's a python script
that prefers to be copied into the project dir?
why is it so bad? ports can cope with it. in the end it
just takes ${CONFIGURE_ARGS} just like autohell. and
it's not like it is alone in the package hostile club.
clearly it has some merit if some big projects switched
to it.
do you go around telling projects stop using insert
your favourite build system to hate? i can imagine
your answer if someone did the same for openbsd and/or
ports. it is nobody elses business what a project
uses. i am surprised you dont share this view.
and what do i tell them? please switch to autohell?
i wouldnt in my project.
as faithless sings if loving you is wrong, i dont want
to be right, if to be part of the solution is to
ignore/hate waf then i dont want to be part of it and
can be hardly called a solution in my eyes.
frankly, this is a storm in a teacup issue. i will send
the port shortly.
-f
--
i'm feeling rather blonde today.
