UPDATE: archivers/rzip

2007-01-01 Thread Lawrence Teo 

This diff updates rzip to 2.1. Here's the author's changelog:

- Added -L compression level option
- minor portability fixes
- fixed a bug that could cause some files to not be able to be uncompressed

I've also changed my email address in the port.

Only tested on i386, so would appreciate testing on other platforms.

Thanks,
Lawrence

--
Lawrence Teo
Calyptix Security
[EMAIL PROTECTED]
http://www.calyptix.com/
Index: Makefile
===
RCS file: /cvs/ports/archivers/rzip/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- Makefile	14 Feb 2006 10:18:37 -	1.3
+++ Makefile	1 Jan 2007 23:38:27 -
@@ -2,12 +2,12 @@
 
 COMMENT=	"file compressor with a high compression ratio"
 
-DISTNAME=	rzip-2.0
-PKGNAME=	${DISTNAME}p0
+DISTNAME=	rzip-2.1
+PKGNAME=	${DISTNAME}
 CATEGORIES=	archivers
 HOMEPAGE=	http://rzip.samba.org/
 
-MAINTAINER=	Lawrence Teo <[EMAIL PROTECTED]>
+MAINTAINER=	Lawrence Teo <[EMAIL PROTECTED]>
 
 # GPL
 PERMIT_PACKAGE_CDROM=	Yes
Index: distinfo
===
RCS file: /cvs/ports/archivers/rzip/distinfo,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 distinfo
--- distinfo	30 Mar 2005 00:02:08 -	1.1.1.1
+++ distinfo	1 Jan 2007 23:38:27 -
@@ -1,4 +1,4 @@
-MD5 (rzip-2.0.tar.gz) = 8a88b445afba919b122a3899d6d26b2a
-RMD160 (rzip-2.0.tar.gz) = a3bc1bb5afe9025ec53cc03bf5f55d65728c0529
-SHA1 (rzip-2.0.tar.gz) = 65d3d95689d14a6fb3b7c805768bf34868de5c17
-SIZE (rzip-2.0.tar.gz) = 42699
+MD5 (rzip-2.1.tar.gz) = 0a3ba55085661647c12f2b014c51c406
+RMD160 (rzip-2.1.tar.gz) = 7ef5299cd526c8c49a779e050ad515a53180c1c5
+SHA1 (rzip-2.1.tar.gz) = efeafc7a5bdd7daa0cea8d797ff21aa28bdfc8d9
+SIZE (rzip-2.1.tar.gz) = 46785
Index: patches/patch-main_c
===
RCS file: /cvs/ports/archivers/rzip/patches/patch-main_c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 patch-main_c
--- patches/patch-main_c	30 Mar 2005 00:02:08 -	1.1.1.1
+++ patches/patch-main_c	1 Jan 2007 23:38:27 -
@@ -1,7 +1,7 @@
-$OpenBSD: patch-main_c,v 1.1.1.1 2005/03/30 00:02:08 naddy Exp $
 main.c.orig	Thu Feb 12 01:01:08 2004
