CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2012/03/07 01:38:44 Modified files: productivity/davical: Makefile productivity/davical/pkg: PLIST README Added files: productivity/davical/files: davical.conf productivity/davical/pkg: UNMESSAGE Log message: Be consistent with the other www ports and install a davical.conf file so that it works out of the box without the need to tweak httpd.conf. Add missing --dbpass to the update-davical-database example in README. ok landry@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2012/03/07 02:45:16 Modified files: mail/sympa : Makefile Added files: mail/sympa/pkg : UNMESSAGE Log message: Add UNMESSAGE telling how to properly completely uninstall sympa, otherwise httpd postfix/sendmail will barf at next restart.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2012/03/07 05:35:39 Modified files: telephony/pjsua: Makefile Removed files: telephony/pjsua/patches: patch-pjlib_src_pj_os_core_unix_c Log message: Zap incorrect patch. noticed by brad, thanks
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2012/03/07 06:14:27 Modified files: lang/lua : Makefile lang/lua/patches: patch-src_luaconf_h Removed files: lang/lua/patches: patch-src_lobject_c patch-src_lstrlib_c Log message: Remove local strlcpy/etc patches, we aren't generally patching these in ports any more (they should be addressed upstream instead) and at least some of them are wrong. This fixes a bug found by Piotr Sikora: http://permalink.gmane.org/gmane.os.openbsd.ports/53993
做 销 》售 要 有 强 烈 的 企 图 心— 成.功.的.欲.望-ecacrb
h/ N f bbe/d8 h=id?d90gbbf(bbeo f(bbf(h?d9ec h/7 b e8o d= f f/e;g o fd8 h?f/d8f6i,h?7e?g* h e72cb f9 f % b, i o e88e88h.)d::e$4fg h 1go fe d:e$)h.)g;e?e6d:d:hh 7i i e d:,ee. e)e=ig'h48f ie,e8 d;6 o [demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a name of ÏÈ¡°¿ªÇ¹¡±ºó¡°Ãé×¼¡±¡ª ¸ßЧִÐÐawl7.28685DEFANGED-xls]
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2012/03/07 13:22:04 Modified files: x11/gnome/libgweather: Makefile distinfo x11/gnome/libgweather/pkg: PLIST Log message: Update to libgweather-3.4.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2012/03/07 13:39:37 Modified files: lang/gcc/4.6 : Makefile lang/gcc/4.6/patches: patch-gcc_config_gcc Log message: enable __cxa_atexit. okay pascal@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2012/03/07 13:42:36 Modified files: security/libassuan: Makefile distinfo Log message: Update to 2.0.3 ok dcoppa@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2012/03/07 15:00:07 Modified files: www/youtube-dl : Makefile distinfo www/youtube-dl/patches: patch-youtube-dl Log message: update youtube-dl to 2012.02.27 ok sthen@
Re: NEW: games/eduke32 (again)
On Wednesday 07 March 2012 01:15:30 Ryan Freeman wrote:
Attached is the still-building port of eduke32 that I have
been sitting on for far too long. Antti Harri did most of
the initial work of getting fixes pushed upstream.
I have pulled a recent snapshot from their repos, and
as those are done daily, we may wish to wait for a real
release, if those happen. Here you go, Edd!
-ryan
Hi, I took a quick look at this. Was the port honoring CC for you?
Didn't seem to work for me. Anyway using MAKE_FLAGS is cleaner.
Removed the hard-coded optimizations and disabled debugging.
PS. The entry pointing to my dist site isn't working anymore because
it only contains the previous snapshot. Let me know if it's still needed
and I'll put the new one on my server where I have all the other distfiles.
--
Antti Harri
diff -uNr eduke32/Makefile /usr/ports/games/eduke32/Makefile
--- eduke32/MakefileWed Mar 7 01:01:18 2012
+++ /usr/ports/games/eduke32/Makefile Wed Mar 7 09:44:39 2012
@@ -41,7 +41,7 @@
3dduke13.zip:0
SEPERATE_BUILD = concurrent
-MAKE_FLAGS = PRETTY_OUTPUT=0 DEBUGANYWAY=1
+MAKE_FLAGS = PRETTY_OUTPUT=0 CC=${CC} CXX=${CXX}
USE_GMAKE =Yes
NO_REGRESS = Yes
diff -uNr eduke32/patches/patch-Makefile_common
/usr/ports/games/eduke32/patches/patch-Makefile_common
--- eduke32/patches/patch-Makefile_common Thu May 26 00:44:16 2011
+++ /usr/ports/games/eduke32/patches/patch-Makefile_common Wed Mar 7
09:48:33 2012
@@ -1,15 +1,11 @@
$OpenBSD$
-
-Make build honor CC
-
Makefile.common.orig Wed May 25 10:52:37 2011
-+++ Makefile.commonWed May 25 10:53:18 2011
-@@ -56,8 +56,6 @@ endif
+--- Makefile.common.orig Wed Mar 7 09:48:09 2012
Makefile.commonWed Mar 7 09:48:29 2012
+@@ -89,7 +89,6 @@ endif
-
- # Tools
--CC=gcc
--CXX=g++
- AS=nasm
- AR=ar
- RC=windres
+ ifneq (0,$(RELEASE))
+ # Debugging disabled
+-debug+= -O$(OPTLEVEL)
+ ifneq ($(CC),clang)
+ debug+= -funswitch-loops
+ endif
diff -uNr eduke32/patches/patch-build_src_glbuild_c
/usr/ports/games/eduke32/patches/patch-build_src_glbuild_c
--- eduke32/patches/patch-build_src_glbuild_c Thu May 26 00:45:35 2011
+++ /usr/ports/games/eduke32/patches/patch-build_src_glbuild_c Wed Mar 7
09:45:40 2012
@@ -3,9 +3,9 @@
allow dlopen to find our libGL.so, falling back to libGL.so.1 for
linux or others.
build/src/glbuild.c.orig Sat Jan 15 18:50:27 2011
-+++ build/src/glbuild.cWed May 25 11:28:36 2011
-@@ -330,6 +330,8 @@ int32_t loadgldriver(const char *driver)
+--- build/src/glbuild.c.orig Tue Oct 11 19:52:53 2011
build/src/glbuild.cWed Mar 7 09:45:03 2012
+@@ -338,6 +338,8 @@ int32_t loadgldriver(const char *driver)
driver = opengl32.dll;
#elif defined __APPLE__
driver = /System/Library/Frameworks/OpenGL.framework/OpenGL;
@@ -14,7 +14,7 @@
#else
driver = libGL.so.1;
#endif
-@@ -921,6 +923,8 @@ int32_t loadglulibrary(const char *driver)
+@@ -936,6 +938,8 @@ int32_t loadglulibrary(const char *driver)
driver = glu32.dll;
#elif defined __APPLE__
driver = /System/Library/Frameworks/OpenGL.framework/OpenGL; //
FIXME: like I know anything about Apple. Hah.
Re: NEW: games/eduke32 (again)
On Wed, Mar 07, 2012 at 09:58:21AM +0200, Antti Harri wrote: On Wednesday 07 March 2012 01:15:30 Ryan Freeman wrote: Attached is the still-building port of eduke32 that I have been sitting on for far too long. Antti Harri did most of the initial work of getting fixes pushed upstream. I have pulled a recent snapshot from their repos, and as those are done daily, we may wish to wait for a real release, if those happen. Here you go, Edd! -ryan Hi, I took a quick look at this. Was the port honoring CC for you? Didn't seem to work for me. Anyway using MAKE_FLAGS is cleaner. Removed the hard-coded optimizations and disabled debugging. This game is serious fun. I'm still seeing a lot of '-fomgz-so-fast': === Building for eduke32-2.0.0.2394 if cc -O2 -pipe -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -W -Wall -Wimplicit -Werror-implicit-function-declaration -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wextra -Wstrict-overflow=1 -DUSE_LIBVPX -Isource -Ibuild/include -Isource/jmact -Isource/jaudiolib/include -Isource/enet/include -I/usr/local/include -I/usr/local/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/X11R6/include -DXTHREADS -DHAVE_GTK2 -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/pango-1.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/X11R6/include -I/usr/local/include/cairo -I/usr/local/include/atk-1.0 -I/usr/X11R6/include/pixman-1 -I/usr/include/dev/pci/drm -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R6/include/freetype2 -DHAVE_INTTYPES -DRENDERTYPESDL=1 -DUSE_OPENGL -DNOASM -DPOLYMER -c source/game.c -o obj/game.o; then true; else false; exit 1; fi The other thing I wonder, should the data be a separate port, like it is for doom? -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
[update] libassuan
Hi, Small diff to update libassuan. Tested on @amd64 with rthreads. ok ? Regards, -- Pierre-Emmanuel André pea at raveland.org GPG key: 0x7AE329DC Index: Makefile === RCS file: /cvs/ports/security/libassuan/Makefile,v retrieving revision 1.8 diff -u -p -r1.8 Makefile --- Makefile6 Jul 2011 15:03:13 - 1.8 +++ Makefile7 Mar 2012 15:45:00 - @@ -2,7 +2,7 @@ COMMENT= IPC library used by GnuPG and gpgme -DISTNAME= libassuan-2.0.2 +DISTNAME= libassuan-2.0.3 SHARED_LIBS += assuan1.0 # 2.0 Index: distinfo === RCS file: /cvs/ports/security/libassuan/distinfo,v retrieving revision 1.5 diff -u -p -r1.5 distinfo --- distinfo6 Jul 2011 15:03:13 - 1.5 +++ distinfo7 Mar 2012 15:45:00 - @@ -1,5 +1,5 @@ -MD5 (libassuan-2.0.2.tar.bz2) = Pn0A/S7ooLnFGsdhbvPx7A== -RMD160 (libassuan-2.0.2.tar.bz2) = e6ATjYPyQto/0uuub53u9jgzKaY= -SHA1 (libassuan-2.0.2.tar.bz2) = 282W4lJdTDotqegFSgb6UX8goYU= -SHA256 (libassuan-2.0.2.tar.bz2) = YeDLoz3LreLc6VO5Xwa4Q68qc96HUwPyWFIn7NR1tNg= -SIZE (libassuan-2.0.2.tar.bz2) = 491172 +MD5 (libassuan-2.0.3.tar.bz2) = F50ZGDJf25KMe9kLilFPxw== +RMD160 (libassuan-2.0.3.tar.bz2) = JD0vWejY/0h1rLV/9uY6Rm8rdXQ= +SHA1 (libassuan-2.0.3.tar.bz2) = K/Tro7WIdY40mXan656KUJlgw7U= +SHA256 (libassuan-2.0.3.tar.bz2) = utVoI3THa8wKuxp6NMlVevaHSkd1AHSOZKfT3vecrBs= +SIZE (libassuan-2.0.3.tar.bz2) = 529149
Re: NEW: games/eduke32 (again)
On Wed, Mar 7, 2012 at 12:15 AM, Ryan Freeman r...@slipgate.org wrote: Attached is the still-building port of eduke32 that I have been sitting on for far too long. Antti Harri did most of the initial work of getting fixes pushed upstream. I have pulled a recent snapshot from their repos, and as those are done daily, we may wish to wait for a real release, if those happen. Here you go, Edd! Duke Nukem 3D... How many memories! I will try this port asap. cheers, David
Re: [update] libassuan
On Wed, Mar 7, 2012 at 4:46 PM, Pierre-Emmanuel André p...@raveland.org wrote: Hi, Small diff to update libassuan. Tested on @amd64 with rthreads. ok ? sure. ok for me ciao, David
NEW: net/weechat
Hi ports -- pkg/DESCR WeeChat is a fast, light and extensible chat client. It runs on many platforms (including Linux, BSD and Mac OS). I've been using this as my IRC client for a few months. Works for me on amd64 and loongson. I'm sure my do-install and post-install routines could be cleaner, but I'm unsure of the variables needed to make it cleaner. Comments/OK? Thanks. ~Brian weechat.tar.gz Description: application/gzip
[Update] Vnstat-1.11
Hi, Update for Vnstat to 1.11. Comments, Ok? Cheers. -- Sending from my VCR vnstat-1.11.diff Description: Binary data
[Update] ntop
Hi, A little update for ntop. Comments, Ok? Cheers. -- Sending from my VCR ntop-1.1p1.diff Description: Binary data
Re: Remove libao plugin's write_size constraint from mpd
On Mon, Mar 05, 2012 at 11:04:00AM +0100, David Coppa wrote: I'd like to remove this write_size constraint, as suggested by jakemsr@ some time ago: afaiu, removing it is desirable, but might be tricky (see below). Does removing it improve stability? http://marc.info/?l=openbsd-portsm=128630571914847 http://marc.info/?l=openbsd-portsm=128630890119517 As jake said, 1024 bytes is only 256 samples of 16-bit stereo. At 44.1kHz, that's only 5.8 miliseconds. If mpd takes more than 5.8 ms between writes, for whatever reason, it will skip. So, this represents a performance penalty on fast machines and afaik sndiod should already cope with eventual stuffups just fine on slower ones... Alexandre, what do you think about this? Is it reasonable? write() blocks until the last byte of the chuck is stored in the device buffer. If the chuck is very large then write() will block for very long and the program will idle instead of decoding more data; in this case, the program doesn't use the cpu optimally which may cause drops on slow or busy systems. So it's more efficient to write small chuncks of audio, ideally a small multiple of the device block size. Unfortunately, libao doesn't expose the device block size, afaiu that's why mpd lets the user enter it manually. Using a small chuck like 1024, should make mpd work on most setups. I see no elegant fix that wouldn't involve libao api change or switching to another backend. -- Alexandre
UPDATE: games/chocolate-doom
I have had this sitting around for about a year, this
patch cleans up this port by removing the need for the patches,
instead opting to use some perl.
it also fixes the port correctly ignoring python.
I am unsure if the revision bump is required, as the resulting
packing list is exactly the same.
comments/ok?
-ryan
Index: Makefile
===
RCS file: /cvs/ports/games/chocolate-doom/Makefile,v
retrieving revision 1.10
diff -u -p -u -r1.10 Makefile
--- Makefile24 May 2011 00:11:48 - 1.10
+++ Makefile7 Mar 2012 04:11:26 -
@@ -2,6 +2,7 @@
COMMENT = portable version of iD Software's Doom
DISTNAME = chocolate-doom-1.6.0
+REVISION = 0
CATEGORIES = games x11
HOMEPAGE = http://www.chocolate-doom.org/
@@ -28,14 +29,23 @@ USE_GROFF = Yes
USE_GMAKE =Yes
CONFIGURE_STYLE = gnu
-CONFIGURE_ARGS += --without-python
-MAN_5= chocolate-doom.cfg default.cfg
-MAN_6= chocolate-doom chocolate-server chocolate-setup
+# we don't need to require python to build
+CONFIGURE_ENV += HAVE_PYTHON=false
+
+MAN_5 =chocolate-doom.cfg default.cfg
+MAN_6 =chocolate-doom chocolate-server chocolate-setup
+
+post-extract:
+ # set correct bin directory and data directory
+ @perl -pi -e s,/games,/bin, ${WRKSRC}/src/Makefile.in
+ @perl -pi -e s,/games,/bin, ${WRKSRC}/setup/Makefile.in
+ @perl -pi -e s,/usr/share/games/doom,${TRUEPREFIX}/share/doom, \
+ ${WRKSRC}/src/d_iwad.c
post-install:
# Data files get installed to this directory.
- ${INSTALL_DATA_DIR} ${PREFIX}/share/games/doom/
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/doom/
.for m in ${MAN_5}
${INSTALL_MAN} ${WRKBUILD}/man/$m.5 ${PREFIX}/man/man5/
.endfor
Index: patches/patch-setup_Makefile_in
===
RCS file: patches/patch-setup_Makefile_in
diff -N patches/patch-setup_Makefile_in
--- patches/patch-setup_Makefile_in 13 Jan 2011 10:30:49 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-setup_Makefile_in,v 1.3 2011/01/13 10:30:49 jasper Exp $
setup/Makefile.in.orig Sun Jan 2 10:17:16 2011
-+++ setup/Makefile.in Tue Jan 11 12:40:52 2011
-@@ -181,7 +181,7 @@ target_alias = @target_alias@
- top_build_prefix = @top_build_prefix@
- top_builddir = @top_builddir@
- top_srcdir = @top_srcdir@
--gamesdir = $(prefix)/games
-+gamesdir = $(prefix)/bin
- AM_CFLAGS = -I../textscreen -I../src @SDLMIXER_CFLAGS@
- SOURCE_FILES = \
- compatibility.c compatibility.h \
Index: patches/patch-src_Makefile_in
===
RCS file: patches/patch-src_Makefile_in
diff -N patches/patch-src_Makefile_in
--- patches/patch-src_Makefile_in 13 Jan 2011 10:30:49 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src_Makefile_in,v 1.3 2011/01/13 10:30:49 jasper Exp $
src/Makefile.in.orig Sun Jan 2 10:17:17 2011
-+++ src/Makefile.inTue Jan 11 12:41:03 2011
-@@ -252,7 +252,7 @@ target_alias = @target_alias@
- top_build_prefix = @top_build_prefix@
- top_builddir = @top_builddir@
- top_srcdir = @top_srcdir@
--gamesdir = $(prefix)/games
-+gamesdir = $(prefix)/bin
- AM_CFLAGS = -I../opl -I../textscreen -I../pcsound @SDLMIXER_CFLAGS@
@SDLNET_CFLAGS@
- DEDSERV_FILES = \
- d_dedicated.c \
Index: pkg/MESSAGE
===
RCS file: /cvs/ports/games/chocolate-doom/pkg/MESSAGE,v
retrieving revision 1.3
diff -u -p -u -r1.3 MESSAGE
--- pkg/MESSAGE 24 May 2011 00:11:48 - 1.3
+++ pkg/MESSAGE 7 Mar 2012 04:11:26 -
@@ -1,6 +1,7 @@
To play the game you will need an original Doom, Ultimate Doom, Doom II
or Final Doom IWAD. Place the doom.wad, doom2.wad, plutonia.wad,
-tnt.wad, or all of the above in ${PREFIX}/share/games/doom/ to play.
+tnt.wad, or all of the above in ${PREFIX}/share/doom/ to play.
+
If multiple IWADs are installed, you may specify the one you want to
play via the -iwad command-line parameter e.g.
@@ -9,7 +10,3 @@ play via the -iwad command-line paramete
The Shareware IWAD is available in the doomdata package.
Run `chocolate-setup' to generate a configuration file to your liking.
-If you would like to enjoy the classic in-game Doom music, you may
-install audio/timidity and Chocolate Doom will automatically make use
-of it at runtime, no recompilation required. Be sure that the music is
-enabled within chocolate-setup.
Index: pkg/PLIST
===
RCS file: /cvs/ports/games/chocolate-doom/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -u -r1.2 PLIST
--- pkg/PLIST 24 May 2011 00:11:48 - 1.2
+++ pkg/PLIST 7 Mar 2012 04:11:26 -
@@ -18,8 +18,7 @@
Re: sox-14.4.0 - mandoc glitches
Hi Jan, Jan Stary wrote on Mon, Mar 05, 2012 at 04:46:26PM +0100: Attached is a port of audio/sox, bringing it to 14.4.0. Tested on i386 and amd. make package complains: warning: file `man1/sox.1', around line 2667: table wider than line width grotty:standard input (man1/sox.1):47303: character above first line discarded These are *not* mandoc(1) glitches, but groff error messages produced by grotty(1). Indeed, sox.1 includes this table that is too wide. What do? Shall I persuade upstream to wrap the lines to make mandoc happy? Or provide a patch? (That would be a good excuse to finally learn the man(doc) syntax.) Please don't, this is a tricky case and not the right place to start learning man(7) and tbl(7). Don't try to talk to upstream about so difficult stuff; making good recommendations upstream requires thorough knowledge in this case, which you don't appear to have yet. These pages exhibit groff bugs, mandoc bugs *and* questionable formatting - to talk to upstream, you must be able to tell apart the three classes of problems, or you would cause more confusion than help. Since groff(1) actually wraps the tables better than mandoc(1), even though it complains, i suggest to keep USE_GROFF and simply ignore the groff warnings in this particular case. Yours, Ingo
Re: sox-14.4.0 update
On Mar 07 23:13:57, Ingo Schwarze wrote: warning: file `man1/sox.1', around line 2667: table wider than line width grotty:standard input (man1/sox.1):47303: character above first line discarded These are *not* mandoc(1) glitches, but groff error messages produced by grotty(1). Sorry; by this unfortunate wording, I didn't mean that these are glitches of mandoc itself of course. What do? Shall I persuade upstream to wrap the lines to make mandoc happy? Or provide a patch? (That would be a good excuse to finally learn the man(doc) syntax.) Please don't, this is a tricky case and not the right place to start learning man(7) and tbl(7). Don't try to talk to upstream about so difficult stuff; making good recommendations upstream requires thorough knowledge in this case, which you don't appear to have yet. Exactly; I was hoping to get an attention of someone man/mandoc/groff-savvy. These pages exhibit groff bugs, mandoc bugs *and* questionable formatting - to talk to upstream, you must be able to tell apart the three classes of problems, or you would cause more confusion than help. Since groff(1) actually wraps the tables better than mandoc(1), even though it complains, i suggest to keep USE_GROFF and simply ignore the groff warnings in this particular case. OK. Thanks for the insight. So, appart from this: any comments to the port update? Jan
Re: UPDATE: QEMU 1.0.1
On Fri, Feb 24, 2012 at 8:02 PM, Brad Smith b...@comstyle.com wrote:
Here is an update to QEMU 1.0.1.
anyone tested this?
come on, don't cry later. you know who you are.
f.-
Index: Makefile
===
RCS file: /home/cvs/ports/emulators/qemu/Makefile,v
retrieving revision 1.84
diff -u -p -r1.84 Makefile
--- Makefile 2 Feb 2012 22:07:33 - 1.84
+++ Makefile 24 Feb 2012 20:01:07 -
@@ -1,14 +1,13 @@
# $OpenBSD: Makefile,v 1.84 2012/02/02 22:07:33 sthen Exp $
-ONLY_FOR_ARCHS= amd64 i386 mips64 mips64el powerpc sparc sparc64
+ONLY_FOR_ARCHS= amd64 arm hppa i386 mips64 mips64el powerpc sparc
sparc64
+BROKEN-hppa= compiler bug with gcc 4.2
COMMENT= multi system emulator
-DISTNAME= qemu-1.0
-REVISION= 1
+DISTNAME= qemu-1.0.1
CATEGORIES= emulators
-MASTER_SITES= http://wiki.qemu.org/download/ \
- http://comstyle.com/source/
+MASTER_SITES= http://wiki.qemu.org/download/
HOMEPAGE= http://www.qemu.org/
Index: distinfo
===
RCS file: /home/cvs/ports/emulators/qemu/distinfo,v
retrieving revision 1.18
diff -u -p -r1.18 distinfo
--- distinfo 12 Dec 2011 10:56:56 - 1.18
+++ distinfo 17 Feb 2012 20:59:39 -
@@ -1,5 +1,5 @@
-MD5 (qemu-1.0.tar.gz) = pks2BnoZFFEyOw0067RJVA==
-RMD160 (qemu-1.0.tar.gz) = OmCu9s/rumiWvbEsmVJdpUVhcv0=
-SHA1 (qemu-1.0.tar.gz) = fcsbNRZVTW2JnXSIzURNu3ch/O4=
-SHA256 (qemu-1.0.tar.gz) = R2dLfaVZ1eG0TMQBr5rFrZYtFOnu3hJWexPkuEGYlzc=
-SIZE (qemu-1.0.tar.gz) = 10848714
+MD5 (qemu-1.0.1.tar.gz) = Xv0QkfAeO8Mb/ewnuO3rAA==
+RMD160 (qemu-1.0.1.tar.gz) = 3O80TxUOI4iAhxdo8vB8y26OzOc=
+SHA1 (qemu-1.0.1.tar.gz) = TQi1qDU4/NeyIr7G8cWE2o0SSXo=
+SHA256 (qemu-1.0.1.tar.gz) = GYkC4QeCUX9gfJ7Z5im153COo56zc+0+w/HIoWnZg3g=
+SIZE (qemu-1.0.1.tar.gz) = 10853005
Index: patches/patch-configure
===
RCS file: /home/cvs/ports/emulators/qemu/patches/patch-configure,v
retrieving revision 1.21
diff -u -p -r1.21 patch-configure
--- patches/patch-configure 12 Dec 2011 10:56:56 - 1.21
+++ patches/patch-configure 17 Feb 2012 21:03:10 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-configure,v 1.21 2011/12/12 10:56:56 sthen Exp $
configure.orig Mon Nov 28 17:22:15 2011
-+++ configure Mon Nov 28 18:32:45 2011
+--- configure.orig Fri Feb 17 14:45:39 2012
configure Fri Feb 17 16:02:57 2012
@@ -235,13 +235,11 @@ sdl_config=${SDL_CONFIG-${cross_prefix}sdl-config}
# default flags for all hosts
@@ -15,15 +15,6 @@ $OpenBSD: patch-configure,v 1.21 2011/12
# make source path absolute
source_path=`cd $source_path; pwd`
-@@ -1116,7 +1114,7 @@ fi
-
- if test $pie = ; then
- case $cpu-$targetos in
-- i386-Linux|x86_64-Linux)
-+ i386-Linux|x86_64-Linux|i386-OpenBSD|x86_64-OpenBSD)
- ;;
- *)
- pie=no
@@ -2684,8 +2682,9 @@ fi
# End of CC checks
# After here, no more $cc or $ld runs
Index: patches/patch-hw_e1000_c
===
RCS file: patches/patch-hw_e1000_c
diff -N patches/patch-hw_e1000_c
--- patches/patch-hw_e1000_c 2 Feb 2012 22:07:33 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,26 +0,0 @@
-$OpenBSD: patch-hw_e1000_c,v 1.4 2012/02/02 22:07:33 sthen Exp $
-
-Bounds packet size against buffer size, otherwise we can write beyond
-the buffer and corrupt memory. CVE-2012-0029.
-
-http://git.qemu.org/?p=qemu.git;a=commitdiff;h=65f82df0d7a71ce1b10cd4c5ab0d176ac840
-
hw/e1000.c.orig Thu Feb 2 20:07:37 2012
-+++ hw/e1000.c Thu Feb 2 20:11:43 2012
-@@ -466,6 +466,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *d
- bytes = split_size;
- if (tp-size + bytes msh)
- bytes = msh - tp-size;
-+
-+ bytes = MIN(sizeof(tp-data) - tp-size, bytes);
- pci_dma_read(s-dev, addr, tp-data + tp-size, bytes);
- if ((sz = tp-size + bytes) = hdr tp-size hdr)
- memmove(tp-header, tp-data, hdr);
-@@ -481,6 +483,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *d
- // context descriptor TSE is not set, while data descriptor TSE is
set
- DBGOUT(TXERR, TCP segmentaion Error\n);
- } else {
-+ split_size = MIN(sizeof(tp-data) - tp-size, split_size);
- pci_dma_read(s-dev, addr, tp-data + tp-size, split_size);
- tp-size += split_size;
- }
Index: patches/patch-target-i386_translate_c
===
RCS file: patches/patch-target-i386_translate_c
diff -N patches/patch-target-i386_translate_c
--- patches/patch-target-i386_translate_c 12 Dec 2011 10:56:56 -
1.6
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,32
Re: UPDATE: QEMU 1.0.1
On Wed, Mar 07, 2012 at 10:39:25PM +, Federico Schwindt wrote: On Fri, Feb 24, 2012 at 8:02 PM, Brad Smith b...@comstyle.com wrote: Here is an update to QEMU 1.0.1. anyone tested this? come on, don't cry later. you know who you are. on amd64 it segfaults and generally doesn't work with rthreads. qemu-system-x86_64 -m 64 Floating point exception (core dumped) trace has no symbols, can look into it some more over the weekend
Re: UPDATE: QEMU 1.0.1
On 07/03/12 5:54 PM, Jonathan Gray wrote: On Wed, Mar 07, 2012 at 10:39:25PM +, Federico Schwindt wrote: On Fri, Feb 24, 2012 at 8:02 PM, Brad Smithb...@comstyle.com wrote: Here is an update to QEMU 1.0.1. anyone tested this? come on, don't cry later. you know who you are. on amd64 it segfaults and generally doesn't work with rthreads. Strange. All I use is amd64 and it runs fine for me. If you build both 1.0 and 1.0.1 on the same system do both versions exhibit the same behavior? qemu-system-x86_64 -m 64 Floating point exception (core dumped) I have seen a crash like this with a particular test with VLC which is fully reproducible. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
