Re: update: misc/tmux 0.6
Hallo, I committed a correction to the patch. Tmux segfaulted when calling strtonum because of a missing declaration. Fulvio At Mon, 19 Jan 2009 19:08:07 +, Nicholas Marriott wrote: > > On Mon, Jan 19, 2009 at 03:12:29PM +, Christian Weisgerber wrote: > > Nicholas Marriott wrote: > > > > > Update to new tmux version 0.6. > > > > Clock-mode doesn't seem to work. It clears the screen, except for > > the status line, and positions the cursor in the lower right corner. > > There is no clock, apart from the one in the status line. > > > > ... > > > > Oh. Let me revise that. Clock-mode requires color. Running with > > TERM=xterm-xfree86, I see this big clock in the middle of the screen. > > With default monochrome xterm, the clock is white on white, I guess. > > Whoops, yes, it draws it by setting the background colour and using spaces, > obviously if the terminal doesn't support setting colours then this doesn't > work... doh. > > I've changed it to use reverse attributes instead which works with both b&w > and > colour terminals - this change will be in 0.7. Now the only problem is > terminals which doesn't support reverse, but I don't think there is much to be > done about them. > > Thanks, > > Nicholas >
Re: update: misc/tmux 0.6
Ops, sorry... I answered the wrong thread. Fulvio At Mon, 19 Jan 2009 19:08:07 +, Nicholas Marriott wrote: > > On Mon, Jan 19, 2009 at 03:12:29PM +, Christian Weisgerber wrote: > > Nicholas Marriott wrote: > > > > > Update to new tmux version 0.6. > > > > Clock-mode doesn't seem to work. It clears the screen, except for > > the status line, and positions the cursor in the lower right corner. > > There is no clock, apart from the one in the status line. > > > > ... > > > > Oh. Let me revise that. Clock-mode requires color. Running with > > TERM=xterm-xfree86, I see this big clock in the middle of the screen. > > With default monochrome xterm, the clock is white on white, I guess. > > Whoops, yes, it draws it by setting the background colour and using spaces, > obviously if the terminal doesn't support setting colours then this doesn't > work... doh. > > I've changed it to use reverse attributes instead which works with both b&w > and > colour terminals - this change will be in 0.7. Now the only problem is > terminals which doesn't support reverse, but I don't think there is much to be > done about them. > > Thanks, > > Nicholas >
new: emacs 22.1
Hallo, attached is a port for emacs 22.1. Emacs 22 adds or improves many features to emacs 21. Note the following: A previous port of emacs 22.1 of 10 jun 2007 exists but does not work in current ports. Emacs 22.1 compiles unpatched on openbsd, actually, the patches found in emacs 21.* seem to have been committed to emacs 22. At least I checked the configure script. I choose a simple approach, conforming to the port of 21.*, with flavours no-x11 and without a gtk flavour. I splitted the package as in port emacs-21.* in emacs-base and emacs-el. No -leim, since this is now included in emacs source. I tested on my i386 architecture and the package compiles and works. I additionally tested that auctex compile and work with emacs->=21. Fulvio Ciriaco emacs22.tar.gz Description: Binary data
sbcl: probably needs tweaking on {Open,Free}BSD
Hallo, I tested the recent port of sbcl for OpenBSD at http://www.elsasser.org/openbsd/sbcl-port-1.0.14.tgz it compiles fine but shows undesirable behaviour, at least on my i386 arch, openbsd current. If run by normal user it requires --dynamic-space-size option set. If run by root, it starts creating a process 700Mb in size, on my arch. Indeed, I tested this on FreeBSD 6.3, i386 too. This is output from top: PID USERNAMETHR PRI NICE SIZERES STATETIME WCPU COMMAND 43495 fc1 960 1036M 16748K select 0:00 0.00% sbcl More sensible values of DEFAULT_DYNAMIC_SPACE_SIZE are required in my opinion. Fulvio Ciriaco
update: sawfish
Attached find a proposal for update of sawfish: 1.3 -> 1.3.1 It compiles and works here: i386, openbsd-current Fulvio Ciriaco PS librep should probably be updated too. I will look at it soon. sawfish.tgz Description: Binary data
new: slime
Hallo, enclosed find a tgz archive for a port of slime. slime is a lisp development environment running under emacs. slime: the superior lisp interaction mode for emacs slime.tgz Description: Binary data
sawfish update: 1.3->1.3.1
Hallo,
cvs diff for sawfish update to 1.3.1,
I have been using it for two weeks without any issues
Fulvio
Index: Makefile
===
RCS file: /cvs/ports/x11/sawfish/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile15 Sep 2007 20:04:24 - 1.29
+++ Makefile18 Feb 2008 20:42:20 -
@@ -2,14 +2,14 @@
COMMENT= extensible window manager
-VERSION= 1.3
+VERSION= 1.3.1
DISTNAME= sawfish-${VERSION}
-PKGNAME= ${DISTNAME}p8
+PKGNAME= ${DISTNAME}p0
CATEGORIES=x11
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=sawmill/}
-HOMEPAGE= http://sawmill.sourceforge.net/
+HOMEPAGE= http://sawfish.wikia.com/
# GPL
PERMIT_PACKAGE_CDROM= Yes
@@ -32,7 +32,9 @@ SUBST_VARS= GNU_ARCH VERSION
USE_X11= Yes
USE_GMAKE= Yes
-CONFIGURE_STYLE= gnu
+CONFIGURE_STYLE= gnu automake autoconf
+AUTOCONF_VERSION=2.61
+CONFIGURE_SCRIPT= ./autogen.sh
MODGNU_CONFIG_GUESS_DIRS= ${WRKSRC}/etc
CONFIGURE_ARGS+= ${CONFIGURE_SHARED}
CONFIGURE_ARGS+= --without-audiofile --without-esd \
@@ -41,7 +43,8 @@ CONFIGURE_ARGS+= --without-audiofile --w
CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include -I{X11BASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib" \
PKG_CONFIG_PATH="/usr/X11R6/lib/pkgconfig"
-
+CONFIGURE_ENV+= AUTOCONF_VERSION=${AUTOCONF_VERSION} \
+ AUTOMAKE_VERSION=${AUTOMAKE_VERSION}
NO_REGRESS=Yes
.include
Index: distinfo
===
RCS file: /cvs/ports/x11/sawfish/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo5 Apr 2007 17:36:24 - 1.4
+++ distinfo18 Feb 2008 20:42:20 -
@@ -1,5 +1,3 @@
-MD5 (sawfish-1.3.tar.gz) = nlzl52xgrOzbGInB8XMpWg==
-RMD160 (sawfish-1.3.tar.gz) = 7vOzm+whtO3noa8vyap3FHctfQw=
-SHA1 (sawfish-1.3.tar.gz) = tjHHsRCgnDom8HH3povn3plXWhw=
-SHA256 (sawfish-1.3.tar.gz) = xTzZbQPFhM81cMuS/APIsq9OaPqG8ZJZU11KexePqoc=
-SIZE (sawfish-1.3.tar.gz) = 1582279
+SHA1 (sawfish-1.3.1.tar.gz) = c204129b7b6fdf702580140c39f62c561683216a
+RMD160 (sawfish-1.3.1.tar.gz) = 66de77629ad98e6205c13b7300928616d687c80a
+SIZE (sawfish-1.3.1.tar.gz) = 1741281
Index: pkg/PLIST
===
RCS file: /cvs/ports/x11/sawfish/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- pkg/PLIST 20 Jan 2006 13:12:03 - 1.7
+++ pkg/PLIST 18 Feb 2008 20:42:20 -
@@ -33,6 +33,9 @@ libexec/sawfish/${VERSION}/${GNU_ARCH}/s
libexec/sawfish/${VERSION}/${GNU_ARCH}/selection.la
libexec/sawfish/${VERSION}/${GNU_ARCH}/x.a
libexec/sawfish/${VERSION}/${GNU_ARCH}/x.la
+share/gnome/
+share/gnome/wm-properties/
+share/gnome/wm-properties/Sawfish.desktop
share/locale/no/LC_MESSAGES/sawfish.mo
share/pixmaps/
share/pixmaps/sawfish-logo.png
libglade: bug, minor
Hallo, libglade installs script libglade-xgettext, this is a #!/usr/bin/env python script. python does however not exist on OpenBSD. Also, apparently libglade does not depend on python. Fulvio
sawfish update: 1.3.3
Attached you can find the cvs diff for sawfish update: 1.3 -> 1.3.3.
It has been working fine on my i386 openbsd snapshot since I compiled
it on Feb. 20th.
Fulvio
PS main fixes are to erroneous behaviour upon customization.Index: Makefile
===
RCS file: /cvs/ports/x11/sawfish/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- Makefile22 Feb 2008 16:52:43 - 1.30
+++ Makefile19 Mar 2008 17:35:33 -
@@ -1,15 +1,15 @@
-# $OpenBSD: Makefile,v 1.30 2008/02/22 16:52:43 naddy Exp $
+# $OpenBSD: Makefile,v 1.31 2008-02-20 fulvio ciriaco $
COMMENT= extensible window manager
-VERSION= 1.3
+VERSION= 1.3.3
DISTNAME= sawfish-${VERSION}
-PKGNAME= ${DISTNAME}p9
+PKGNAME= ${DISTNAME}p0
CATEGORIES=x11
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=sawmill/}
-HOMEPAGE= http://sawmill.sourceforge.net/
+HOMEPAGE= http://sawfish.wikia.com/
# GPL
PERMIT_PACKAGE_CDROM= Yes
@@ -22,6 +22,7 @@ WANTLIB= ICE SM X11 Xext Xft.>=5 Xineram
gobject-2.0 gtk-x11-2.0 pango-1.0 glitz png \
pangocairo-1.0 pangoft2-1.0 rep.>=12 cairo
+
BUILD_DEPENDS= ${RUN_DEPENDS}
RUN_DEPENDS= :rep-gtk-*:x11/rep-gtk
@@ -36,12 +37,11 @@ CONFIGURE_STYLE= gnu
MODGNU_CONFIG_GUESS_DIRS= ${WRKSRC}/etc
CONFIGURE_ARGS+= ${CONFIGURE_SHARED}
CONFIGURE_ARGS+= --without-audiofile --without-esd \
---disable-capplet --disable-themer \
+--disable-capplet --disable-themer\
--disable-gnome-widgets --disable-linguas
CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include -I{X11BASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib" \
PKG_CONFIG_PATH="/usr/X11R6/lib/pkgconfig"
-
NO_REGRESS=Yes
.include
Index: distinfo
===
RCS file: /cvs/ports/x11/sawfish/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo5 Apr 2007 17:36:24 - 1.4
+++ distinfo19 Mar 2008 17:35:33 -
@@ -1,5 +1,7 @@
-MD5 (sawfish-1.3.tar.gz) = nlzl52xgrOzbGInB8XMpWg==
-RMD160 (sawfish-1.3.tar.gz) = 7vOzm+whtO3noa8vyap3FHctfQw=
-SHA1 (sawfish-1.3.tar.gz) = tjHHsRCgnDom8HH3povn3plXWhw=
-SHA256 (sawfish-1.3.tar.gz) = xTzZbQPFhM81cMuS/APIsq9OaPqG8ZJZU11KexePqoc=
-SIZE (sawfish-1.3.tar.gz) = 1582279
+SHA1 (sawfish-1.3.1.tar.gz) = c204129b7b6fdf702580140c39f62c561683216a
+RMD160 (sawfish-1.3.1.tar.gz) = 66de77629ad98e6205c13b7300928616d687c80a
+SIZE (sawfish-1.3.1.tar.gz) = 1741281
+
+SHA1 (sawfish-1.3.3.tar.gz) = 3a77267cc8a2032a5a0810070b2a200fe4961250
+RMD160 (sawfish-1.3.3.tar.gz) = 82f11163013c711559fe48e51a85ff9926086faf
+SIZE (sawfish-1.3.3.tar.gz) = 1805122
Index: pkg/PLIST
===
RCS file: /cvs/ports/x11/sawfish/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- pkg/PLIST 20 Jan 2006 13:12:03 - 1.7
+++ pkg/PLIST 19 Mar 2008 17:35:34 -
@@ -33,6 +33,9 @@ libexec/sawfish/${VERSION}/${GNU_ARCH}/s
libexec/sawfish/${VERSION}/${GNU_ARCH}/selection.la
libexec/sawfish/${VERSION}/${GNU_ARCH}/x.a
libexec/sawfish/${VERSION}/${GNU_ARCH}/x.la
+share/gnome/
+share/gnome/wm-properties/
+share/gnome/wm-properties/Sawfish.desktop
share/locale/no/LC_MESSAGES/sawfish.mo
share/pixmaps/
share/pixmaps/sawfish-logo.png
git-1.5.4.2: small port bug, patch
Hallo, git help does not work. GIT_MAN_PATH is set incorrectly to /usr/local/share/man. my solution is: patch patches/patch-Makefile -mandir = $(prefix)/share/man +mandir = $(prefix)/man/ Fulvio
new:orgmode
Hi,
attached find a port of org mode: http://orgmode.org .
Org mode shipped with emacs/xemacs is a stale version,
e.g. 4.67 for emacs22.{1,2}.
The port provides an uptodate version (6.01d) with nice
new features and bug fixes.
Fulvio
clisp: clx flavor
Hallo, I added a clx flavor to clisp, clx is a foreign interface to Xlib allowing for use of X programs in clisp. Stumpwm for example (http://www.nongnu.org/stumpwm/) is a wm running under clisp/sbcl dependent on clx. By the way clisp 2.44.1 is out. Instructions recommend libffcall but I could not find it anywhere. It compiles and runs fine nonetheless. OffTopic: cvs diff refused to diff the new file in pkg until I cvs added it. Is this normal behaviour? Flags overriding it? Fulvio
Re: clisp: clx flavor
From: Michael Small <[EMAIL PROTECTED]> Subject: Re: clisp: clx flavor Date: Wed, 30 Apr 2008 23:11:55 -0400 > On Wed, Apr 30, 2008 at 11:12:58PM +0200, fulvio ciriaco wrote: > > Hallo, > > I added a clx flavor to clisp, > > clx is a foreign interface to Xlib allowing for use > > of X programs in clisp. > > Stumpwm for example (http://www.nongnu.org/stumpwm/) is a wm running > > under clisp/sbcl dependent on clx. > > By the way clisp 2.44.1 is out. Instructions recommend libffcall > > but I could not find it anywhere. It compiles and runs fine nonetheless. > > I think that's the package called ffcall under devel. At least I can > get fairly far compiling clisp on macppc using that (I'm hitting a > stack overflow with a 32M stack). > > -- > Mike Small > [EMAIL PROTECTED] > You are right in fact, ffcall is what instructions mean. However, though recommended, clisp 2.44.1 does not compile --with-ffcall on openbsd current i386. Undefined references to __va_(all kind of vars) Otherwise it compiles fine --with-gmalloc Fulvio
auctex port: small bug
Hi, in port print/auctex file /usr/local/share/emacs/site-lisp/tex-site.el the following assignment is wrong: (defvar TeX-lisp-directory "/usr/ports/print/auctex/w-auctex-11.14p1/fake-i386/u sr/local/share/emacs/site-lisp/auctex/" "*The directory where the AUC TeX lisp files are located.") I suggest the attached patched patch-Makefile Fulvio $OpenBSD: patch-Makefile,v 1.1.1.1 2004/02/21 01:41:12 pvalchev Exp $ --- Makefile.orig Sun Dec 15 03:15:42 2002 +++ MakefileMon May 5 19:55:09 2008 @@ -17,9 +17,9 @@ infodir = $(prefix)/info # Where local lisp files go. lispdir = $(prefix)/share/emacs/site-lisp - # Where the AUC TeX emacs lisp files go. aucdir=$(lispdir)/auctex +finaldir = $(prefix)/share/emacs/site-lisp/auctex # Name of your emacs binary EMACS=emacs @@ -121,12 +121,12 @@ contrib: # $(ELC) hilit-LaTeX.el # Doesn't compile without X install-lisp: some - if [ ! -d $(lispdir) ]; then mkdir $(lispdir); else true; fi ; + if [ ! -d $(lispdir) ]; then mkdir -p -m 755 $(lispdir); else true; fi ; if [ -f $(lispdir)/tex-site.el ]; \ then \ echo "Leaving old tex-site.el alone."; \ else \ - sed -e '[EMAIL PROTECTED](aucdir)/#' tex-site.el \ + sed -e '[EMAIL PROTECTED](finaldir)/#' tex-site.el \ > $(lispdir)/tex-site.el ; \ fi if [ ! -d $(aucdir) ]; then mkdir $(aucdir); else true; fi ;
status of gcc 4.2, 4.3 ports
Hallo, I have been using egfortran from package gcc 4.2 for six months and bugs showed here and there. Recently I had occasion to compile large pieces of chemical computing software. The result depended on optimization flags: -O2 all tests result in never ending jobs -O1 all tests segmentation fault -O0 all tests passed but a few. I built a port of gcc 4.2.4 from a modification of official openbsd port. Basically I accepted all cleanly applied patches and rejected the rest. The situation is much better but not satisfactory. -O0 there are still failing tests -O1 some tests don't crash and are passed, others crash -O2 some tests never end. I discovered that some assignments were entirely skipped with -O1. So I downloaded the NIST f77 testing suite at http://www.fortran-2000.com/ArnaudRecipes/fcvs21_f95.html and ran it with egfortran -O0 (all tests passed) and with egfortran -O1 (never ending jobs). I also tried to compile gcc 4.3.1, more or less with the same strategy but this also resulted in a never ending compilation while compiling the c++ system. Please, any information on a. current plans of gcc porting/debugging b. is this never-ending-job motif across different gcc versions an impression of mine or b.1 is there a reason why this behaviour shows on OpenBSD in particular b.2 where should one hunt for the origin of this kind of bug? Fulvio gcc-4.2.4.tgz Description: gcc 4.2.4 port