-+++ main.c	Tue Mar 29 22:53:26 2005
-@@ -50,7 +50,7 @@ static void write_magic(int fd_in, int f
+$OpenBSD$
+--- main.c.orig	Mon Feb 13 19:38:23 2006
 main.c	Mon Jan  1 18:26:21 2007
+@@ -51,7 +51,7 @@ static void write_magic(int fd_in, int f
  	uint32_t v;
  
  	memset(magic, 0, sizeof(magic));
@@ -10,11 +10,7 @@
  	magic[4] = RZIP_MAJOR_VERSION;
  	magic[5] = RZIP_MINOR_VERSION;
  
-@@ -127,9 +127,13 @@ static void decompress_file(struct rzip_
- {
- 	int fd_in, fd_out = -1, fd_hist = -1;
- 	off_t expected_size;
-+	size_t n;
+@@ -131,6 +131,9 @@ static void decompress_file(struct rzip_
  
  	if (control->outname) {
  		control->outfile = strdup(control->outname);
@@ -24,23 +20,17 @@
  	} else {
  		if (strlen(control->suffix) >= strlen(control->infile) ||
  		strcmp(control->suffix, 
-@@ -138,9 +142,12 @@ static void decompress_file(struct rzip_
- 			fatal("%s: unknown suffix\n", control->infile);
+@@ -140,6 +143,9 @@ static void decompress_file(struct rzip_
  		}
  		
--		control->outfile = strndup(control->infile, 
--	   strlen(control->infile) - 
--	   strlen(control->suffix));
-+		n = strlen(control->infile) - strlen(control->suffix) + 1;
-+		control->outfile = malloc(n);
+ 		control->outfile = strdup(control->infile);
 +		if (control->outfile == NULL) {
 +			fatal("Failed to allocate memory for output filename");
 +		}
-+		strlcpy(control->outfile, control->infile, n);
+ 		control->outfile[strlen(control->infile) - strlen(control->suffix)] = 0;
  	}
  
- 	fd_in = open(control->infile,O_RDONLY);
-@@ -208,6 +215,9 @@ static void compress_file(struct rzip_co
+@@ -208,14 +214,19 @@ static void compress_file(struct rzip_co
  
  	if (control->outname) {
  		control->outfile = strdup(control->outname);
@@ -48,5 +38,19 @@
 +			fatal("Failed to allocate memory for output filename");
 +		}
  	} else {
- 		asprintf(&control->outfile, "%s%s", control->infile, control->suffix);
+-		control->outfile = malloc(strlen(control->infile) + 
+-	  strlen(control->suffix) + 1);
++		size_t len;
++
++		len = strlen(control->infile) + strlen(control->suffix) + 1;
++		control->outfile = malloc(len);
+ 		if (!control->outfile) {
+ 			fatal("Failed to allocate outfile name\n");
+ 		}
+-		strcpy(control->outfile, control->infile);
+-		strcat(control->outfile, control->suffix);
++		strlcpy(control->outfile, control->infile, len);
++		strlcat(control->outfile, control->suffix, len);
  	}
+ 
+ 	fd_in = open(control->infile,O_RDONLY);

Re: on current, Xvnc core dumps on amd64 (with an intel dual core

2007-01-01 Thread Travers Buda 
On Mon, 1 Jan 2007 23:38:47 +0200
Nikns Siankin <[EMAIL PROTECTED]> wrote:

> 
> No. I have amd64 box without any duals cores...
> Port is broken for amd64. There are a lot of *bugreports*
> on misc@ about this port.
> 

It works great for me on -current with an _athlon 64 clawhammer_. What hardware 
are you running, Nikns? Intel, AMD...?

Travers Buda

patch: audio/ncmpc

2007-01-01 Thread Tobias Ulmer 
There is no common character encoding for ID3 tags, anything that is not
compatible with UTF-8 or ASCII results in an error message with ncmpc.
This diff fixes the ugly "Unable to convert.." message by using a glib
funktion that replaces broken chars with '?'.

Index: Makefile
===
RCS file: /cvs/ports/audio/ncmpc/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- Makefile16 Dec 2006 12:22:32 -  1.4
+++ Makefile2 Jan 2007 01:01:21 -
@@ -6,6 +6,7 @@
 COMMENT=   "curses based frontend for mpd"
 
 DISTNAME=  ncmpc-0.11.1
+PKGNAME=   ${DISTNAME}p0
 CATEGORIES=audio
 
 HOMEPAGE=  http://hem.bredband.net/kaw/ncmpc/
Index: patches/patch-src_support_c
===
RCS file: patches/patch-src_support_c
diff -N patches/patch-src_support_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_support_c 2 Jan 2007 01:01:21 -
@@ -0,0 +1,15 @@
+--- src/support.c.orig Sun Jan 23 18:37:41 2005
 src/support.c  Tue Jan  2 01:53:34 2007
+@@ -156,10 +156,8 @@
+   rb = 0; /* bytes read */
+   wb = 0; /* bytes written */
+   error = NULL;
+-  str=g_locale_from_utf8(utf8str, 
+-   strlen(utf8str),
+-   &wb, &rb,
+-   &error);
++  str = g_convert_with_fallback(
++  utf8str, -1, "ASCII", "UTF-8", "?", &rb, &wb, &error);
+   if( error )
+ {
+   const char *charset;


-- 
Gnu's Not Useful

patch: print/ghostscript/gnu

2007-01-01 Thread Matthias Kilian 
The patch below fixes some pdfwrite problems for ghostscript and
the LuxiMono fonts in /usr/X11R6/lib/X11/fonts/TTF.

See also http://bugs.ghostscript.com/show_bug.cgi?id=688536

Please test and let me know about any regressions.

Ciao,
Kili

Index: print/ghostscript/gnu/patches/patch-src_gdevpsft_c
===
RCS file: print/ghostscript/gnu/patches/patch-src_gdevpsft_c
diff -N print/ghostscript/gnu/patches/patch-src_gdevpsft_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ print/ghostscript/gnu/patches/patch-src_gdevpsft_c  1 Jan 2007 23:20:18 
-
@@ -0,0 +1,54 @@
+$OpenBSD$
+
+# Fix for bug 688536. From upstream svn.
+
+--- src/gdevpsft.c.origThu Mar 23 13:39:23 2006
 src/gdevpsft.c Mon Jan  1 19:42:31 2007
+@@ -479,7 +479,8 @@ write_name(stream *s, const gs_const_str
+ /* -- OS/2 -- */
+ 
+ /* Write a generated OS/2 table. */
+-#define OS_2_LENGTH sizeof(ttf_OS_2_t)
++#define OS_2_LENGTH1 offset_of(ttf_OS_2_t, sxHeight[0]) /* OS/2 version 1. */
++#define OS_2_LENGTH2 sizeof(ttf_OS_2_t) /* OS/2 version 2. */
+ private void
+ update_OS_2(ttf_OS_2_t *pos2, uint first_glyph, int num_glyphs)
+ {
+@@ -504,15 +505,16 @@ write_OS_2(stream *s, gs_font *font, uin
+  * We don't bother to set most of the fields.  The really important
+  * ones, which affect character mapping, are usFirst/LastCharIndex.
+  * We also need to set usWeightClass and usWidthClass to avoid
+- * crashing ttfdump.
++ * crashing ttfdump. Version 1 86-byte structure has all the fields
++ * we need.
+  */
+ memset(&os2, 0, sizeof(os2));
+ put_u16(os2.version, 1);
+ put_u16(os2.usWeightClass, 400); /* Normal */
+ put_u16(os2.usWidthClass, 5); /* Normal */
+ update_OS_2(&os2, first_glyph, num_glyphs);
+-stream_write(s, &os2, sizeof(os2));
+-put_pad(s, sizeof(os2));
++stream_write(s, &os2, offset_of(ttf_OS_2_t, sxHeight[0]));
++put_pad(s, offset_of(ttf_OS_2_t, sxHeight[0]));
+ }
+ 
+ /* -- post -- */
+@@ -688,7 +690,7 @@ psf_write_truetype_data(stream *s, gs_fo
+ int have_hvhea[2];
+ uint cmap_length = 0;
+ ulong OS_2_start = 0;
+-uint OS_2_length = OS_2_LENGTH;
++uint OS_2_length = OS_2_LENGTH1;
+ int code;
+ 
+ have_hvhea[0] = have_hvhea[1] = 0;
+@@ -755,7 +757,7 @@ psf_write_truetype_data(stream *s, gs_fo
+   if (writing_cid)
+   continue;
+   have_OS_2 = true;
+-  if (length > OS_2_LENGTH)
++  if (length > OS_2_LENGTH2)
+   return_error(gs_error_invalidfont);
+   OS_2_start = start;
+   OS_2_length = length;
Index: print/ghostscript/gnu/patches/patch-src_gxttf_h
===
RCS file: print/ghostscript/gnu/patches/patch-src_gxttf_h
diff -N print/ghostscript/gnu/patches/patch-src_gxttf_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ print/ghostscript/gnu/patches/patch-src_gxttf_h 1 Jan 2007 23:20:18 
-
@@ -0,0 +1,21 @@
+$OpenBSD$
+
+# Fix for bug 688536. From upstream svn.
+
+--- src/gxttf.h.orig   Mon Mar 13 17:18:19 2006
 src/gxttf.hMon Jan  1 20:19:11 2007
+@@ -134,7 +134,13 @@ typedef struct ttf_OS_2_s {
+   sTypoLineGap[2],
+   usWinAscent[2],
+   usWinDescent[2],
+-  ulCodePageRanges[8];
++  ulCodePageRanges[8],
++
++sxHeight[2],/* version 2 */
++  sCapHeight[2],
++  usDefaultChar[2],
++  usBreakChar[2],
++usMaxContext[2];
+ } ttf_OS_2_t;
+ 
+ /* -- vhea -- */

Re: on current, Xvnc core dumps on amd64 (with an intel dual core

2007-01-01 Thread Nikns Siankin 
On Mon, Jan 01, 2007 at 10:22:14AM -0600, Travers Buda wrote:
>On Mon, 01 Jan 2007 13:34:16 +0100
>Didier Wiroth <[EMAIL PROTECTED]> wrote:
>
>> Hello,
>> I'm trying to use tightvnc-1.2.9p0 on current amd64 (with intel dual core 
>> cpu).
>
>Perhaps one of these is at fault:
>http://geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif
>
>Travers Buda
>

No. I have amd64 box without any duals cores...
Port is broken for amd64. There are a lot of *bugreports*
on misc@ about this port.

xine-lib security fix.

2007-01-01 Thread Brad 
Here is a security fix for the xine-lib port.

The details...

A potential buffer overflow was found in the code used to handle RealMedia
RTSP streams. When checking for matching asm rules, the code stores the
results in a fixed-size array, but no boundary checks are performed. This
may lead to a buffer overflow if the user is tricked into connecting to a
malicious server. Since the attacker can not write arbitrary data into the
buffer, creating an exploit is very hard; but a DoS attack is easily made.


Index: Makefile
===
RCS file: /cvs/ports/multimedia/xine-lib/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile16 Dec 2006 12:22:34 -  1.9
+++ Makefile1 Jan 2007 20:18:20 -
@@ -4,7 +4,7 @@ COMMENT="multimedia decoding library"
 
 V= 1.1.2
 DISTNAME=  xine-lib-${V}
-PKGNAME=   ${DISTNAME}p3
+PKGNAME=   ${DISTNAME}p4
 EXTRACT_SUFX=  .tar.bz2
 CATEGORIES=multimedia
 SHARED_LIBS=   xine14.1
Index: patches/patch-src_input_libreal_asmrp_c
===
RCS file: 
/cvs/ports/multimedia/xine-lib/patches/patch-src_input_libreal_asmrp_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_input_libreal_asmrp_c
--- patches/patch-src_input_libreal_asmrp_c 7 Dec 2006 09:21:01 -   
1.1
+++ patches/patch-src_input_libreal_asmrp_c 1 Jan 2007 20:28:26 -
@@ -1,7 +1,15 @@
 $OpenBSD: patch-src_input_libreal_asmrp_c,v 1.1 2006/12/07 09:21:01 steven Exp 
$
 src/input/libreal/asmrp.c.orig Mon Dec  4 14:27:53 2006
-+++ src/input/libreal/asmrp.c  Mon Dec  4 14:30:49 2006
-@@ -604,7 +604,7 @@ static int asmrp_rule (asmrp_t *p) {
+--- src/input/libreal/asmrp.c.orig Fri Aug 27 14:34:16 2004
 src/input/libreal/asmrp.c  Mon Jan  1 15:27:04 2007
+@@ -37,6 +37,7 @@
+ #include 
+ #include 
+ #include 
++#include "asmrp.h"
+ 
+ #define LOG_MODULE "asmrp"
+ #define LOG_VERBOSE
+@@ -604,7 +605,7 @@ static int asmrp_rule (asmrp_t *p) {
return ret;
  }
  
@@ -10,7 +18,7 @@ $OpenBSD: patch-src_input_libreal_asmrp_
  
int rule_num, num_matches;
  
-@@ -613,7 +613,7 @@ static int asmrp_eval (asmrp_t *p, int *
+@@ -613,13 +614,15 @@ static int asmrp_eval (asmrp_t *p, int *
asmrp_get_sym (p);
  
rule_num = 0; num_matches = 0;
@@ -19,7 +27,17 @@ $OpenBSD: patch-src_input_libreal_asmrp_
  
  if (asmrp_rule (p)) {
lprintf ("rule #%d is true\n", rule_num);
-@@ -629,7 +629,7 @@ static int asmrp_eval (asmrp_t *p, int *
+ 
+-  matches[num_matches] = rule_num;
+-  num_matches++;
++  if(num_matches < MAX_RULEMATCHES - 1)
++matches[num_matches++] = rule_num;
++  else
++printf("Ignoring matched asm rule %d, too many matched rules.\n", 
rule_num);
+ }
+ 
+ rule_num++;
+@@ -629,7 +632,7 @@ static int asmrp_eval (asmrp_t *p, int *
return num_matches;
  }
  
@@ -28,7 +46,7 @@ $OpenBSD: patch-src_input_libreal_asmrp_
  
asmrp_t *p;
int  num_matches;
-@@ -641,7 +641,7 @@ int asmrp_match (const char *rules, int 
+@@ -641,7 +644,7 @@ int asmrp_match (const char *rules, int 
asmrp_set_id (p, "Bandwidth", bandwidth);
asmrp_set_id (p, "OldPNMPlayer", 0);
  
Index: patches/patch-src_input_libreal_asmrp_h
===
RCS file: 
/cvs/ports/multimedia/xine-lib/patches/patch-src_input_libreal_asmrp_h,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_input_libreal_asmrp_h
--- patches/patch-src_input_libreal_asmrp_h 7 Dec 2006 09:21:01 -   
1.1
+++ patches/patch-src_input_libreal_asmrp_h 1 Jan 2007 20:28:18 -
@@ -1,11 +1,13 @@
 $OpenBSD: patch-src_input_libreal_asmrp_h,v 1.1 2006/12/07 09:21:01 steven Exp 
$
 src/input/libreal/asmrp.h.orig Mon Dec  4 14:28:04 2006
-+++ src/input/libreal/asmrp.h  Mon Dec  4 14:31:10 2006
-@@ -37,6 +37,6 @@
+--- src/input/libreal/asmrp.h.orig Mon Dec  8 19:02:30 2003
 src/input/libreal/asmrp.h  Mon Jan  1 15:27:47 2007
+@@ -37,6 +37,8 @@
  #ifndef HAVE_ASMRP_H
  #define HAVE_ASMRP_H
  
 -int asmrp_match (const char *rules, int bandwidth, int *matches) ;
++#define MAX_RULEMATCHES 16
++
 +int asmrp_match (const char *rules, int bandwidth, int *matches, int 
matchsize) ;
  
  #endif
Index: patches/patch-src_input_libreal_real_c
===
RCS file: 
/cvs/ports/multimedia/xine-lib/patches/patch-src_input_libreal_real_c,v
retrieving revision 1.3
diff -u -p -r1.3 patch-src_input_libreal_real_c
--- patches/patch-src_input_libreal_real_c  7 Dec 2006 09:21:01 -   
1.3
+++ patches/patch-src_input_libreal_real_c  1 Jan 2007 20:28:18 -
@@ -1,6 +1,6 @@
 $OpenBSD: patch-src_input_libreal_real_c,v 1.3 2006/12/07 09:21:01 steven Exp $
 --- src/input/libreal/real.c.orig  Sun Jul  9 10:37:40 2006
-+++ src

MPlayer security fix.

2007-01-01 Thread Brad 
Here is a security fix for the MPlayer port.

The details...

A potential buffer overflow was found in the code used to handle RealMedia
RTSP streams. When checking for matching asm rules, the code stores the
results in a fixed-size array, but no boundary checks are performed. This
may lead to a buffer overflow if the user is tricked into connecting to a
malicious server. Since the attacker can not write arbitrary data into the
buffer, creating an exploit is very hard; but a DoS attack is easily made. 


Index: Makefile
===
RCS file: /cvs/ports/x11/mplayer/Makefile,v
retrieving revision 1.107
diff -u -p -r1.107 Makefile
--- Makefile28 Dec 2006 02:23:17 -  1.107
+++ Makefile1 Jan 2007 19:44:30 -
@@ -7,7 +7,7 @@ COMMENT="Movie player supporting MPEG,
 
 DISTNAME=  MPlayer-1.0pre8
 DIST_SUBDIR=   mplayer
-PKGNAME=   ${DISTNAME:L}p2
+PKGNAME=   ${DISTNAME:L}p3
 CATEGORIES=x11
 EXTRACT_SUFX=  .tar.bz2
 
Index: patches/patch-libmpdemux_realrtsp_asmrp_c
===
RCS file: patches/patch-libmpdemux_realrtsp_asmrp_c
diff -N patches/patch-libmpdemux_realrtsp_asmrp_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-libmpdemux_realrtsp_asmrp_c   1 Jan 2007 19:55:47 -
@@ -0,0 +1,24 @@
+$OpenBSD$
+--- libmpdemux/realrtsp/asmrp.c.orig   Mon Jan  1 14:46:36 2007
 libmpdemux/realrtsp/asmrp.cMon Jan  1 14:47:35 2007
+@@ -40,6 +40,7 @@
+ #include 
+ #include 
+ #include 
++#include "asmrp.h"
+ 
+ /*
+ #define LOG
+@@ -645,8 +646,10 @@ static int asmrp_eval (asmrp_t *p, int *
+ #ifdef LOG
+   printf ("rule #%d is true\n", rule_num);
+ #endif
+-  matches[num_matches] = rule_num;
+-  num_matches++;
++  if(num_matches < MAX_RULEMATCHES - 1)
++matches[num_matches++] = rule_num;
++  else
++printf("Ignoring matched asm rule %d, too many matched rules.\n", 
rule_num);
+ }
+ 
+ rule_num++;
Index: patches/patch-libmpdemux_realrtsp_asmrp_h
===
RCS file: patches/patch-libmpdemux_realrtsp_asmrp_h
diff -N patches/patch-libmpdemux_realrtsp_asmrp_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-libmpdemux_realrtsp_asmrp_h   1 Jan 2007 19:50:32 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- libmpdemux/realrtsp/asmrp.h.orig   Mon Jan  1 14:49:49 2007
 libmpdemux/realrtsp/asmrp.hMon Jan  1 14:50:23 2007
+@@ -40,6 +40,8 @@
+ #ifndef HAVE_ASMRP_H
+ #define HAVE_ASMRP_H
+ 
++#define MAX_RULEMATCHES 16
++
+ int asmrp_match (const char *rules, int bandwidth, int *matches) ;
+ 
+ #endif
Index: patches/patch-libmpdemux_realrtsp_real_c
===
RCS file: patches/patch-libmpdemux_realrtsp_real_c
diff -N patches/patch-libmpdemux_realrtsp_real_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-libmpdemux_realrtsp_real_c1 Jan 2007 19:50:32 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- libmpdemux/realrtsp/real.c.origMon Jan  1 14:49:12 2007
 libmpdemux/realrtsp/real.c Mon Jan  1 14:49:37 2007
+@@ -528,7 +528,7 @@ rmff_header_t *real_parse_sdp(char *data
+ int j=0;
+ int n;
+ char b[64];
+-int rulematches[16];
++int rulematches[MAX_RULEMATCHES];
+ 
+ #ifdef LOG
+ printf("calling asmrp_match with:\n%s\n%u\n", 
desc->stream[i]->asm_rule_book, bandwidth);

Re: on current, Xvnc core dumps on amd64 (with an intel dual core

2007-01-01 Thread Travers Buda 
On Mon, 1 Jan 2007 17:39:00 +0100 (CET)
Otto Moerbeek <[EMAIL PROTECTED]> wrote:

> 
> On Mon, 1 Jan 2007, Travers Buda wrote:
> 
> > On Mon, 01 Jan 2007 13:34:16 +0100
> > Didier Wiroth <[EMAIL PROTECTED]> wrote:
> > 
> > > Hello,
> > > I'm trying to use tightvnc-1.2.9p0 on current amd64 (with intel dual core 
> > > cpu).
> > 
> > Perhaps one of these is at fault:
> > http://geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif
> > 
> > Travers Buda
> 
> Core 2 CPU != Core CPU.
> 
> The errata quoted is about the Core Duo/Solo CPU, the OP has a Core 2
> Duo CPU. 
> 
> A difference between the two is that the Core CPU's ae 32bit,
> while the Core 2 CPU is 64 bit.
> 
>   -Otto
> 

Whell, of course, =); it's a place to start. Another place to start would be 
trying to reproduce this on i386 -current... Didier?

Re: on current, Xvnc core dumps on amd64 (with an intel dual core

2007-01-01 Thread Otto Moerbeek 

On Mon, 1 Jan 2007, Travers Buda wrote:

> On Mon, 01 Jan 2007 13:34:16 +0100
> Didier Wiroth <[EMAIL PROTECTED]> wrote:
> 
> > Hello,
> > I'm trying to use tightvnc-1.2.9p0 on current amd64 (with intel dual core 
> > cpu).
> 
> Perhaps one of these is at fault:
> http://geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif
> 
> Travers Buda

Core 2 CPU != Core CPU.

The errata quoted is about the Core Duo/Solo CPU, the OP has a Core 2
Duo CPU. 

A difference between the two is that the Core CPU's ae 32bit,
while the Core 2 CPU is 64 bit.

-Otto

Re: on current, Xvnc core dumps on amd64 (with an intel dual core

2007-01-01 Thread Travers Buda 
On Mon, 01 Jan 2007 13:34:16 +0100
Didier Wiroth <[EMAIL PROTECTED]> wrote:

> Hello,
> I'm trying to use tightvnc-1.2.9p0 on current amd64 (with intel dual core 
> cpu).

Perhaps one of these is at fault:
http://geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif

Travers Buda

UPDATE: textproc/libebml-0.7.7

2007-01-01 Thread Antoine Jacoutot 

Hi.

This diff updates libebml to the latest available version.
multimedia/libmatroska compiles fine with it and I need it for the ports 
of mkvtoolnix and iso2mkv I'm working on.


ok?

--
AntoineIndex: Makefile
===
RCS file: /cvs/ports/textproc/libebml/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- Makefile22 Mar 2006 01:26:57 -  1.1.1.1
+++ Makefile1 Jan 2007 15:43:26 -
@@ -1,7 +1,7 @@
 # $OpenBSD: Makefile,v 1.1.1.1 2006/03/22 01:26:57 jolan Exp $
 
 COMMENT=   "Extensible Binary Meta Language library"
-DISTNAME=  libebml-0.7.6
+DISTNAME=  libebml-0.7.7
 SHARED_LIBS=   ebml 0.0
 EXTRACT_SUFX=  .tar.bz2
 CATEGORIES=textproc
Index: distinfo
===
RCS file: /cvs/ports/textproc/libebml/distinfo,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 distinfo
--- distinfo22 Mar 2006 01:26:57 -  1.1.1.1
+++ distinfo1 Jan 2007 15:43:26 -
@@ -1,4 +1,4 @@
-MD5 (libebml-0.7.6.tar.bz2) = bb054799dfdf6bfa5dd2cf95416ff021
-RMD160 (libebml-0.7.6.tar.bz2) = d389dba159de1c8e2a783b3cee483dceff277801
-SHA1 (libebml-0.7.6.tar.bz2) = fe94f77d9f45529bce42ca16714882ce4d5ae843
-SIZE (libebml-0.7.6.tar.bz2) = 56317
+MD5 (libebml-0.7.7.tar.bz2) = 7c8456a50fd82c1c9755917d0182c49e
+RMD160 (libebml-0.7.7.tar.bz2) = d42ec6606a16cc9b38cff501e14929853136fa0b
+SHA1 (libebml-0.7.7.tar.bz2) = e79f98968c8566c95637616c4419697e0adbecca
+SIZE (libebml-0.7.7.tar.bz2) = 56527
Index: patches/patch-make_linux_Makefile
===
RCS file: /cvs/ports/textproc/libebml/patches/patch-make_linux_Makefile,v
retrieving revision 1.2
diff -u -r1.2 patch-make_linux_Makefile
--- patches/patch-make_linux_Makefile   28 Mar 2006 01:06:52 -  1.2
+++ patches/patch-make_linux_Makefile   1 Jan 2007 15:43:26 -
@@ -1,6 +1,6 @@
 $OpenBSD: patch-make_linux_Makefile,v 1.2 2006/03/28 01:06:52 jolan Exp $
 make/linux/Makefile.orig   Tue Apr 19 01:56:06 2005
-+++ make/linux/MakefileMon Mar 27 19:05:00 2006
+--- make/linux/Makefile.orig   Mon Jan  1 16:36:35 2007
 make/linux/MakefileMon Jan  1 16:39:27 2007
 @@ -16,11 +16,11 @@ prefix=/boot/home/config
  else
  prefix=/usr/local
@@ -25,19 +25,20 @@
  
  # source-files
  sources:=$(wildcard ${SRC_DIR}*$(EXTENSION))
-@@ -94,8 +94,7 @@ $(LIBRARY): $(objects)
+@@ -94,9 +94,7 @@ $(LIBRARY): $(objects)
$(RANLIB) $@
  
  $(LIBRARY_SO): $(objects_so)
 -  $(CXX) -shared -Wl,-soname,$(LIBRARY_SO_VER) -o $(LIBRARY_SO_VER) 
$(objects_so)
+-  rm -f $(LIBRARY_SO)
 -  ln -s $(LIBRARY_SO_VER) $(LIBRARY_SO)
 +  $(CXX) -shared -Wl,-soname,$(LIBRARY_SO_VER) -o $(LIBRARY_SO_VER) 
$(objects_so) -fPIC
  
  clean:
rm -f $(objects) $(objects_so)
-@@ -139,7 +138,6 @@ install_staticlib: $(LIBRARY)
- 
+@@ -141,7 +139,6 @@ install_staticlib: $(LIBRARY)
  install_sharedlib: $(LIBRARY_SO)
+   $(INSTALL) $(INSTALL_DIR_OPTS) -d $(libdir)
$(INSTALL) $(INSTALL_OPTS_LIB) $(LIBRARY_SO_VER) $(libdir)
 -  ln -s $(LIBRARY_SO_VER) $(libdir)/$(LIBRARY_SO)

Re: NEW: www/hiawatha-5.4

2007-01-01 Thread Marc Balmer 

Marc Espie wrote:

Well,  I was probably a bit harsh on my first comments wrt hiawatha.
One actually nice feature of this program is that it is reasonably
small. Someone with incentive could probably audit it.

Since it is under the GPL, the OpenBSD project has little incentive
in looking at it very closely...


You might want to a closer look a www/nostromo, a secure and small 
webserver written by [EMAIL PROTECTED]




Antoine fixed hiawatha so that it does not abuse user nobody, so that one
issue doesn't exist on OpenBSD.

Just looking shows me there is probably a race condition on signals.
Using the same variable for TERM/USR1/USR2 is asking for trouble...
and the variable is an int, not a sigatomic_t (whch is innocuous on
most arches, but still).

Some printf's are not portable... like printing getpid with %d (okay,
this is a stretch). 


the str2int function has absolutely no overflow handling and uses 48
directly, which is totally icky. This means that a few functions have no
protection against user error, which is probably not too bad.

Like I already noticed, there is no handler for seg faults, not even 
something to log an error message (which is about all that should happen,

but this SHOULD happen).

I've looked a bit more, but the coding layout is a bit bizarre. I'm not
a big fan of code that indents out to column 160 or so...

There are LOTS of hand-coded length computations based on strings, and use
of unsafe string functions, or error-prone stuff (between atoi, str2int,
strncpy, and friends...).  I don't think it's incredibly bad, but it doesn't
look incredibly good either...

Re: NEW: www/hiawatha-5.4

2007-01-01 Thread Marc Espie 
Well,  I was probably a bit harsh on my first comments wrt hiawatha.
One actually nice feature of this program is that it is reasonably
small. Someone with incentive could probably audit it.

Since it is under the GPL, the OpenBSD project has little incentive
in looking at it very closely...

Antoine fixed hiawatha so that it does not abuse user nobody, so that one
issue doesn't exist on OpenBSD.

Just looking shows me there is probably a race condition on signals.
Using the same variable for TERM/USR1/USR2 is asking for trouble...
and the variable is an int, not a sigatomic_t (whch is innocuous on
most arches, but still).

Some printf's are not portable... like printing getpid with %d (okay,
this is a stretch). 

the str2int function has absolutely no overflow handling and uses 48
directly, which is totally icky. This means that a few functions have no
protection against user error, which is probably not too bad.

Like I already noticed, there is no handler for seg faults, not even 
something to log an error message (which is about all that should happen,
but this SHOULD happen).

I've looked a bit more, but the coding layout is a bit bizarre. I'm not
a big fan of code that indents out to column 160 or so...

There are LOTS of hand-coded length computations based on strings, and use
of unsafe string functions, or error-prone stuff (between atoi, str2int,
strncpy, and friends...).  I don't think it's incredibly bad, but it doesn't
look incredibly good either...

Re: on current, Xvnc core dumps on amd64 (with an intel dual core cpu), could someone confirm?

2007-01-01 Thread Nikns Siankin 
The same here.
Maintainer seems unreachable.


On Mon, Jan 01, 2007 at 01:34:16PM +0100, Didier Wiroth wrote:
>Hello,
>I'm trying to use tightvnc-1.2.9p0 on current amd64 (with intel dual core cpu).
>The Xvnc server core dumps after starting wiith the following log:
>Getting interface configuration (4): Device not configured
>31/12/06 17:24:44 Xvnc version 3.3.tight1.2.9
>31/12/06 17:24:44 Copyright (C) 1999 AT&T Laboratories Cambridge.
>31/12/06 17:24:44 Copyright (C) 2000-2002 Constantin Kaplinsky.
>31/12/06 17:24:44 All Rights Reserved.
>31/12/06 17:24:44 See http://www.uk.research.att.com/vnc for information on VNC
>31/12/06 17:24:44 See http://www.tightvnc.com for TightVNC-specific information
>31/12/06 17:24:44 Desktop name 'test' (dreyfus:1)
>31/12/06 17:24:44 Protocol version supported 3.3
>31/12/06 17:24:44 Listening for VNC connections on TCP port 5901
>31/12/06 17:24:44 Listening for HTTP connections on TCP port 5801
>31/12/06 17:24:44   URL http://dreyfus:5801
>xrdb: Can't open display ':1'
>xsetroot:  unable to open display ':1'
>twm:  unable to open display ":1"
>xterm Xt error: Can't open display: 1
>
>I'm starting Xvnc as a standard user like this:
>vncserver :1 -geometry 1280x1024  -depth 16 -name test -localhost
>
>Could someone else confirm this core dump on amd64 with an "intel dual core 
>cpu"?
>
>Here is my dmesg:
>OpenBSD 4.0-current (GENERIC.MP_acpi) #0: Sun Dec 31 15:55:48 CET 2006
>[EMAIL PROTECTED]:/home/sources/src/sys/arch/amd64/compile/GENERIC.MP_acpi
>real mem = 3220303872 (3144828K)
>avail mem = 2757431296 (2692804K)
>using 22937 buffers containing 322236416 bytes (314684K) of memory
>mainbus0 (root)
>bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0690 (74 entries)
>bios0: stem manufacturer P5WDG2 WS PRO
>acpi0 at mainbus0: rev 2
>acpi0: tables DSDT FACP APIC OEMB HPET MCFG
>acpitimer0 at acpi0: 3579545 Hz, 24 bits
>acpi device at acpi0 from table DSDT not configured
>acpi device at acpi0 from table FACP not configured
>acpimadt0 at acpi0 table APIC addr 0xfee0: PC-AT compat
>LAPIC: acpi_proc_id 1, apic_id 0, flags 0x1
>cpu0 at mainbus0: apid 0 (boot processor)
>cpu0: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz, 2671.61 MHz
>cpu0: 
>FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,LONG
>cpu0: 4MB 64b/line 16-way L2 cache
>cpu0: apic clock running at 267MHz
>LAPIC: acpi_proc_id 2, apic_id 1, flags 0x1
>cpu1 at mainbus0: apid 1 (application processor)
>cpu1: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz, 2671.24 MHz
>cpu1: 
>FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,LONG
>cpu1: 4MB 64b/line 16-way L2 cache
>LAPIC: acpi_proc_id 3, apic_id 82, flags 0x0
>LAPIC: acpi_proc_id 4, apic_id 83, flags 0x0
>IOAPIC: acpi_ioapic_id 2, address 0xfec0, global_int_base 0x0
>ioapic0 at mainbus0 apid 2 pa 0xfec0, version 20, 24 pins
>IOAPIC: acpi_ioapic_id 3, address 0xfec1, global_int_base 0x18
>ioapic1 at mainbus0 apid 3 pa 0xfec1, version 20, 24 pins
>OVERRIDE: bus 0, source 0, global_int 2, flags 0
>OVERRIDE: bus 0, source 9, global_int 9, flags d
>OVERRIDE: bus 0, source 0, global_int 2, flags 0
>OVERRIDE: bus 0, source 9, global_int 9, flags d
>acpi device at acpi0 from table OEMB not configured
>acpihpet0 at acpi0 table HPET: 14318179 Hz
>acpi device at acpi0 from table MCFG not configured
>acpiprt0 at acpi0: bus 0 (PCI0)
>acpiprt1 at acpi0: bus 7 (P0P1)
>acpiprt2 at acpi0: bus 0 (P0P2)
>acpiprt3 at acpi0: bus 1 (P0P3)
>acpiprt4 at acpi0: bus 3 (P0P8)
>acpiprt5 at acpi0: bus 2 (P0P9)
>acpiprt6 at acpi0: bus 4 (P0P4)
>acpiprt7 at acpi0: bus 5 (PXHA)
>acpibtn0 at acpi0: SLPB
>acpibtn1 at acpi0: PWRB
>pci0 at mainbus0 bus 0: configuration mode 1
>pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x277c rev 0xc0
>ppb0 at pci0 dev 1 function 0 vendor "Intel", unknown product 0x277d rev 0xc0
>pci1 at ppb0 bus 7
>vga1 at pci1 dev 0 function 0 "ATI Radeon X300" rev 0x00
>wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
>wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
>"ATI Radeon X300 Sec" rev 0x00 at pci1 dev 0 function 1 not configured
>azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: apic 2 
>int 19 (irq 5)
>azalia0: host: High Definition Audio rev. 1.0
>azalia0: codec: 0x04x/0x11d4 (rev. 2.0), HDA version 1.0
>audio0 at azalia0
>ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01
>pci2 at ppb1 bus 4
>ppb2 at pci2 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
>pci3 at ppb2 bus 5
>ppb3 at pci3 dev 2 function 0 "Intel IOP331 PCIX-PCIX" rev 0x0a
>pci4 at ppb3 bus 6
>ami0 at pci4 dev 14 function 0 "Symbios Logic MegaRAID SATA 4x/8x" rev 0x0a: 
>apic 3 int 4 (irq 11)
>ami0: LSI 3008, 32b, FW 814D, BIOS vH431, 128MB RAM
>ami0: 1 channels, 0 FC loops, 3 logical drives
>scsibus0 at ami0: 40 targets
>sd0 at scsibus0 targ 0 lun 0:  SCSI2 0/direct fixed
>sd0: 10MB, 10 cyl, 64 head,

on current, Xvnc core dumps on amd64 (with an intel dual core cpu), could someone confirm?

2007-01-01 Thread Didier Wiroth 
Hello,
I'm trying to use tightvnc-1.2.9p0 on current amd64 (with intel dual core cpu).
The Xvnc server core dumps after starting wiith the following log:
Getting interface configuration (4): Device not configured
31/12/06 17:24:44 Xvnc version 3.3.tight1.2.9
31/12/06 17:24:44 Copyright (C) 1999 AT&T Laboratories Cambridge.
31/12/06 17:24:44 Copyright (C) 2000-2002 Constantin Kaplinsky.
31/12/06 17:24:44 All Rights Reserved.
31/12/06 17:24:44 See http://www.uk.research.att.com/vnc for information on VNC
31/12/06 17:24:44 See http://www.tightvnc.com for TightVNC-specific information
31/12/06 17:24:44 Desktop name 'test' (dreyfus:1)
31/12/06 17:24:44 Protocol version supported 3.3
31/12/06 17:24:44 Listening for VNC connections on TCP port 5901
31/12/06 17:24:44 Listening for HTTP connections on TCP port 5801
31/12/06 17:24:44   URL http://dreyfus:5801
xrdb: Can't open display ':1'
xsetroot:  unable to open display ':1'
twm:  unable to open display ":1"
xterm Xt error: Can't open display: 1

I'm starting Xvnc as a standard user like this:
vncserver :1 -geometry 1280x1024  -depth 16 -name test -localhost

Could someone else confirm this core dump on amd64 with an "intel dual core 
cpu"?

Here is my dmesg:
OpenBSD 4.0-current (GENERIC.MP_acpi) #0: Sun Dec 31 15:55:48 CET 2006
[EMAIL PROTECTED]:/home/sources/src/sys/arch/amd64/compile/GENERIC.MP_acpi
real mem = 3220303872 (3144828K)
avail mem = 2757431296 (2692804K)
using 22937 buffers containing 322236416 bytes (314684K) of memory
mainbus0 (root)
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0690 (74 entries)
bios0: stem manufacturer P5WDG2 WS PRO
acpi0 at mainbus0: rev 2
acpi0: tables DSDT FACP APIC OEMB HPET MCFG
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpi device at acpi0 from table DSDT not configured
acpi device at acpi0 from table FACP not configured
acpimadt0 at acpi0 table APIC addr 0xfee0: PC-AT compat
LAPIC: acpi_proc_id 1, apic_id 0, flags 0x1
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz, 2671.61 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,LONG
cpu0: 4MB 64b/line 16-way L2 cache
cpu0: apic clock running at 267MHz
LAPIC: acpi_proc_id 2, apic_id 1, flags 0x1
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz, 2671.24 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,LONG
cpu1: 4MB 64b/line 16-way L2 cache
LAPIC: acpi_proc_id 3, apic_id 82, flags 0x0
LAPIC: acpi_proc_id 4, apic_id 83, flags 0x0
IOAPIC: acpi_ioapic_id 2, address 0xfec0, global_int_base 0x0
ioapic0 at mainbus0 apid 2 pa 0xfec0, version 20, 24 pins
IOAPIC: acpi_ioapic_id 3, address 0xfec1, global_int_base 0x18
ioapic1 at mainbus0 apid 3 pa 0xfec1, version 20, 24 pins
OVERRIDE: bus 0, source 0, global_int 2, flags 0
OVERRIDE: bus 0, source 9, global_int 9, flags d
OVERRIDE: bus 0, source 0, global_int 2, flags 0
OVERRIDE: bus 0, source 9, global_int 9, flags d
acpi device at acpi0 from table OEMB not configured
acpihpet0 at acpi0 table HPET: 14318179 Hz
acpi device at acpi0 from table MCFG not configured
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 7 (P0P1)
acpiprt2 at acpi0: bus 0 (P0P2)
acpiprt3 at acpi0: bus 1 (P0P3)
acpiprt4 at acpi0: bus 3 (P0P8)
acpiprt5 at acpi0: bus 2 (P0P9)
acpiprt6 at acpi0: bus 4 (P0P4)
acpiprt7 at acpi0: bus 5 (PXHA)
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
pci0 at mainbus0 bus 0: configuration mode 1
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x277c rev 0xc0
ppb0 at pci0 dev 1 function 0 vendor "Intel", unknown product 0x277d rev 0xc0
pci1 at ppb0 bus 7
vga1 at pci1 dev 0 function 0 "ATI Radeon X300" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
"ATI Radeon X300 Sec" rev 0x00 at pci1 dev 0 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: apic 2 int 
19 (irq 5)
azalia0: host: High Definition Audio rev. 1.0
azalia0: codec: 0x04x/0x11d4 (rev. 2.0), HDA version 1.0
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01
pci2 at ppb1 bus 4
ppb2 at pci2 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
pci3 at ppb2 bus 5
ppb3 at pci3 dev 2 function 0 "Intel IOP331 PCIX-PCIX" rev 0x0a
pci4 at ppb3 bus 6
ami0 at pci4 dev 14 function 0 "Symbios Logic MegaRAID SATA 4x/8x" rev 0x0a: 
apic 3 int 4 (irq 11)
ami0: LSI 3008, 32b, FW 814D, BIOS vH431, 128MB RAM
ami0: 1 channels, 0 FC loops, 3 logical drives
scsibus0 at ami0: 40 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI2 0/direct fixed
sd0: 10MB, 10 cyl, 64 head, 32 sec, 512 bytes/sec, 20480 sec total
sd1 at scsibus0 targ 1 lun 0:  SCSI2 0/direct fixed
sd1: 49998MB, 49998 cyl, 64 head, 32 sec, 512 bytes/sec, 102395904 sec total
sd2 at scsibus0 targ 2 lun 0:  SCSI2 0/di