Re: update: gtkpod
Am Samstag, 26. November 2005 00:04 schrieb Nikolay Sturm: Servus Nikolay, Attached diff updates gtkpod to 0.94.0, the latest stable release. If someone could test this with an ipod, I'd appreciate it. Works for me on i386 with an fifth generation ipod: umass0 at uhub0 port 1 configuration 1 interface 0 umass0: Apple iPod, rev 2.00/0.01, addr 2 umass0: using SCSI over Bulk-Only scsibus1 at umass0: 2 targets sd0 at scsibus1 targ 1 lun 0: Apple, iPod, 1.62 SCSI0 0/direct removable sd0: 28615MB, 28615 cyl, 64 head, 32 sec, 512 bytes/sec, 58605120 sec total Regards, Stephan
CATEGORIES fixes
Hi,
I've attached a few patches that fix typos/ommissions in some ports'
CATEGORIES. The result is that link-categories does not create three
mostly empty directories (gnome/, perl/, sysutil/) anymore.
Moritz
P.S.: So far, only two special categories exist: perl5 and pear ...
right? Is there a list of valid categories somewhere?
Index: Makefile
===
RCS file: /cvs/ports/devel/g-wrap/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- Makefile31 Mar 2005 23:38:26 - 1.3
+++ Makefile27 Nov 2005 10:22:33 -
@@ -3,7 +3,7 @@
COMMENT= g-wrap
DISTNAME= g-wrap-1.3.4
PKGNAME= ${DISTNAME}p0
-CATEGORIES=gnome databases
+CATEGORIES=x11/gnome databases
MASTER_SITES= ${HOMEPAGE}/source/
HOMEPAGE= http://www.gnucash.org/pub/g-wrap
Index: Makefile
===
RCS file: /cvs/ports/graphics/dvdrip/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile13 Feb 2005 10:56:23 - 1.5
+++ Makefile27 Nov 2005 10:18:52 -
@@ -5,7 +5,7 @@
VERSION= 0.50.18
PKGNAME= dvdrip-${VERSION}p1
DISTNAME= Video-DVDRip-${VERSION}
-CATEGORIES=graphics audio perl
+CATEGORIES=graphics audio perl5
HOMEPAGE= http://www.exit1.org/dvdrip/
Index: Makefile
===
RCS file: /cvs/ports/productivity/gnucash/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- Makefile12 Nov 2005 12:49:59 - 1.4
+++ Makefile27 Nov 2005 10:21:35 -
@@ -5,7 +5,7 @@
COMMENT= Quicken-like money and finance manager
DISTNAME= gnucash-1.8.11
PKGNAME= ${DISTNAME}p0
-CATEGORIES=gnome productivity
+CATEGORIES=x11/gnome productivity
MASTER_SITE_GNUCASH= http://www.gnucash.org/pub/gnucash/ \
ftp://ftp.gnucash.org/pub/gnucash/ \
http://www.linas.org/pub/gnucash/gnucash/
Index: Makefile
===
RCS file: /cvs/ports/sysutils/syslog-ng/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile19 Sep 2005 13:35:17 - 1.6
+++ Makefile27 Nov 2005 10:23:42 -
@@ -2,7 +2,7 @@
COMMENT= syslogd replacement
-CATEGORIES=sysutil
+CATEGORIES=sysutils
DISTNAME= syslog-ng-1.6.8
LIBOL= libol-0.3.16
Re: CATEGORIES fixes
On Sun, Nov 27, 2005 at 11:33:47AM +0100, Moritz Grimm wrote: Hi, I've attached a few patches that fix typos/ommissions in some ports' CATEGORIES. The result is that link-categories does not create three mostly empty directories (gnome/, perl/, sysutil/) anymore. it looks like at least dvdrip, gnucash and syslog-ng could do with an update. as this is a minor fix, maybe it can be included whenever the next update happens? so i suggest you send this to the respective maintainers. -- steven Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: What java port for konqueror?
On Sat, Nov 26, 2005 at 05:45:37PM -0500, Dave Feustel wrote: I finally need to activate Java support for Konqueror, but it appears that Java is not by default part of KDE or included in OpenBSD. What port/package(s) do I need for java to work with konqueror on OpenBSD? Thanks, Dave Feustel grab a jdk (devel/jdk/1.4 or 1.5). Beware that konqueror's java support is not really good. Among other things, the reparenting of windows does not work correctly unless you happen to also be using kwin, the window manager of KDE...
Re: What java port for konqueror?
On Sunday 27 November 2005 06:28, Marc Espie wrote: On Sat, Nov 26, 2005 at 05:45:37PM -0500, Dave Feustel wrote: I finally need to activate Java support for Konqueror, but it appears that Java is not by default part of KDE or included in OpenBSD. What port/package(s) do I need for java to work with konqueror on OpenBSD? Thanks, Dave Feustel grab a jdk (devel/jdk/1.4 or 1.5). Beware that konqueror's java support is not really good. Among other things, the reparenting of windows does not work correctly unless you happen to also be using kwin, the window manager of KDE... Thanks for the tip, Marc. -- Switch to Secure OpenBSD with a KDE desktop!!! NOW with Virtual PC OS support via QEMU and Beowulf clustering using PETSc and MPICH2!
Re: libtool no symlinked libs patch
[ Cc: to libtool mailing list. This thread is at http://thread.gmane.org/gmane.os.openbsd.ports/14993 and the interesting bit starts at the end of this post: http://article.gmane.org/gmane.os.openbsd.ports/15121 ] * Ralf Wildenhues wrote on Sun, Nov 27, 2005 at 09:06:09AM CET: * Jacob Meuser wrote on Sun, Nov 27, 2005 at 05:42:07AM CET: On Wed, Nov 23, 2005 at 05:04:07PM +, Ralf Wildenhues wrote: Marc Espie espie at nerim.net writes: I'm very annoyed at libtool --mode=link cc -L/usr/local/lib -o foo foo.o ./libbar.la expanding into some stuff like: cc -L/usr/local/lib -L. -o foo foo.o -lbar which gets us the libbar installed under /usr/local/lib instead of the one we just built... Genuine bug in Libtool's OpenBSD support, most likely some wrong assumption about which path overrides which. Current branch-1-5 does not do this on GNU/Linux nor on FreeBSD -- sorry, I don't currently have access to OpenBSD. For static libbar, it creates on both systems gcc -o foo foo.o ./.libs/libbar.a and for shared libbar it creates gcc -o .libs/foo foo.o ./.libs/libbar.so -Wl,--rpath -Wl,/tmp/inst I think you are not understanding Marc's point. No, but I pasted the output in a misleading way. what happens with -L/usr/local/lib? Libtool knows that the library is uninstalled, because this information is encoded in libbar.la, hence knows to hardcode it _even_ when the installed path is given first. Attached an example. Please modify so it fails on OpenBSD. OK. This fails on OpenBSD because of hardcode_direct=yes, all branches, I assume, because then libtool will create cc -L/usr/local/lib -L.libs .. then. Call for help: I need access to an OpenBSD box or someone with access to help me debug this (off-list), because the failure is not exposed with GNU ld. Cheers, Ralf
Re: SIP Soft Phone
Jolan Luff [EMAIL PROTECTED] wrote: there's also shtoom, http://divmod.org/projects/shtoom. Right now I'm working on Twisted port. I guess that I could try to port shtoom later as it requires Twisted. Alek -- Wang-mu wzruszyła ramionami: - Przyszłość jest tysiącem nici, ale przeszłość tkaniną, której nie można spleść na nowo. Może byłabym szczęśliwa. Może nie. -- Orson Scott Card, Ksenocyd
Re: sysutils/stat/ redundant now?
* Okan Demirmen [2005-11-27]: now that stat(1) is in base, couldn't this go away? Yes, you are right. I just marked this (and another port) accordingly. They will be removed after 3.9. thanks, Nikolay
Re: libtool no symlinked libs patch
Hi Jacob, * Jacob Meuser wrote on Sun, Nov 27, 2005 at 05:42:07AM CET: On Wed, Nov 23, 2005 at 05:04:07PM +, Ralf Wildenhues wrote: Marc Espie espie at nerim.net writes: I'm very annoyed at libtool --mode=link cc -L/usr/local/lib -o foo foo.o ./libbar.la expanding into some stuff like: cc -L/usr/local/lib -L. -o foo foo.o -lbar which gets us the libbar installed under /usr/local/lib instead of the one we just built... Genuine bug in Libtool's OpenBSD support, most likely some wrong assumption about which path overrides which. Current branch-1-5 does not do this on GNU/Linux nor on FreeBSD -- sorry, I don't currently have access to OpenBSD. For static libbar, it creates on both systems gcc -o foo foo.o ./.libs/libbar.a and for shared libbar it creates gcc -o .libs/foo foo.o ./.libs/libbar.so -Wl,--rpath -Wl,/tmp/inst I think you are not understanding Marc's point. No, but I pasted the output in a misleading way. what happens with -L/usr/local/lib? Libtool knows that the library is uninstalled, because this information is encoded in libbar.la, hence knows to hardcode it _even_ when the installed path is given first. Attached an example. Please modify so it fails on OpenBSD. Elsewhere it creates gcc -o .libs/main main.o -L/tmp/inst/lib ./.libs/liba.so \ -Wl,--rpath -Wl,/tmp/inst/lib Now please: be specific in the bug report, and state exactly which libtool version you are using (including which patches you have applied) and post all output. Also please show 'libtool --config'. I am pretty sure our testsuite covers this, too. Any failures on OpenBSD? (Please run with VERBOSE=x so one can see actually useful output.) Cheers, Ralf run.sh Description: Bourne shell script
Re: libtool no symlinked libs patch
On Sun, Nov 27, 2005 at 04:25:27PM -0800, Jacob Meuser wrote:
patch below seems to do the trick. tested with devel/glib2 and
with this change to glib2. sorry, should have mentioned this before.
--
[EMAIL PROTECTED]
Index: Makefile
===
RCS file: /home/cvs/OpenBSD/ports/devel/glib2/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- Makefile13 Nov 2005 06:22:02 - 1.23
+++ Makefile28 Nov 2005 00:37:14 -
@@ -5,7 +5,7 @@
VERSION= 2.8.3
DISTNAME= glib-${VERSION}
-PKGNAME= glib2-${VERSION}
+PKGNAME= glib2-${VERSION}p0
PKGNAME-docs= glib2-docs-${VERSION}
CATEGORIES=devel
@@ -39,12 +39,12 @@
CONFIGURE_ARGS+= --disable-threads
.endif
+USE_LIBTOOL= Yes
USE_GMAKE= Yes
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS+= ${CONFIGURE_SHARED}
CONFIGURE_ARGS+= --enable-static
CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include \
- LIBS=-L${LOCALBASE}/lib \
- LDFLAGS=-L${WRKSRC}/glib/.libs
-L${WRKSRC}/gthread/.libs -L${WRKSRC}/gobject/.libs -L${WRKSRC}/gmodule/.libs
+ LDFLAGS=-L${LOCALBASE}/lib
.include bsd.port.mk
cvs server: patches/patch-ltmain_sh was removed, no comparison available
Re: akpop3d questions
On 28 Nov 2005, at 8:18 AM, J Moore wrote: Ian, Hope you'll excuse my persistence, but I'm still struggling with akpop3d. I may be confused, but here's how I see my choices: 1. chgrp mail /var/mail (after adding mail as a group) 2. akpop3d -g wheel (give akpop3 wheel privileges ?) Not really the port needs fixing some what. Try the attached tar ball. The port now creates a group _akpop3d and the lock files writable by the _akpop3d group. You will need to make /var/mail group writable, leave the permissons on /var/mail as root:wheel (the default). The command line I've used for simple testing is /usr/local/sbin/akpop3d -d -s -c /etc/ssl/server.crt -k /etc/ssl/ private/server.key Ian McWilliam akpop3d-port.tgz Description: Binary data
NEW: jamvm-1.4.0+classpath-0.19 for i386
Greetings, Ports for JamVM and GNU Classpath (tested on i386) are available on: http://druseikis.com/OpenBSD/ports/classpath-0.19-port-20051127.tar.gz http://druseikis.com/OpenBSD/ports/jamvm-1.4.0-port-20051127.tar.gz http://druseikis.com/OpenBSD/ports/freetype2-port-20051127.tar.gz Notes: (1) Freetype2 is a dependency for Classpath-0.19. Install it first. The Freetype2 port does not include the freetype documentation nor does it make any effort to be consistent with the exiting freetype 1.x port. More work needed here -- comments and suggestions welcome. (2) Install Classpath next; it has dependencies for other obsd packages and their ports. The Java code is compiled with Jikes. (3) This GNU Classpath port has a minor build problem with it: namely, soft links to shared libs need to be created to satisfy JNI declarations. These are in the makefile. I do the build this way: cd /usr/ports/mystuff/classpath-0.19 sudo make build fake post-fake install (The post-fake target is mine. The Fake Framework doc explains the special cases, but none of the things I tried seem to work. I could patch classpath's makefiles to construct the links to the shared libs but have been trying to avoid that; Suggestions welcome here too.) (4) Install JamVM last; the port assumes you will be installing classpath; glibj.zip will be found without mentioning it on the CLASSPATH environment var or with -classpath flag. (5) JamVM has powerpc, arm, X86_64 support, which I have not tested. It might work! (The interpreter has been run on linux an darwin on these archs.) JamVM is supposed to be 64-bit clean. It uses posix threads. (6) You must specify -classpath /usr/local/share/classpath/glibj.zip explicitly on Jikes compiles (along with any other build dependencies on your CLASSPATH.) (7) The JamVM port has a patch to correct a GC bug that will be fixed in JamVM 1.4.1; this is needed to run serious apps. I have run ant-1.6.5 with it using the binary from apache.org -- not the apache-ant obsd port, which tries to bring in Sun Java 1.3 :P Comments and suggestions welcome! Regards, Fred
Re: NEW: jamvm-1.4.0+classpath-0.19 for i386
On Sun, Nov 27, 2005 at 10:50:12PM -0500, Frederick C Druseikis wrote:
Greetings,
Ports for JamVM and GNU Classpath (tested on i386) are available on:
http://druseikis.com/OpenBSD/ports/classpath-0.19-port-20051127.tar.gz
http://druseikis.com/OpenBSD/ports/jamvm-1.4.0-port-20051127.tar.gz
http://druseikis.com/OpenBSD/ports/freetype2-port-20051127.tar.gz
just looking at classpath for the moment.
use the freetype from X. the pkgconfig file for this is
${X11BASE}/lib/pkgconfig/xft.pc. you will have to patch configure
to make pkg-config look for xft instead of freetype2, and add
${X11BASE}/lib/pkgconfig to PKG_CONFIG_PATH in CONFIGURE_ENV.
please look at LOCALBASE and X11BASE in bsd.port.mk(5). do
not hardcode '/usr/local' or '/usr/X11R6' into a port.
why are you specifying AUTOMAKE_VERSION and AUTOCONF_VERSION
if you aren't using automake or autoconf?
the way you specified BUILD_DEPENDS, you will be stuck depending
on specific versions of these packages, even if new ones go
into the ports tree. you should not specify the actual package
name in packages-specs for BUILD_DEPENDS.
wouldn't java be a more appropriate category than devel?
as far as the version numbers for the modules, tell the classpath
developers to look into using the -avoid-version libtool flag.
if they are hardcoding unversioned module names, they should be
using this to build the modules.
and some general stuffs:
please roll port tarballs from at most 1 directory above the actual
port.
port directories do not have version numbers. sometimes there
may be foo/bar and foo/bar2 or some such, but those only exist if
there is good reason to have two generations of a package in
the ports tree.
--
[EMAIL PROTECTED]
