Re: nn -- build without sbrk
I’m good with this.
--
arcf...@sacrideo.us | http://www.sacrideo.us | Skype: arcfide
From: Daniel Dickman
Sent: Sunday, November 4, 2018 2:05 PM
To: Aaron W. Hsu
Cc: ports@openbsd.org
Subject: nn -- build without sbrk
news/nn uses sbrk(2) to print some memory diagnostics. Delete this code to
eliminate use of sbrk.
ok?
Index: Makefile
===
RCS file: /cvs/ports/news/nn/Makefile,v
retrieving revision 1.16
diff -u -p -u -r1.16 Makefile
--- Makefile15 Apr 2017 14:11:35 - 1.16
+++ Makefile4 Nov 2018 20:02:48 -
@@ -2,7 +2,7 @@
COMMENT = menu-based Usenet newsreader
DISTNAME = nn-6.7.3
-REVISION = 3
+REVISION = 4
CATEGORIES = news
HOMEPAGE = http://www.nndev.org
Index: patches/patch-init_c
===
RCS file: patches/patch-init_c
diff -N patches/patch-init_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-init_c4 Nov 2018 20:02:48 -
@@ -0,0 +1,25 @@
+$OpenBSD$
+
+eliminate use of sbrk(2)
+
+Index: init.c
+--- init.c.orig
init.c
+@@ -566,17 +566,8 @@ print_debug_info(void)
+ struct mallinfo mallinfo(), mi;
+ #endif
+
+-static long prev_mem = 0;
+-longcur_mem;
+-
+ clrdisp();
+ tprintf("group=%s, nart=%ld\n\r", current_group->group_name, n_articles);
+-
+-cur_mem = (((long) sbrk(0)) - initial_memory_break) / 1024;
+-
+-tprintf("\nMemory usage: %ldk, previous: %ldk, change: %ldk\n\r",
+- cur_mem, prev_mem, cur_mem - prev_mem);
+-prev_mem = cur_mem;
+
+ #ifdef USE_MALLOC_H
+ mi = mallinfo();
Index: patches/patch-nn_c
===
RCS file: patches/patch-nn_c
diff -N patches/patch-nn_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-nn_c 4 Nov 2018 20:02:48 -
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+eliminate use of sbrk(2)
+
+Index: nn.c
+--- nn.c.orig
nn.c
+@@ -745,7 +745,6 @@ main(int argc, char *argv[])
+ int say_welcome = 0, cmd;
+ flag_type access_mode = 0;
+ char *mask = NULL;
+-initial_memory_break = (long) sbrk(0);
+
+ #ifdef USE_MALLOC_H
+
Re: scheme48 update
Okay by me. -- Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us Support my Open Work: http://www.gratipay.com/Co-dfns/ From: Marc Espie Sent: Saturday, May 27, 2017 4:52 PM To: arcf...@sacrideo.us Cc: ports@openbsd.org Subject: scheme48 update Here's a small update to scheme48. I'm not sure what changed, but this one actually builds and works with clang. 1.9 does segfault once built: ./build/build-usual-image . \ "`(cd . && pwd)`/scheme" "`pwd`/c" 'scheme48.image' './scheme48vm' \ './build/initial.image-64' Segmentation fault (core dumped) okay ? Index: Makefile === RCS file: /cvs/ports/lang/scheme48/Makefile,v retrieving revision 1.13 diff -u -p -r1.13 Makefile --- Makefile4 Apr 2016 16:09:09 - 1.13 +++ Makefile27 May 2017 20:49:31 - @@ -1,10 +1,10 @@ # $OpenBSD: Makefile,v 1.13 2016/04/04 16:09:09 naddy Exp $ COMMENT= Scheme Underground's implementation of R5RS +# ' -V= 1.9 +V= 1.9.2 DISTNAME= scheme48-$V -REVISION= 2 CATEGORIES=lang HOMEPAGE= http://www.s48.org/ Index: distinfo === RCS file: /cvs/ports/lang/scheme48/distinfo,v retrieving revision 1.4 diff -u -p -r1.4 distinfo --- distinfo6 Feb 2013 20:37:34 - 1.4 +++ distinfo27 May 2017 20:49:31 - @@ -1,2 +1,2 @@ -SHA256 (scheme48-1.9.tgz) = 3LqR0VC3SQ5hcO9PvUWgZboNjW4iiUY3naDR18ungmc= -SIZE (scheme48-1.9.tgz) = 3945425 +SHA256 (scheme48-1.9.2.tgz) = nEkhqQ6V2u4GfNLpzA/+CeEY9NoBwMAZjld8T0d1nfQ= +SIZE (scheme48-1.9.2.tgz) = 3951356 Index: patches/patch-Makefile_in === RCS file: /cvs/ports/lang/scheme48/patches/patch-Makefile_in,v retrieving revision 1.4 diff -u -p -r1.4 patch-Makefile_in --- patches/patch-Makefile_in 8 Feb 2013 14:39:50 - 1.4 +++ patches/patch-Makefile_in 27 May 2017 20:49:31 - @@ -2,9 +2,10 @@ $OpenBSD: patch-Makefile_in,v 1.4 2013/0 Fix fake-stage. Makefile.in.orig Thu Dec 27 11:46:24 2012 -+++ Makefile.inThu Feb 7 20:52:25 2013 -@@ -71,8 +71,8 @@ VERSION = 1.`cat $(srcdir)/build/minor-version-number` +Index: Makefile.in +--- Makefile.in.orig Makefile.in +@@ -72,8 +72,8 @@ VERSION = 1.`cat $(srcdir)/build/minor-version-number` RUNNABLE = scheme48 CONFIG_SCRIPT = scheme48-config MANPAGE = $(RUNNABLE).$(manext) @@ -15,7 +16,7 @@ Fix fake-stage. distdir = /tmp -@@ -469,7 +469,7 @@ doc/html/manual.html: doc/manual.pdf +@@ -470,7 +470,7 @@ doc/html/manual.html: doc/manual.pdf doc: doc/manual.pdf doc/manual.ps doc/html/manual.html @@ -24,12 +25,13 @@ Fix fake-stage. install-no-doc: enough dirs # install the VM -@@ -532,8 +532,6 @@ install-no-doc: enough dirs +@@ -532,9 +532,6 @@ install-no-doc: enough dirs + chmod +x $$config_script # install the external modules $(INSTALL_PROGRAM) $(EXTERNALS) $(DESTDIR)$(LIB)/ - # install the documentation +-# install the documentation - $(srcdir)/mkinstalldirs $(DESTDIR)$(docdir) -- $(INSTALL_DATA) $(srcdir)/COPYING $(docdir) +- $(INSTALL_DATA) $(srcdir)/COPYING $(DESTDIR)$(docdir) install-doc: dirs doc $(srcdir)/mkinstalldirs $(DESTDIR)$(docdir)
Re: news/nn overhaul
I don’t currently use OpenBSD on any of my main work machines, so I don’t use
the NN port right now, but I heartily approve of the overall simplification
enumerated below. Thank you!
--
Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us
Support my Open Work: http://www.gratipay.com/Co-dfns/
From: Christian Weisgerber
Sent: Friday, April 14, 2017 6:00 PM
To: ports@openbsd.org
Cc: Aaron W. Hsu
Subject: news/nn overhaul
Does anybody still use news/nn? Here's an overhaul of the port:
* Get rid of the MACHINE_ARCH dance and use a single m-openbsd.h
file. We only need to define a few basic types that are the same
on all our archs. NETWORK_BYTE_ORDER could be gotten from
, but it is only used with NETWORK_DATABASE, which we
don't define.
* Simplify the contorted substitutions in Makefile and use SUBST_CMD
where possible.
* clang throws a hissy fit over nested comments. Since fixing those
destroys the diff-ability of s-openbsd.h compared to s-template.h
anyway, I went ahead and compactified the file.
* clang on amd64 with our binutils ld produced a relocation error
for BC in term.c. I think these are globals that are already
defined in libtermlib, and thus should be declared extern.
Very lightly tested on arm64.
Index: Makefile
===
RCS file: /cvs/ports/news/nn/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile1 Sep 2016 10:53:27 - 1.15
+++ Makefile14 Apr 2017 21:26:28 -
@@ -1,8 +1,8 @@
# $OpenBSD: Makefile,v 1.15 2016/09/01 10:53:27 jasper Exp $
-COMMENT = No News is Good News (Fast CLI Point & Read Newsreader)
+COMMENT = menu-based Usenet newsreader
DISTNAME = nn-6.7.3
-REVISION = 2
+REVISION = 3
CATEGORIES = news
HOMEPAGE = http://www.nndev.org
@@ -23,36 +23,12 @@ USE_GROFF = Yes
NO_TEST = Yes
MAKE_ENV = CC="${CC}"
-.if "${MACHINE_ARCH}" == "alpha"
-MFILE =m-alpha.h
-.elif "${MACHINE_ARCH}" == "hppa"
-MFILE =m-hp9000.h
-.elif "${MACHINE_ARCH}" == "m88k"
-MFILE =m-m88000.h
-.elif "${MACHINE_ARCH}" == "powerpc"
-MFILE =m-powerpc.h
-.elif "${MACHINE_ARCH}" == "mips64"
-MFILE =m-mips.h
-.elif "${MACHINE_ARCH}" == "sparc64"
-MFILE =m-sparc.h
-.else
-MFILE =m-i80386.h
-.endif
-
pre-configure:
- sed -e "s/OBSD_PREFIX/${PREFIX:S/\//\\\//g}/" \
- -e "s/m-i80386\.h/${MFILE}/" \
- ${FILESDIR}/config.h > ${WRKSRC}/config.h
- cp ${FILESDIR}/s-openbsd.h ${WRKSRC}/conf/s-openbsd.h
-
-pre-install:
- sed -e "s/\/usr\/local/${PREFIX:C/\//\\\//g}/" \
- ${WRKSRC}/inst > ${WRKSRC}/inst.new
- mv ${WRKSRC}/inst ${WRKSRC}/inst.old
- mv ${WRKSRC}/inst.new ${WRKSRC}/inst
- chmod 755 ${WRKSRC}/inst
+ ${SUBST_DATA} ${FILESDIR}/config.h ${WRKSRC}/config.h
+ cp ${FILESDIR}/[ms]-openbsd.h ${WRKSRC}/conf/
do-install:
- cd ${WRKSRC} && echo `pwd` && ./inst n
+ perl -pi.bak -e 's:${TRUEPREFIX}:${PREFIX}:g' ${WRKSRC}/inst
+ cd ${WRKSRC} && ./inst n
.include
Index: files/config.h
===
RCS file: /cvs/ports/news/nn/files/config.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 config.h
--- files/config.h 17 Nov 2008 08:42:13 - 1.1.1.1
+++ files/config.h 14 Apr 2017 21:26:28 -
@@ -122,7 +122,7 @@
* conf/m-template.h as a starting point for writing you own.
*/
-#include "m-i80386.h"
+#include "m-openbsd.h"
/* OWNERSHIP ***
@@ -173,10 +173,10 @@
*(= LIB_DIRECTORY/Log if undefined).
*/
-#define BIN_DIRECTORY "OBSD_PREFIX/bin"
-#define LIB_DIRECTORY "OBSD_PREFIX/lib/nn"
-#define CLIENT_DIRECTORY "OBSD_PREFIX/libexec/nn"
-#define HELP_DIRECTORY "OBSD_PREFIX/share/doc/nn"
+#define BIN_DIRECTORY "${PREFIX}/bin"
+#define LIB_DIRECTORY "${PREFIX}/lib/nn"
+#define CLIENT_DIRECTORY "${PREFIX}/libexec/nn"
+#define HELP_DIRECTORY "${PREFIX}/share/doc/nn"
#define TMP_DIRECTORY "/tmp"
#define LOG_FILE "/var/log/nn"
@@ -240,13 +240,13 @@
* DAEMON_MAN - nnmaster
*/
-#define USER_MAN_DIR "OBSD_PREFIX/man/man1"
+#define USER_MAN_DIR "${PREFIX}/man/man1"
#define USER_MAN_SECTION "1"
-#define SYS_MAN_DIR"OBSD_PREFIX/man/man1"
+#define SYS_MAN_DIR&
Re: news/nn diff
On Fri, Mar 11, 2016 at 02:07:23PM +0100, Jérémie Courrèges-Anglas wrote: > this is a diff I've had since years and I never went to try it. > Tests welcome. > > Index: Makefile > === > RCS file: /cvs/ports/news/nn/Makefile,v > retrieving revision 1.12 > diff -u -p -r1.12 Makefile > --- Makefile 24 Nov 2015 09:11:05 - 1.12 > +++ Makefile 11 Mar 2016 13:02:30 - > @@ -2,7 +2,7 @@ > > COMMENT =No News is Good News (Fast CLI Point & Read Newsreader) > DISTNAME = nn-6.7.3 > -REVISION = 1 > +REVISION = 2 > CATEGORIES = news > HOMEPAGE = http://www.nndev.org > > Index: files/s-openbsd.h > === > RCS file: /cvs/ports/news/nn/files/s-openbsd.h,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 s-openbsd.h > --- files/s-openbsd.h 17 Nov 2008 08:42:13 - 1.1.1.1 > +++ files/s-openbsd.h 11 Mar 2016 13:02:30 - > @@ -59,7 +59,7 @@ > * Define if a signal handler has type void (see signal.h) > */ > > -/* #define SIGNAL_HANDLERS_ARE_VOID/* */ > +#define SIGNAL_HANDLERS_ARE_VOID/* */ > > /* > * Define if signals must be set again after they are caught Thanks for this. I've not been keeping up on this, but if this is in fact the way that OpenBSD does signal handlers, then that's a good patch. As long as tests from others turn out okay, it has my okay. -- Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us signature.asc Description: PGP signature
Re: 4.6-stable ports
On Thu, 22 Oct 2009 21:06:30 -0400, William Yodlowsky b...@openbsd.rutgers.edu wrote: Yes, -stable packages will be provided, but I can't say which architectures yet; some details are still being worked out. I saw the announcement, and I was amazed, to say the least. I was also exuberantly happy, but I was wondering if I missed a bigger write-up explaining how this came about? Did someone new step-up and provide the effort and sweat? Aaron W. Hsu -- Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive. -- C. S. Lewis
Majordomo distfile missing for OPENBSD_4_5?
Hello all, Is there a reason the majordomo-1.94.5.tgz distfile seems to be missing from the mirrors (at least, the ones used by the 'make install' target)? Am I just crazy? Aaron W. Hsu -- Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive. -- C. S. Lewis
Re: opera 10 beta with unite
On Sat, 27 Jun 2009 18:14:51 -0400, Theo de Raadt dera...@cvs.openbsd.org wrote: I say so. Is that enough? Yep. -- Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive. -- C. S. Lewis
Re: opera 10 beta with unite
On Sat, 27 Jun 2009 07:00:48 -0400, frantisek holop min...@obiit.org wrote: opera is commercial software. there is no point in asking for a change of license or to go open source. I do not think it is unreasonable to ask and to let a company, which creates commercial software, to evaluate their licensing in order to make their products more attractive to consumers. I think that permitting distributions via packages and OpenBSD is not such a hard request, though there may be valid reasons for not allowing such. Asking them to go Open Source is another matter entirely. Sincerely, Aaron W. Hsu -- Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive. -- C. S. Lewis
Re: opera 10 beta with unite
Hello Stuart, Thanks for your perspective. On Sat, 27 Jun 2009 05:39:51 -0400, Stuart Henderson s...@spacehopper.org wrote: Asking them to change license while also asking to provide binaries for another OS is far too much in one go. Besides, adding a new OS is just a technical and support issue, changing license is a very pervasive legal issue, often involving contracts with other companies etc. Usually a much more difficult thing to get changed. You are probably right there, but on the other hand, someone suggested that perhaps getting Opera distributed by default with the Operating System would be enough motivation for them to make a port of it. I don't know. I think that both goals should be pursued, but I don't know how and in which order. I doubt that OpenBSD would replace Firefox with Opera on the CD-ROMs, but, hehe, I bet that would make Opera take notice. Maybe not? Sincerely, Aaron W. Hsu -- Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive. -- C. S. Lewis
Re: UPDATE: misc/magicpoint
I haven't had a lot of time to think about this... From matthieu.he...@laas.fr Fri May 22 16:56:02 2009 joshua stein wrote: if this update doesn't break presentations like it did before (which is why it was reverted to 1.09), then remove the hack comment and you can avoid setting pkgname. It probably still does, since the breakage (for deraadt and henning) is caused by magicpoint switching to more modern font handling, causing the layout of slides to change enough to make some existing slides unreadable. We'll probably need 2 ports a legacy and a current one. Later magicpoint versions aren't broken because they changed the way they rendered fonts to use a more modern method. They may break old presentations because of it, though, and that's a valid concern. It makes sense to me to have two versions if this is the case. Otherwise we're basically freezing magicpoint for the sake of backwards compatibility, which, while important, shouldn't be the only consideration in my humble opinion. If the rest of you disagree, *hides* okay! :-) -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
UPDATE: misc/magicpoint
The following patch updates magicpoint to version 1.13a. Please test.
Also, the update requires patches/patch-{draw,parse,tfont}_c to be
removed.
--
Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us
Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else. -- Frederic Bastiat
+++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
Index: misc/magicpoint/Makefile
===
RCS file: /cvs/ports/misc/magicpoint/Makefile,v
retrieving revision 1.48
diff -u misc/magicpoint/Makefile
--- misc/magicpoint/Makefile18 Feb 2009 08:15:50 - 1.48
+++ misc/magicpoint/Makefile22 May 2009 15:12:57 -
@@ -2,9 +2,9 @@
COMMENT= X11-based presentation tool
-DISTNAME= magicpoint-1.09a
+DISTNAME= magicpoint-1.13a
# hack
-PKGNAME= magicpoint-1.11bp8
+PKGNAME= magicpoint-1.13a
CATEGORIES=misc productivity
MASTER_SITES= ftp://sh.wide.ad.jp/WIDE/free-ware/mgp/
@@ -15,21 +15,21 @@
PERMIT_DISTFILES_CDROM=Yes
PERMIT_DISTFILES_FTP= Yes
-WANTLIB= c ICE jpeg lcms m SM util \
- Xt Xau Xdmcp Xmu Xext X11 Xtst z
+WANTLIB += ICE SM X11 Xau Xdmcp Xext Xft Xmu Xrender Xt Xtst c
+WANTLIB += expat fontconfig freetype m util z jpeg lcms
-# plus sign is for localized (i.e. Japanese) version
-LIB_DEPENDS+= ttf.=1::print/freetype \
- png.=2::graphics/png \
- mng::graphics/libmng \
- ungif.=5::graphics/libungif
-RUN_DEPENDS+= ::graphics/netpbm \
- ::print/ghostscript/gnu-fonts
+LIB_DEPENDS+= ttf.=1::print/freetype \
+ png.=2::graphics/png \
+ mng::graphics/libmng \
+ ungif.=5::graphics/libungif
+RUN_DEPENDS+= ::graphics/netpbm \
+ ::print/ghostscript/gnu-fonts
+
+# plus sign is for localized (i.e. Japanese) version
MODULES= devel/gettext
USE_X11= Yes
-AUTOCONF_VERSION=2.13
CONFIGURE_STYLE=autoconf gnu imake no-autoheader
CONFIGURE_ARGS=--disable-vflib
CONFIGURE_ARGS+= --enable-gif
Index: misc/magicpoint/distinfo
===
RCS file: /cvs/ports/misc/magicpoint/distinfo,v
retrieving revision 1.5
diff -u misc/magicpoint/distinfo
--- misc/magicpoint/distinfo5 Apr 2007 17:41:07 - 1.5
+++ misc/magicpoint/distinfo22 May 2009 15:12:57 -
@@ -1,5 +1,5 @@
-MD5 (magicpoint-1.09a.tar.gz) = T8SL0pKnyLGqtla/Lwr0fQ==
-RMD160 (magicpoint-1.09a.tar.gz) = Lulu7ZyeMdbFmUR9QhrjGUg8Nhc=
-SHA1 (magicpoint-1.09a.tar.gz) = KQP3xCow1Vhnf8GpNgf+f8jB/A8=
-SHA256 (magicpoint-1.09a.tar.gz) = woQZdNFfyvvJXlIiqnHiv+VIeFqgiRsewzMB27pjfww=
-SIZE (magicpoint-1.09a.tar.gz) = 816234
+MD5 (magicpoint-1.13a.tar.gz) = 68QDmClW6RirMnxUqQtE4A==
+RMD160 (magicpoint-1.13a.tar.gz) = Bn197juQ7DVJddmtTqDA30jMoZE=
+SHA1 (magicpoint-1.13a.tar.gz) = K8ZirQpILUJXh2YlihQ7BqRxiuM=
+SHA256 (magicpoint-1.13a.tar.gz) = IF5nUuPLAkvM4Fg7Q9r8m4lJDAAW2qkdJIaJHtzyz8E=
+SIZE (magicpoint-1.13a.tar.gz) = 890670
Index: misc/magicpoint/patches/patch-configure_in
===
RCS file: /cvs/ports/misc/magicpoint/patches/patch-configure_in,v
retrieving revision 1.5
diff -u misc/magicpoint/patches/patch-configure_in
--- misc/magicpoint/patches/patch-configure_in 3 Nov 2005 14:46:01 -
1.5
+++ misc/magicpoint/patches/patch-configure_in 22 May 2009 15:12:57 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-configure_in,v 1.5 2005/11/03 14:46:01 espie Exp $
configure.in.orig Tue May 22 08:09:42 2001
-+++ configure.in Thu Nov 3 15:00:38 2005
-@@ -103,6 +103,8 @@ if test $mgp_use_freetype = yes; the
+--- configure.in.orig Fri Dec 28 15:31:26 2007
configure.in Thu Apr 23 12:54:58 2009
+@@ -125,6 +125,8 @@ if test $mgp_use_freetype = yes; then
ac_cv_ft_include=$dir/include
elif test -d $dir/include/freetype -a -f
$dir/include/freetype/freetype.h; then
ac_cv_ft_include=$dir/include/freetype
@@ -10,25 +10,16 @@
fi
if test $ac_cv_ft_lib != no -a $ac_cv_ft_include != no;
then
LIBS=-L$ac_cv_ft_lib $LIBS
-@@ -118,7 +120,7 @@ if test $mgp_use_freetype = yes; the
+@@ -139,7 +141,7 @@ if test $mgp_use_freetype = yes; then
+ AC_MSG_RESULT($ac_cv_ft_lib and $ac_cv_ft_include)
fi
- fi
- if test $mgp_use_freetype = yes; then
-- LIBS=-L$ac_cv_ft_lib $LIBS
-+ LIBS=-L$ac_cv_ft_lib $LIBS -liconv
- OPTFLAGS=-I$ac_cv_ft_include $OPTFLAGS
- DEPLIBS=$ac_cv_ft_lib/$ac_cv_ft_libpath $DEPLIBS
- AC_CHECK_LIB(intl, dgettext)
-@@ -244,7 +246,7 @@ if test $mgp_use_freetype = yes; the
- fi
-
- for i in /usr/pkg /usr/local /usr; do
-- if test -f $i/include/png.h; then
-+ if test -f $i/include/libpng/png.h; then
- if test -f $i/lib
SUBMITTING, again: lang/petite lang/chez
Hey All, Does anyone want to actually commit these ports to OpenBSD? Was there anything else wrong with them? I know some people are busy, but... :-) -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ gzkkX0YRAtTq.gz Description: An object packed by metasend gzjrgZ0MEb3x.gz Description: An object packed by metasend
Re: Extending libfprint
Hey Toby, From weing...@tepid.org Fri Apr 3 16:07:44 2009 Subject: Re: Extending libfprint If any of you guys can track down the programming documentation, that would be a good start to having this type of device supported... Just a thought, but it seems that my Lenovo T500 has an AES2810 from AuthenTec. Checking their website, it appears that one of the things they do is provide SDKs to interested parties. I have not figured out what counts as a qualifying request to get the SDK, but I just thought I would ask whether anyone else has tried to obtain the documentation directly from them in this form and whether it works if they did get it? Is Authentec just another one of those companies which refuse to give out the documentation without a host of NDAs and the like? -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
Extending libfprint
Are any developers currently working on fingerprint drivers for Lenovo laptops? I notice that the AuthenTec readers are listed as unsupported on libfprint's home page, but maybe some OpenBSD developers have taken an interest? -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
Re: security support
Ian, From kaosa...@tpg.com.au Tue Mar 31 09:08:59 2009 From: Ian McWilliam kaosa...@tpg.com.au To: ports@openbsd.org ports@openbsd.org Subject: Re: security support [...] Just what grabs peoples fancy with regard -stable ports??? I would say that proper security/stability-only patches sent to ports@ would go a long way, without putting the burden on anyone beside the maintainers of the ports. That may be hard for each maintainer, but at least the work is somewhat distributed. Later, if someone wants to maintain the -STABLE branch of the CVS tree, well, that's well and good. Not every maintainer would have to do this either, but it would be nice if they did. ;-) -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
Re: security support
David, Thanks for your message... As a practical matter, I would prefer to see that information featured prominently in the documentation, rather than strongly encouraging people to rely on packages (http://www.openbsd.org/faq/faq15.html#PkgVsPorts). I don't feel that it's responsible to discourage users from using ports when doing so, along with manual backporting, is the only supported way to maintain a patched system (where -current is not appropriate). Many people aren't competent enough to backport their security patches. People usually think that they have to have all the latest patches, which is all well and good, but if they don't know how to run ports (very likely) and they don't know enough about the ports system to backport the security patches, they are very likely to make mistakes, and then someone is going to have to support them. It's much easier for people in -STABLE to just run the stable packages. That is still probably the best advice for most people. If they want to run other stuff, they will probably be able to do it without needing an FAQ entry, since all this information is already out there. On the other hand, I don't think anyone would complain if there were someone tracking the security updates and making sure that they got in to -STABLE or at least that the patches were sent to po...@. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
NEW: lang/chez
The following is a package for Chez Scheme users on OpenBSD, which deals with issues such as FFI linking. This is for the commercial compiler, whereas petite-chez is the free interpreter. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ chez.tar.gz Description: chez.tar.gz
Re: security support
David, Thank you for your message... Aaron W. Hsu wrote: but if you are really concerned about security, pretty much your only hope is to either run -CURRENT or track the security updates and backport them yourself. And then adds: My advice to you would be to just follow -STABLE. So, it follows that your advice would be to not be really concerned about security? In this case, yes. The problem description was a machine on dial-up which was on the network for only one hour per day. This would make it impractical for the user of such a system to download new snapshots or pull in source code changes from CVS fast enough to get real work done after this. The only possible way that the user of such a system could work this in, would be to track the patches himself carefully on ports@ while maintaining the -STABLE branch, and then backport where necessary. Doing so is going to be very troublesome, and likely not worth the effort for this machine. However, like I said, if it really is a concern, then backporting the security issues is a perfectly viable option; doing so will significantly cut into the one hour per day internet allotment. Most people who use OpenBSD are probably doing so at least in part because they are very concerned about security. Doesn't that make this disconnect curious, to say the least? The main -STABLE system is still going to be secure, and as long as the ports are chosen wisely, most of them should be fairly secure as well. Certainly, they will be good enough in most cases for the standard desktop user who is planning to do normal work and has their head about them. Not that it would not be nice to have fixes backported on a more reliable basis, but as has been noted in the lists before, this isn't going to happen without some more people. This thread doesn't inspire any more confidence in -stable ports than I have gained from the documentation, which has led me to conclude that I should generally compile and manage my own software on OpenBSD. A stable branch is generally understood to mean critical security patches only, not unmaintained ... That sounds remarkably troll-ish, but nonetheless, of course one shouldn't have a great deal of confidence in the -STABLE branch of the ports when it comes to security backports, because they are officially unmaintained. Why? No one is there to do it, as has been mentioned before in the lists. They don't have the time to maintain them properly. Going the other way and saying that you should not use the ports system at all is crazy. You can make the security updates yourself as easily as you can manage all the software without the help of the ports framework, so it is still better to run -STABLE and make the necessary updates when they are required. The OpenBSD project has been very clear about what -STABLE means. When it comes to the software distribution, it does mean that critical patches are made, but the more important guarantee of STABLE is that the interfaces, programs, and APIs will not change randomly and unexpectedly, and things will generally behave in a reliable manner. If this is what you implied by the only term above, well, okay, but the statement above may say more than is necessary, and certainly says more than what the -STABLE ports are. The -STABLE ports right now has no one who can care for them, and thus, they go mostly unmaintained except for those places where the maintainers of the individual packages care to handle them, and even then, this may not happen in a nice way. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
Re: security support
Douglas, Could someone point me to the appropriate docs or info on the mechanism for keeping the packages/ports of a stable OBSD system up-to-date? Occassionally I see a security patch backported to the -STABLE branch, but if you are really concerned about security, pretty much your only hope is to either run -CURRENT or track the security updates and backport them yourself. They may not be too hard to do, but it's not just as easy as pkg_add -ui. The ports I maintain rarely have updates of that nature, so I don't usually have to deal with these issues, but some ports have to deal with it much more often. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
Re: security support
Doug, I only have the phone for about an hour a day, and the computer for a couple of hours. I don't want to spend all that time just keeping the system up-to-date and not getting any real work done. My advice to you would be to just follow -STABLE. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
PING? lang/petite-chez
Since the ports tree is unfrozen now, does anyone have any objections to adding petite-chez in now that the licensing issues have been resolved? Before the next release I'll probably be able to submit an update with better licensing, but until then, I think it would be nice to have this in for people to use this nice Scheme system. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ petite-chez.tar.gz Description: petite-chez.tar.gz
Re: NEW: lang/petite-chez
In regards to the following, this submission fixes the licensing issues to be a bit safer. On 11-Feb-2009 Stuart Henderson wrote: On 2009/02/11 15:29, Will Maier wrote: I also find the license confusing. For convenience, here's the meat: 1. License Grant Cadence Research Systems (hereinafter, Cadence) grants you (hereinafter, Licensee) a nonexclusive license to use Petite Chez Scheme and associated documentation (hereinafter, Licensed Product), to combine the Licensed Product with other products to form Aggregate Products, and to redistribute the Licensed Product or Aggregate Products without royalty. All Aggregate Products must include the Licensed Product in its entirety. No payment may be received by Licensee for redistribution of the Licensed Product, although nothing in this Agreement shall prevent Licensee from receiving payment for other portions of Aggregate Products. Any redistribution of the Licensed Product or Aggregate Products is subject to all restrictions set forth in this Agreement. Licensee may not reverse compile, disassemble, or otherwise reverse engineer the Licensed Product. The port currently sets PERMIT_* = Yes. Does that fit with the above? IMO this should have PERMIT_*_CDROM=no, combine is not well defined in the license and is I think ambiguous. in its entirety is hard since we don't actually put distfiles on the CDs. I'm not even sure about PERMIT_PACKAGE_FTP since it doesn't permit modification (the Licensed Product includes the associated documentation, and the port patches this). The author may be intending something other than what is written, but that is irrelevant, what is relevant is how someone else sometime down the line might interpret it. (And that is why the standard /usr/share/misc/license.template used in OpenBSD is so good; there is very little room for legal wriggling and misinterpretation). I have spoken with the author regarding these issues, and he indicated that he is interested in this and wants to deal with it, but that he is swamped and will not be able to deal with it until early Summer, so I've adjust the licensing to be on the safe side for now. I think there should be nothing else wrong with it. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ petite-chez.tar.gz Description: petite-chez.tar.gz
Re: opera gcc295 more stable?
Hey Antoine, Thanks a bunch for your work... On 11-Feb-2009 Antoine Jacoutot wrote: It seems the gcc295 version of opera is much more stable for me after several testings on a default !mp install (no async dns tweaks needed). I have tried both with and without the async dns tweaks as well as both the 295 an the gcc4 versions, and they all freeze within three minutes of use. Dmesg below: -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ OpenBSD 4.5-beta (GENERIC.MP) #4: Thu Feb 12 12:53:57 EST 2009 r...@onyx.local:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz (GenuineIntel 686-class) 2.53 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,D S,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SS E3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR real mem = 2088005632 (1991MB) avail mem = 2010619904 (1917MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 10/30/08, BIOS32 rev. 0 @ 0xfdc80, SMBIOS rev. 2.4 @ 0xe0010 (74 entries) bios0: vendor LENOVO version 6FET50WW (1.20 ) date 10/30/2008 bios0: LENOVO 2081CTO acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S 3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: unknown i686 EBL_CR_POWERON value 3 (0x424c0800) cpu0: apic clock running at 266MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz (GenuineIntel 686-class) 2.53 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,D S,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SS E3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2 acpicpu1 at acpi0: C3, C2 acpitz0 at acpi0: critical temperature 127 degC acpitz1 at acpi0: critical temperature 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4623 serial 4193 type LION oem SONY acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock at acpi0 not configured acpivideo at acpi0 not configured acpivideo at acpi0 not configured bios0: ROM list: 0xc/0x1! 0xd/0x1000 0xd1000/0x1000 0xd2000/0x1000 0xde000/0x1800! 0xe/0x1 cpu0: EST: unknown system bus clock pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel GM45 Host rev 0x07 ppb0 at pci0 dev 1 function 0 Intel GM45 PCIE rev 0x07: apic 1 int 16 (irq 11) pci1 at ppb0 bus 1 ATI Mobility Radeon HD 3650 rev 0x00 at pci1 dev 0 function 0 not configured vga1 at pci0 dev 2 function 0 Intel GM45 Video rev 0x07 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1: apic 1 int 16 (irq 11) drm0 at inteldrm0 Intel GM45 HECI rev 0x07 at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 Intel GM45 PT IDER rev 0x07: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wir ed to native-PCI pciide0: using apic 1 int 18 (irq 11) for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) Intel GM45 AMT SOL rev 0x07 at pci0 dev 3 function 3 not configured em0 at pci0 dev 25 function 0 Intel ICH9 IGP M AMT rev 0x03: apic 1 int 20 (irq 11), address 00:1c:25:9c:48:06 uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x03: apic 1 int 20 (irq 11) uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x03: apic 1 int 21 (irq 11) uhci2 at pci0 dev 26 function 2 Intel 82801I USB rev 0x03: apic 1 int 22 (irq 11) ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x03: apic 1 int 23 (irq 11) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 82801I HD Audio rev 0x03: apic 1 int 17 (irq 11) azalia0: RIRB time out azalia0: codecs: Conexant CX20561, Conexant/0x2c06, using Conexant CX20561 audio0 at azalia0 ppb1 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x03
Re: opera gcc295 more stable?
Antoine, On 13-Feb-2009 Antoine Jacoutot wrote: Stuart is right. I said !mp install. Whoops, I totally missed that. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
NEW: lang/petite-chez
Attached is a port for Petite Chez Scheme, a high-speed threaded Scheme interpreter. This is a rock-solid Scheme system that works great, and I would love to see it in Ports before the freeze. It's especially nice since OpenBSD is one of the officially supported platforms. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ petite-chez.tar.gz Description: petite-chez.tar.gz
RESUBMIT: lang/petite-chez
This is a resubmission of Petite Chez Scheme. It cleans up the man page and puts the examples in the right place. It also tentatively uses normal permissions for installation of the executables. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ petite-chez.tar.gz Description: petite-chez.tar.gz
Re: NEW: lang/petite-chez
Hey Will, Thanks for your quick comments... On 11-Feb-2009 Will Maier wrote: On Wed, Feb 11, 2009 at 03:47:15PM -0500, Aaron W. Hsu wrote: Attached is a port for Petite Chez Scheme, a high-speed threaded Scheme interpreter. This is a rock-solid Scheme system that works great, and I would love to see it in Ports before the freeze. It's especially nice since OpenBSD is one of the officially supported platforms. Neat! Some comments: * the examples in lib/ should probably move to share/examples/petite-chez; * there are no regress tests, so set NO_REGRESS; * the petite binary is installed with mode 551, which is silly; * petite.1's SYNOPSIS makes it sound like petite-chez installs a scheme compiler, too. I have attached a port which fixes these issues. I don't feel strongly about changing the SYNOPSIS, though I think it's misleading as-is. I'm open to more readily comprehensible versions. I also find the license confusing. For convenience, here's the meat: 1. License Grant Cadence Research Systems (hereinafter, Cadence) grants you (hereinafter, Licensee) a nonexclusive license to use Petite Chez Scheme and associated documentation (hereinafter, Licensed Product), to combine the Licensed Product with other products to form Aggregate Products, and to redistribute the Licensed Product or Aggregate Products without royalty. All Aggregate Products must include the Licensed Product in its entirety. No payment may be received by Licensee for redistribution of the Licensed Product, although nothing in this Agreement shall prevent Licensee from receiving payment for other portions of Aggregate Products. Any redistribution of the Licensed Product or Aggregate Products is subject to all restrictions set forth in this Agreement. Licensee may not reverse compile, disassemble, or otherwise reverse engineer the Licensed Product. The port currently sets PERMIT_* = Yes. Does that fit with the above? Knowing and working with the author, I am sure that the intent is to permit redistribution of Petite Chez Scheme with all commercial applications which rely on it. The OpenBSD distribution can be considered an aggregate product which I believe permits the distribution of Petite Chez Scheme as a part of the product, where the complete distribution, in the form of a CDROM, may be sold for profit. Selling of the Petite Chez Scheme distribution itself is not permitted, but so long as there is not explicit cost for the Scheme system, then we're fine. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ petite-chez.tar.gz Description: petite-chez.tar.gz
RESUBMIT: lang/petite-chez (Hopefully Last)
Whoops! Sorry guys for all the spam. This should be the last one that I can see. I forgot a WANTLIB. Sorry! -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ petite-chez.tar.gz Description: petite-chez.tar.gz
RESUBMIT: lang/petite-chez (Cleanup + Improvements)
The attached resubmission of Petite Chez Scheme improves on a number of things compared to my previous submission: * Fixes a packing list issue and adds a conflict with chez * Links dynamically against OpenBSD's libz instead of static internal version. * Fixes a bug with shared and reentrant objects that are loaded using LOAD-SHARED-OBJECT. Thanks to Will for his suggestions! -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ petite-chez.tar.gz Description: petite-chez.tar.gz
Porting commercial applications
What's the proper thing to do when you want to have a port that can't be obtained normally via the internet? Is it worth it to publish the port? In other words, Petite Chez is easy enough to port, but would a corrolary Chez Scheme (commercial) port be welcome? How would I set up the fetching, since the user would have to have the distfile already from purchasing it? -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
RESUBMIT (Bah!): lang/petite-chez
Quality control ain't what it used to be... This latest one fixes a stupid conflict mispelling. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ petite-chez.tar.gz Description: petite-chez.tar.gz
Re: fonts category anyone?
Frantisek, On 02-Feb-2009 frantisek holop wrote: cvs history for scaffolding makefiles which support _only and only_ the latest and greatest and only and only in -current dont seem like terribly important information to me. it's not like we are talking about important C files like in src or xenocera. hands up who would be distressed if the initial import for liberty fonts got lost? especially the fonts, these are pretty simple ports anyway. Sorry, I have to say I would not want to lose editing history on any file. For example, I run an older port of some of my stuff, and if someone just removed all the old editing history, I would be in trouble. However, I have seen CVS directories and files moved without losing the history, so I don't think it is technically impossible, but I would guess it is a question of whether it is so inconvenient that the trouble outweighs the benefit, but in this case, I would lean towards saying that the trouble *is* worth it. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
Re: fonts category anyone?
Antoine, On 02-Feb-2009 Antoine Jacoutot wrote: if possible, e.g. because most of the time the categories are sensible--except the fonts (and possible others too). It has been discussed *billion* times! If one day we have a 'cvs move' function, we may consider it. It was my understanding that even though CVS does not have a specific move command, it is still physically and technically possible to move CVS files around without losing the editing history [1]. Obviously, there must be some gotchas (like having working copies that still think the old way), but these can't be bad enough to discourage a good design change just because it's inconvenient in some respect, can it? If it really is *that* bad, then I can understand, but I've moved CVS files around before, and it wasn't anything that was going to kill a person. [1] http://synthcode.com/code/cvsmove -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++
UPDATE: lang/scheme48
Update Email address for Maintainer. -- Aaron W. Hsu arcf...@sacrideo.us | http://www.sacrideo.us Government is the great fiction, through which everybody endeavors to live at the expense of everybody else. -- Frederic Bastiat +++ ((lambda (x) (x x)) (lambda (x) (x x))) ++ Index: Makefile === RCS file: /cvs/ports/lang/scheme48/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile --- Makefile19 Aug 2008 22:20:40 - 1.3 +++ Makefile14 Dec 2008 20:27:50 - @@ -2,13 +2,13 @@ COMMENT= Scheme Underground's implementation of R5RS -V= 1.8 +V= 1.8p0 DISTNAME= scheme48-$V CATEGORIES=lang HOMEPAGE= http://www.s48.org/ -MAINTAINER=Aaron Hsu arcf...@sacrificumdeo.net +MAINTAINER=Aaron Hsu arcf...@sacrideo.us # 3-clause BSD PERMIT_PACKAGE_CDROM= Yes
Enlighentment 17 Update?
Is anyone working on updating the e17 port to the latest snapshot? Aaron Hsu
PATCH: devel/glib2
The following patch fixes an (apparently known) issue with glib2
wherein the port cannot be installed or built on a system with an
existing, incompatible glib2 version (i.e. -- older package)
installed, because the build would catch the older libraries rather
than the newly built ones. This patch works around this by fiddling
with LDFLAGS to catch the new libraries.
A better solution would be for the system to build correctly without
having to fiddle with LDFLAGS at all, but this works at least on
my system. Testing welcomed.
Aaron Hsu
--- Makefile.orig Wed Nov 5 03:13:27 2008
+++ MakefileWed Nov 5 03:19:27 2008
@@ -54,7 +54,12 @@
--with-pcre=system \
--disable-fam
CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include \
- LDFLAGS=-L${LOCALBASE}/lib
+ LDFLAGS=-L${WRKSRC}/glib/.libs \
+ -L${WRKSRC}/gthread/.libs \
+ -L${WRKSRC}/gio/.libs \
+ -L${WRKSRC}/gobject/.libs \
+ -L${WRKSRC}/gmodule/.libs \
+ -L${LOCALBASE}/lib
# Port has /usr/local hardcoded, we prefer ${LOCALBASE}
pre-build:
Problem doing an upgrade from Ports on Glib2
I seem to be having some trouble with the glib2 port. I've tried a few things, but it seems to be picking up my old installation somehow. Here's is a history: /usr/local/bin/libtool --tag=CC --mode=link cc -O2 -pipe -Wall -L/usr/local/lib -o markup-subparser markup-subparser.o ../../glib/libglib-2.0.la -lintl -liconv cc -O2 -pipe -Wall -o .libs/markup-subparser markup-subparser.o -L/usr/local/lib -L../../glib/.libs -lglib-2.0 -lpcre -lintl -liconv -Wl,-rpath,/usr/local/lib /usr/local/lib/libglib-2.0.so.1600.2: warning: vsprintf() is often misused, please use vsnprintf() /usr/local/lib/libglib-2.0.so.1600.2: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/libglib-2.0.so.1600.2: warning: strcat() is almost always misused, please use strlcat() markup-subparser.o(.text+0xb8): In function `subparser_start': /usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/glib/tests/markup-sub parser.c:72: undefined reference to `g_markup_parse_context_push' markup-subparser.o(.text+0xcb): In function `subparser_end': /usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/glib/tests/markup-sub parser.c:82: undefined reference to `g_markup_parse_context_pop' markup-subparser.o(.text+0x185): In function `replay_parser_start': /usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/glib/tests/markup-sub parser.c:128: undefined reference to `g_markup_parse_context_push' markup-subparser.o(.text+0x1a8): In function `replay_parser_end': /usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/glib/tests/markup-sub parser.c:141: undefined reference to `g_markup_parse_context_pop' collect2: ld returned 1 exit status gmake[4]: *** [markup-subparser] Error 1 gmake[4]: Leaving directory `/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/glib/tests' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/glib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/glib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/devel/glib2 (line 2169 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/devel/glib2 (line 1424 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/devel/glib2 (line 1964 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/devel/glib2 (line 2980 of /usr/ports/infrastructure/mk/bsd.port.mk). And my attempt to remove that old library: cc -O2 -pipe -Wall -o .libs/memory-output-stream memory-output-stream.o -L/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/glib/.libs -L/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/gobject/.libs -L/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/gmodule/.libs -L/usr/local/lib -L../../glib/.libs -L../../gobject/.libs -L../../gio/.libs -lgio-2.0 -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -lpcre -lintl -liconv -Wl,-rpath,/usr/local/lib /usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/glib/.libs/libglib-2.0.so.1800.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/local/lib/libgio-2.0.so.1600.2: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/libgio-2.0.so.1600.2: warning: strcat() is almost always misused, please use strlcat() /usr/bin/ld: warning: libgmodule-2.0.so.1600.2, needed by /usr/local/lib/libgio-2.0.so.1600.2, may conflict with libgmodule-2.0.so.1800.0 /usr/bin/ld: warning: libgobject-2.0.so.1600.2, needed by /usr/local/lib/libgio-2.0.so.1600.2, may conflict with libgobject-2.0.so.1800.0 /usr/bin/ld: warning: libglib-2.0.so.1600.2, needed by /usr/local/lib/libgio-2.0.so.1600.2, not found (try using -rpath or -rpath-link) memory-output-stream.o(.text+0x13c): In function `test_data_size': /usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/gio/tests/memory-output-stream.c:68: undefined reference to `g_memory_output_stream_get_data_size' collect2: ld returned 1 exit status gmake[4]: *** [memory-output-stream] Error 1 gmake[4]: Leaving directory `/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/gio/tests' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/gio' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2/gio' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/glib2/w-glib-2.18.2/glib-2.18.2' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/devel/glib2 (line 2169 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/devel/glib2 (line 1424 of
Re: Problem doing an upgrade from Ports on Glib2
Jasper, Thanks for your reply... And my attempt to remove that old library: with what commad are you removing that old library? obviously not pkg_delete. that would solve the problem actually... I was just attempting to rm the main one. Reading through the the pkg_delete man page, I cannot find a way to delete the glib2 package without also deleting all of its dependencies. If you know some way to do this, I am all ears. Nonetheless, shouldn't a ports update go through smoothly without breaking? This seems like a problem with the port assuming a clean system. Aaron Hsu
PATCH: net/bluetooth-tools (Fix TTY Handling)
The patches below fix rfcomm_sppd to allow it to be used as a
subprocess or pipe when communicating to a bluetooth device. It
is not always useful to rely on rfcomm_sppd attaching itself to a
tty, so we should handle the case when there is not TTY.
I attempted to mail the maintainer first, but I have not heard
anything.
Aaron Hsu
--- Makefile.orig Thu Oct 23 00:00:42 2008
+++ MakefileThu Oct 23 00:03:57 2008
@@ -2,7 +2,7 @@
COMMENT= bluetooth network tools
DISTNAME= bluetooth-tools-20080217
-PKGNAME= ${DISTNAME}p0
+PKGNAME= ${DISTNAME}p1
CATEGORIES=net
MAINTAINER=Uwe Stuehler [EMAIL PROTECTED]
--- patches/patch-rfcomm_sppd_rfcomm_sppd_c.origMon Oct 27 20:33:29 2008
+++ patches/patch-rfcomm_sppd_rfcomm_sppd_c Wed Oct 22 23:57:37 2008
@@ -0,0 +1,35 @@
+$OpenBSD$
+--- rfcomm_sppd/rfcomm_sppd.c.orig Fri Sep 14 04:24:55 2007
rfcomm_sppd/rfcomm_sppd.c Wed Oct 22 23:57:09 2008
+@@ -228,18 +228,20 @@ main(int argc, char *argv[])
+* be used directly with stdio
+*/
+ if (tty == NULL) {
+- if (tcgetattr(tty_in, t) 0)
+- err(EXIT_FAILURE, tcgetattr);
++ if (tcgetattr(tty_in, t) 0) {
++ if (errno != ENOTTY)
++ err(EXIT_FAILURE, tcgetattr);
++ } else {
++ memcpy(tio, t, sizeof(tio));
++ t.c_lflag = ~(ECHO | ICANON);
++ t.c_iflag = ~(ICRNL);
++
++ if (memcmp(tio, t, sizeof(tio))) {
++ if (tcsetattr(tty_in, TCSANOW, t) 0)
++ err(EXIT_FAILURE, tcsetattr);
+
+- memcpy(tio, t, sizeof(tio));
+- t.c_lflag = ~(ECHO | ICANON);
+- t.c_iflag = ~(ICRNL);
+-
+- if (memcmp(tio, t, sizeof(tio))) {
+- if (tcsetattr(tty_in, TCSANOW, t) 0)
+- err(EXIT_FAILURE, tcsetattr);
+-
+- atexit(reset_tio);
++ atexit(reset_tio);
++ }
+ }
+ } else {
+ if (daemon(0, 0) 0)
Users and Groups in ports
Hello All, I am cleaning up a port to be imported into the tree, and I noticed that even though there are appropriate @newuser and @newgroup lines in the PLIST, these users are not created by the make repackage command, or any other command for that matter. According to pkg_add(1) the users will be created when the package is installed, but this doesn't work so well when the package requires those users when built, what can I do to fix this?
Status? news/nn
Hello All, I haven't seemed to hear anything back, so I wanted to send out another message just in case something was missed. I submitted a new port for the NN newsreader, but I have not received any feedback or indications of problems that need fixing. Could someone please provide either feedback or commit the port if they have time and the port is working? http://www.sacrideo.us/nn_port.tar.gz Thanks! Aaron Hsu
Any comments on news/nn ?
Hello all, I submitted a new port a week or so ago, but I received no comments on it, nor did it get committed, so I was wondering if someone could let me know if there is interest in it, whether someone intends to commit it, or if there are some problems with it that are preventing any action? And the port is news/nn. Thanks! Aaron Hsu
RESUBMIT: news/nn
gzRsTwNqptt9.gz Description: An object packed by metasend
Problems with gtk+2 and gdk_pixbuf
Hey All, I was doing a rebuild of my ports to relink them with libc and libm now that there are new versions out, and most of them went smoothly. However, I couldn't get gtk+2 working. I noticed that it was failing on a problem with gdk-pixbuf. I checked, and gdk_pixbuf libraries were installed, but the gdk-pixbuf package wasn't actually installed. When I attempted to build the gtk+2 port, it would have problems linking against gdk_pixbuf, and would attempt to link against the old libm. I tried to install gdk-pixbuf over the old files, but this didn't seem to work. So I took the gdk_pixbuf* libraries and moved them to another location. I then installed gdk-pixbuf again, and ran the gtk+2 build again. This time it worked. Does anyone know what is going on here and why? I checked out the Makefile in gtk+2 and noticed that a SHARED_LIBS is defined for gdk_pixbuf-2.0.1200.10, but the newer gdk-pixbuf package doesn't install or update this file. In fact, I was able to install gtk+2 without ever installing gdk-pixbuf until now. Huh? I hope I'm just making some kind of stupid oversight here, but if not, maybe this really is some problem? Aaron
NEW: nn-6.7.3 (No News is Good News) Newsreader
I have just completed a tentatively workable port for NN-6.7.3 that I
would like to have test by a host of people if possible. As always,
any help is very appreciated.
http://www.sacrideo.us/nn_port.tar.gz
DESCRIPTION
nn is a menu based (point and shoot) netnews reader with a complete set
of features to satisfy both the expert and the novice user. Since its
first release in Denmark in 1984 (!), in Europe in 1988, and the global
release in June 1989, it has replaced rn and other well-known news
readers at many sites.
CURRENT ISSUES
[I consider the issues below as mostly passable for the moment, until
I have time to fix them. They should not affect the overall usage of the
port, though some of them are definitely undesirable.]
* I have *NOT* had time to go through all the compiler warnings
and verify individually that every usage of every mktemp() and
other such functions are used correctly. I intend to do this
as time allows.
* Currently I just build and install the client package. There is
a master package and other pieces to the system that should be
built, but probably belong in separate packages.
* Currently there is no note at the post installation phase to
let people know how they should configure their system to use
NN. I intend to add a little README.OpenBSD file as well as a
notice soon enough.
TESTING
There are a few things in particular that I would appreciate tested. To
test this program, it is easiest to set NNTPSERVER=news.yourserver.com
in your environment. /etc/nntp_server is also used.
1) Check that `nn` runs cleanly.
2) Check that `nnpost` works and can post.
#2 is important because of some issues I had with termcap/terminfo, and
I'd like to make sure that it works over all platforms.
Currently I have only an i386 machine to test on, and individual include
files have to be used for every different architecture, so I would
appreciate some help in verifying all of the other architectures. Once I
know which ones work and don't, I'll clean up the makefile.
Currently, I have inserted sed commands for each of the following
architectures:
Alpha
i386
Macppc
SGI
VAX
luna88k
mvme68k
sparc
hp300
mac68k
sparc64
In ${WRKSRC}/conf/m-* there are other machine specific files. If I have
left out a compatible architecture, or if anyone would like to modify
m-template.h to work with other architectures, and will send in fixes
I would be very happy.
DESIGN QUESTIONS
Currently I use sed scripts to do some hackery on the installation file
and the configuration files in order to make them work. I am not sure if
this is the best way to handle things.
Some lesser used programs are installed to /usr/local/lib/nn, I am trying
to find a more useful place for them right now.
I am not sure that my choice of the word daemon is correct in my PLIST.
NOTES
I have not cleaned up the Makefile yet; I am waiting on feedback to
submit an import ready copy, include architecure limitations.
Re: NEW: nn-6.7.3 (No News is Good News) Newsreader
One other question about DESIGN. In the pkg/DESCR file, should I include a long list of features like http://www.nndev.org has on their website, or should I stick to a short one paragraph explanation? Aaron Hsu
UPDATE: news/nn Clean up Makefile (tarball updated, too)
--- Makefile.orig Wed Jul 23 18:57:10 2008
+++ MakefileWed Jul 23 18:56:13 2008
@@ -1,57 +1,14 @@
-# $OpenBSD: Makefile.template,v 1.54 2008/01/13 16:43:57 espie Exp $
-# $FreeBSD/NetBSD: credit FreeBSD/NetBSD if thats where the port came from $
-# Original from: credit the original author here
-#
-# Replace ??? with appropriate values
-# Remove extraneous comments before commit.
+# $OpenBSD: Makefile,v 1.00 2008/07/23 16:00:00 espie Exp $
-# Reasons why the port/package shouldn't be built
-#
-#ONLY_FOR_ARCHS = ???
-#NOT_FOR_ARCHS = ???
-#SHARED_ONLY = ???
-#COMES_WITH = ???
-#BROKEN = reason
+NOT_FOR_ARCHS =armish hppa landisk mvme88k zaurus
-#
-# Very short description of the package, 60 chars max
-#
COMMENT = No News is Good News (Fast CLI Point Read Newsreader)
-# COMMENT-foo =??? for multi packages
-
-#
-# What port/package will be created
-#
DISTNAME = nn-6.7.3
-#PKGNAME = ???
-#PKGNAME-foo = ??? for multi packages
-
-# for any port that create shared libraries.
-# both libtool and cmake handle this automatically.
-# for libtool-based ports, have a look at WRKBUILD/shared_libs.log
-#SHARED_LIBS = ???
-
CATEGORIES = news
+HOMEPAGE = http://www.nndev.org
-#HOMEPAGE =??? URL
-
-# where to send bitches about this port
-# Put a complete email address with a real name, e.g.,
-# MAINTAINER= John Doe [EMAIL PROTECTED]
-# if you maintain several ports, try to use the same line each time.
-# MAINTAINER implies some amount of responsibility.
-# If you no longer use the port, or are unwilling/unable to handle issues
-# in a timely manner, *leave the field blank*.
-# Default value is ports@openbsd.org, no need to fill in
MAINTAINER = Aaron W. Hsu [EMAIL PROTECTED]
-# Licensing: This determines what we can distribute.
-# When you determine the license type, make sure to look at ALL distfiles.
-# Every distfile can have a different license. The PERMIT_* values are
-# determined by the most restrictive license. If you have two licenses
-# that are in conflict, set PERMIT_* based on the most restrictive one.
-# Make SURE you get these values right.
-
# 4 point NN License á la BSD but with GPL Source Restriction and Freeware
# Requirement
PERMIT_PACKAGE_CDROM = CDs not sold at cost
@@ -61,117 +18,12 @@
WANTLIB = c termlib
-# where the source files and patches can be fetched
-#
MASTER_SITES = ftp://ftp.nndev.org/pub/nn-6.7/
-#MASTER_SITES =${MASTER_SITE_foo:=subdir/}
-# if more master sites are needed...
-#MASTER_SITES0 =
-# ...
-#DISTFILES = ???
-#EXTRACT_ONLY =???
EXTRACT_SUFX = .tar.Z
-#DIST_SUBDIR = ???
+CONFIGURE_STYLE = none
-# PATCHFILES are also retrieved from MASTER_SITES*
-#PATCHFILES = ???
-#PATCH_DIST_STRIP =-p0
-
-# Dependencies
-#
-#MODULES = ???
-#BUILD_DEPENDS = ???
-#RUN_DEPENDS = ???
-#LIB_DEPENDS = ???
-#REGRESS_DEPENDS = ???
-
-#MAKE_FLAGS = ???
-#MAKE_ENV =???
-#FAKE_FLAGS = ???
-#REGRESS_FLAGS = ???
-
-# build/configuration variables
-#
-#SEPARATE_BUILD = concurrent (build simultaneously on all arches)
-#SEPARATE_BUILD = simple (configure/build still recreates files in
source)
-#USE_X11 = Yes
-#USE_GMAKE = Yes
-# Programs that uses libtool should use this option,
-# unless there is a really good reason not to.
-#USE_LIBTOOL = Yes
-# Set CONFIGURE_STYLE to value corresponding to some standard configuration
-#perl [modbuild]: perl's MakeMaker Makefile.PL (modbuild: perl's
-#Module::Build Build.PL)
-#gnu [autoconf] [old] [dest]: gnu style configure (old: no
-#sysconfdir), (dest: add DESTDIR, does not handle it),
-#(autoconf: needed by port, implies gnu)
-# XXX: cygnus products do NOT use autoconf for making the main
-# configure from configure.in
-#imake [noman]: port uses imake for configuration.
-#(noman: no man page installation)
-#simple: port has its own configure script
-CONFIGURE_STYLE = none
-#CONFIGURE_SCRIPT =??? (if other than configure)
-#CONFIGURE_ARGS += ${CONFIGURE_SHARED}
-#CONFIGURE_ENV = ???
-
-# for gnu stuff
-#AUTOCONF_VERSION =??? (defaults to 2.13)
-#AUTOMAKE_VERSION =??? (defaults to 1.4)
-#MODGNU_CONFIG_GUESS_DIRS = ??? (defaults to ${WRKSRC}
-
-# Is the build automagic or is it interactive
-#
-#IS_INTERACTIVE = Yes
-#REGRESS_IS_INTERACTIVE = Yes
-
-# Assume you have one multiple choice flavor: 1 2 3 and switches a b.
-# You would write
-#
-#FLAVORS = 1 2 3 a b
-#FLAVOR ?=
-# grab multiple choice value
-#CHOICE = ${FLAVOR:L:Na:Nb}
-# check that CHOICE is 1 OR 2 OR 3, or error out
-#.if ${CHOICE} == 1
-# code for 1
-#.elif
Anyone working on a port of NN?
Hello All, Does anyone currently have a port of NN in the works? If so, then I won't bother doing it myself, but if not, then I have a working build of the system that I would like to submit as a port. However, there are some warnings and such with mktemp and the like that I haven't checked yet. Still, I would like to just get it in the tree before things freeze if it is not too late, and work on the fixes later. Sincerely, Aaron Hsu -- +++ ((lambda (x) (x x)) (lambda (x) (x x))) +++ Email: [EMAIL PROTECTED] | WWW: http://www.sacrideo.us Scheme Programming is subtle; subtlety can be hard. +++
Help with Porting
I am trying to create a port for NN, and I am running into a bit of a situation. The build system is a simple makefile with some configuration files after it, and I can't seem to figure out the *right* way to do the installation part. Configuration is merely copying a few pieces here and there from each configuraiton file that I can make and store in files/, but there is a inst installation script which does the install. The PREFIX is hard coded into the config.h file. I'm at #20 in the Porting Checklist, and I am not sure as to the best way to proceed. Is it better to patch the inst program, or is there another means of doing a proper installation? I guess I'm a bit rusty on my porting. Aaron Hsu -- +++ ((lambda (x) (x x)) (lambda (x) (x x))) +++ Email: [EMAIL PROTECTED] | WWW: http://www.sacrideo.us Scheme Programming is subtle; subtlety can be hard. +++
Relinking packages for bumped base libraries
Hey all, What is the easiest way to rebuild my packages for a new base library version? Right now, I see that there is a FORCE_UPDATE environment variable I can use when building a port, but this seems a bit broad. If I just want to update a certain package, make update doesn't seem to work because it will already recognize the package as being installed, I could just tell it to build a new package by deleting the old one manually, but what's the correct way of doing this? Sincerely, Aaron Hsu -- +++ ((lambda (x) (x x)) (lambda (x) (x x))) +++ Email: [EMAIL PROTECTED] | WWW: http://www.sacrideo.us Scheme Programming is subtle; subtlety can be hard. +++
Status of build/out-of-date
Hey all, I was searching for a way to keep my ports tree in synch with my installed packages as I am running -current and sometimes I have to build from ports instead of packages. I found build/out-of-date for use, but I can't tell if it is actively maintained or not. Does this script work currently? I tested it out, and it seems to be pretty good, in that it went through and gave me all the output I would have expected, but I'm just wondering if I can rely on it. I would certainly be interested in patching it up if it needs work. Does anyone know the status of this script? Sincerely, Aaron Hsu -- +++ ((lambda (x) (x x)) (lambda (x) (x x))) +++ Email: [EMAIL PROTECTED] | WWW: http://www.sacrideo.us Scheme Programming is subtle; subtlety can be hard. +++
Random Opera Freezes, still?
Hey all, I remember that a while back there were some issues with Opera randomly freezing. I believe that it could have been related to threads spawned or something of that sort. I am following -current and checked out the Opera 9.50 port. It seems to have the same issue of being very unstable and freezing. I am on an GENERIC.MP kernel. I also found some old stuff relating to Opera and Redhat 6.2 that mentioned a bug in glibc could be causing crashes in Opera on Linux. Could this be related at all? Does anyone have suggestions for improving the stability of Opera? Can these suggestions be put into a document or something that is available to the user after installing Opera? -- Aaron Hsu [EMAIL PROTECTED]
Re: Notes on vpnc
I've been working with the vpnc port, and I noticed something strange. I have to run a dhcp client first to connect to my network, and then I start vpnc. This all works fine until dhcp repools for a new IP. Somehow, it overwrites the resolv.conf file so that my routes do not work. Tunnels already established continue to work for some time, but eventually they go out too. Does anyone know what is wrong here? It does not appear that my vpnc client is disconnecting me, or that the server is disconnecting me, so I can't see any other reason than dhclient for the whole thing to mess up. Has anyone experienced a similar problem? Is there a way to make sure that dhclient does not overwrite my vpnc defined resolv.conf file? :-/ -- ((name Aaron Hsu) (email/xmpp [EMAIL PROTECTED]) (phone 703-597-7656) (site http://www.aaronhsu.com;)) pgpm7IC2Jf9YQ.pgp Description: PGP signature
[SOLVED] Re: lang/scheme48 new port, request for assistance
On Thu, Jul 27, 2006 at 09:07:09AM -0400, Kurt Miller wrote: On Saturday 22 July 2006 7:44 pm, Aaron W. Hsu wrote: ... Basically, Scheme allows external C libraries to access the scheme48vm's internal C structures through a scheme48.h header file. One such program (http://magic.xmog.com) is using a postgresql.c wrapper file to provide special wrappers to my Scheme programs. In doing so, it utilizes some of the internal structures (functions, variables, etc.) declared in scheme48.h. However, when I load this software (further instructions on reproducing the exact error are below), and run the proper commands, the program faults out (segfault) giving me errors that it cannot find the functions internal to scheme48vm It sounds like you need to link the executable with -Wl,-E. Read man 1 ld -E option to understand why. Yes, this problem was solved thanks to some help at [EMAIL PROTECTED] That was the issue. This has been fixed when I submitted the port more officially to the list. In the end, it boiled down to LDFLAGS=-Wl,--export-dynamic. -- Aaron Hsu [EMAIL PROTECTED] http://www.aaronhsu.com XMPP/Jabber/GTalk: [EMAIL PROTECTED] | ICQ: 153114301 AIM/Yahoo: NoorahAbeer | MSN: [EMAIL PROTECTED]
Re: NEW: lang/scheme48
On Tue, Jul 25, 2006 at 09:03:19PM -0500, Will Maier wrote:
On Tue, Jul 25, 2006 at 05:53:31PM -0500, Aaron W. Hsu wrote:
I have currently tested on i386-stable and have had positive test
feedback from i386-current testers. I would appreciate additional
testing on big-endian or 64-bit machines, if possible.
Tested on i386/-current. Port builds fine and looks good to me.
Passes the regress checks; I'm not really sure how else to test it.
;)
I have learned that Scheme48 is 32-bit dependent, and as such, I have
added an appropriate NOT_FOR_ARCHS=${LP64_ARCHS} line, which,
according to my research, is the right way to mention this. This
change is reflected in the updated package at the same previous link I
gave.
http://arcfide.fastmail.fm/scheme48_openbsd/scheme48.tar.gz
If this is not the correct way to handle this situation, could someone
please correct my error?
--
Aaron Hsu [EMAIL PROTECTED]
http://www.aaronhsu.com
XMPP/Jabber/GTalk: [EMAIL PROTECTED] | ICQ: 153114301
AIM/Yahoo: NoorahAbeer | MSN: [EMAIL PROTECTED]
NEW: lang/scheme48
COMMENT=R5RS Scheme byte-code interpreter Scheme 48 is an implementation of the Scheme programming language as described in the Revised5 Report on the Algorithmic Language Scheme. It is based on a compiler and interpreter for a virtual Scheme machine. Scheme 48 tries to be faithful to the Revised5 Scheme Report, providing neither more nor less in the initial user environment. It is based on a byte-code interpreter and is designed to be used as a testbed for experiments in implementation techniques and as an expository tool. http://arcfide.fastmail.fm/scheme48_openbsd/scheme48.tar.gz I have currently tested on i386-stable and have had positive test feedback from i386-current testers. I would appreciate additional testing on big-endian or 64-bit machines, if possible. Thank you! -- Aaron Hsu [EMAIL PROTECTED] http://www.aaronhsu.com XMPP/Jabber/GTalk: [EMAIL PROTECTED] | ICQ: 153114301 AIM/Yahoo: NoorahAbeer | MSN: [EMAIL PROTECTED]
lang/scheme48 new port, request for assistance
Hello all, I have two requests to make here, and I hope that at least the second request will receive something of a favourable reply. To begin, I am working to port over scheme48 for OpenBSD for my own personal use, and the ports works, so far. Enough that most of the things necessary to post it up are done. The problem is that I don't run -current. I'm well aware of the rules that I must be running -current if I want to submit a port; I just can't do that right now (stability). Instead, I was wondering if there is someone who would be willing to pick up moving the port to -current for me? The software itself is very self-contained and minimal. I have attached what I have thus far, and if someone is willing to work with me on testing and fixing it, I would greatly appreciate it. Second, there is one known bug in this port so far. It is causing me no end in my headaches. Basically, Scheme allows external C libraries to access the scheme48vm's internal C structures through a scheme48.h header file. One such program (http://magic.xmog.com) is using a postgresql.c wrapper file to provide special wrappers to my Scheme programs. In doing so, it utilizes some of the internal structures (functions, variables, etc.) declared in scheme48.h. However, when I load this software (further instructions on reproducing the exact error are below), and run the proper commands, the program faults out (segfault) giving me errors that it cannot find the functions internal to scheme48vm (the virtual machine which loads the postgresql.so wrapper library in Magic). Learning about stripping from the ports docs, I thought perhaps the stripped executable was not able to reference its own functions when they were called from an external library. I supposed that removing the stripping from the executable might solve my problem. Doing so, I verified that the necessary functions were indeed inside the vm, and then I tried again. Still, I had no luck, and the same error occurs. :-( I am now at a loss as to what might be special about OpenBSD (this works in Slackware 10.2) that would result in a program being unable to locate its own functions. I hope that submitting this problem to the OpenBSD porting gurus will result in some hidden knowledge being released, as I was unable to find any porting troubles related to my topic being mentioned anywhere on any of the searchable mailing lists of NetBSD or FreeBSD, both of which have ports of Scheme48. In addition, a general search and request to IRC and search engines reveals nothing. What could be causing this problem? REPRODUCING SEGFAULT ERROR IN SCHEME48 To duplicate the problem, one can use this port to install scheme48, then, get a copy of Magic from (http://magic.xmog.com) and install it to some directory. Please then install the error_stuff.tar.gz package to the Magic directory. After doing so, enter the Magic directory and $ cd c $ cp ../error_stuff/Makefile . $ make This will make and install the postgresql.so file into magic_dir/lib. $ cd magic_dir $ scheme48 [you will see the scheme48 prompt, represented as ] ,config ,load packages.scm ,config ,load error_stuff/packages.scm ,in application From this you should receive the following output: /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_pop_gc_rootsB' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_enter_integer' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_stob_ref' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_stob_has_type' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_extract_byte_vector' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_make_vector' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_enter_string' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_call_scheme' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_stob_set' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_extract_string' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_enter_byte_vector' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_define_exported_binding' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_raise_scheme_exception' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_enter_pointer' /usr/local/lib/scheme48/scheme48vm:lib/postgresql.so: undefined symbol 's48_push_gc_rootsB' Segmentation fault (core dumped) -- Aaron Hsu [EMAIL PROTECTED] http://www.aaronhsu.com XMPP/Jabber/GTalk: [EMAIL PROTECTED] | ICQ: 153114301 AIM/Yahoo: NoorahAbeer | MSN: [EMAIL PROTECTED] error_stuff.tar.gz Description: application/tar-gz scheme48.tar.gz Description: application/tar-gz
