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