Re: NEW: games/spacehulk
Am 20.11.2005 um 23:29 schrieb Aleksander Piotrowski: Hi Slightly tested on i386... Someone wants to maintain it? Space Hulk is a science-fiction board game in the world of Warhammer 4. It is aiming at providing a way to play SpaceHulk on your computer with the exact same rules as in the board version. Alek took it for a spin on i386 and sparc64, works floh
Re: libtool no symlinked libs patch
Sorry for the delay. Jacob Meuser jakemsr at jakemsr.com writes: On Sun, Nov 20, 2005 at 12:25:19AM -0500, Brad wrote: On Sat, Nov 19, 2005 at 09:10:33PM -0800, Jacob Meuser wrote: On Sat, Nov 19, 2005 at 09:12:36PM -0500, Brad wrote: So whatever the library name is supposed to be, either -lfoo or - lfoo-1.8 is up to the software author, most here roll their eyes at versioned libnames, but we accept them... just don't symlink them. Exactly, which means not removing the ability to create shared libs with the -release tag. This is a very bad idea. Just remove the symlinking. I strongly disagree. for example, we'd get _only_ libldap-2.3.so.8.1. then we'd have to change every port with -lldap to -lldap-2.3. I believe a better way would be to have less libraries with -release (but that may be me only). Ports should already do the right thing with pkgconfig and the other mechanisms. If not then they need to be fixed. Removing -release support from libtool is not happening. Nope. There are some situations where it is necessary. I think this would be very common because of the comment that gets put into libtool just above the library_names_spec line: # List of archive names. First name is the real one, the rest are links. # The last name is the one that the linker finds with -lNAME. so the -release flag doesn't effectively create release named libraries anyway, since libtool will always create a symlink without the release part to the release library. Well, because it's a hack in a way. For your decision, it may be helpful to be aware of another related hack: http://lists.gnu.org/archive/html/libtool/2005-07/msg00028.html Without any symlinks, this won't work well. I do not know whether Keith has enabled this in X, but would assume so. It has not yet been integrated into GNU Libtool, but we would like to do so eventually, given that it can be made to work on as many systems as possible. I can see the value in having, say libfoo-1.0.so... and libfoo-2.0.so..., you may want to have both installed, for example. but this is not possible if both are trying to install libfoo.so... as well, which is what libtool would do. Well, but this nothing new. In any case, however you decide: if you want to see the corresponding change in upstream Libtool as well, please let us know. Thanks. Cheers, Ralf
Re: UPDATE: x11/py-gtk2
Eric Faurot [EMAIL PROTECTED] wrote: Because of the missing pycairo.pc. Please update py-cairo (and cairo too) with patches at http://ekyo.nerim.net/openbsd/index.html I'll take care of Eric's python stuff. Alek -- - Co to są litery? - Coś takiego jak mediaglify, tylko że czarne i maleńkie. I wcale się nie ruszają, są stare, nudne i trudno je czytać. Ale można z nich robić skróty i długie słowa stają sie krótkie. -- Neal Stephenson, Diamentowy Wiek
bison 2.1 needs GNU m4 at runtime too
And fails without giving a warning if /usr/local/bin/gm4 isn't there.
If I force it to use our in-tree m4 I get:
M4sugar requires GNU M4. Install it before installing M4sugar or
set the M4 environment variable to its absolute file name.
The attached patch adds the RUN_DEPENDS.
Mark
Index: Makefile
===
RCS file: /cvs/ports/devel/bison/Makefile,v
retrieving revision 1.40
diff -u -p -r1.40 Makefile
--- Makefile21 Nov 2005 09:15:11 - 1.40
+++ Makefile22 Nov 2005 14:49:15 -
@@ -3,7 +3,7 @@
COMMENT= GNU parser generator
DISTNAME= bison-2.1
-PKGNAME= ${DISTNAME}p0
+PKGNAME= ${DISTNAME}p1
CATEGORIES=devel
MASTER_SITES= ${MASTER_SITE_GNU:=bison/}
@@ -17,6 +17,7 @@ PERMIT_DISTFILES_FTP= Yes
MODULES= devel/gettext
BUILD_DEPENDS= ::devel/m4
+RUN_DEPENDS= ${BUILD_DEPENDS}
WANTLIB= c
CONFIGURE_STYLE=gnu
proposte svago, terza et� inHOTEL* * * *
Gentili Signori, terza età inHOTEL, è una iniziativa Intersectors Servizi sas. Dal 1995, ci occupiamo di soggiorni alberghieri brevi e lunghi nel settore over 60. Inoltre organizziamo Proposte-Svago, per gruppi. Visitando il nostro sito http://www.terzaetainhotel.it si potrà avere una visione più ampia di ciò che proponiamo. Abbiamo inserito 3 Proposte-Svago per i gruppi, visibili nell'area Servizi e Itinerari http://www.terzaetainhotel.it Gradite i nostri più cordiali saluti Intersectors Servizi sas Via Lipari 3, c/o hotel 09045 Quartu S. Elena (CA) Tel. e fax: 070/8988056 e-mail: [EMAIL PROTECTED] site: http://www.terzaetainhotel.it Se non doveste essere interessati e/o questa e-mail Vi è giunta per errore, ci scusiamo. Dalla ricerca telematica vengono rilevati indirizzi e-mail da siti esposti in rete e predisposti alla ricezione; non vengono in alcun modo rilevati dati personali di chicchessia.
Re: bison 2.1 needs GNU m4 at runtime too
On Tue, Nov 22, 2005 at 03:51:21PM +0100, Mark Kettenis wrote:
And fails without giving a warning if /usr/local/bin/gm4 isn't there.
If I force it to use our in-tree m4 I get:
M4sugar requires GNU M4. Install it before installing M4sugar or
set the M4 environment variable to its absolute file name.
The attached patch adds the RUN_DEPENDS.
Mark
Index: Makefile
===
RCS file: /cvs/ports/devel/bison/Makefile,v
retrieving revision 1.40
diff -u -p -r1.40 Makefile
--- Makefile 21 Nov 2005 09:15:11 - 1.40
+++ Makefile 22 Nov 2005 14:49:15 -
@@ -3,7 +3,7 @@
COMMENT= GNU parser generator
DISTNAME=bison-2.1
-PKGNAME= ${DISTNAME}p0
+PKGNAME= ${DISTNAME}p1
CATEGORIES= devel
MASTER_SITES=${MASTER_SITE_GNU:=bison/}
@@ -17,6 +17,7 @@ PERMIT_DISTFILES_FTP= Yes
MODULES= devel/gettext
BUILD_DEPENDS= ::devel/m4
+RUN_DEPENDS= ${BUILD_DEPENDS}
WANTLIB= c
CONFIGURE_STYLE=gnu
You're late, I removed the dependency yesterday.
Samba 3 lockups
The 3.8 Samba 3 package seems to be causing me some grief, locking up machine under heavy traffic. Has anyone else had similar experience? I've gone back the the Samba 2 package from release 3.7 and things have been more stable so far. Any chance of forking Samba 2/3 to give people an easier choice? Paul
Re: Samba 3 lockups
* Paul Galbraith wrote: The 3.8 Samba 3 package seems to be causing me some grief, locking up machine under heavy traffic. Has anyone else had similar experience? I've gone back the the Samba 2 package from release 3.7 and things have been more stable so far. Not here. We run several highly loaded Samba servers and have no srability issues. Any chance of forking Samba 2/3 to give people an easier choice? No. Samba 2 is deprecated. If there is a real problem, we fix that. So please start by posting a *much* more complete problem report ;) Paul Marc Balmer
Re: Samba 3 lockups
Marc Balmer wrote: No. Samba 2 is deprecated. If there is a real problem, we fix that. So please start by posting a *much* more complete problem report ;) That will take some work, unless you're just interested in hardware details :-). I just wanted to see if anyone else has had a similar experience. I'm beginning to suspect that I've got a hardware problem, since I've been having problems with softdep, too. I'm going to focus on that side of things for now, but will follow up to this if I learn anything that seems relevant.
Re: UPDATE: security/gpgme
On Tue, 22 Nov 2005 19:40:11 +0100 Jasper Lievisse Adriaanse [EMAIL PROTECTED] wrote: [...] Index: pkg/PLIST === RCS file: /cvs/ports/security/gpgme/pkg/PLIST,v retrieving revision 1.4 diff -u -r1.4 PLIST --- pkg/PLIST 14 Feb 2005 22:14:25 - 1.4 +++ pkg/PLIST 22 Nov 2005 18:41:27 - @@ -1,7 +1,7 @@ @comment $OpenBSD: PLIST,v 1.4 2005/02/14 22:14:25 couderc Exp $ bin/gpgme-config include/gpgme.h [EMAIL PROTECTED] info/gpgme.info +info/gpgme.info whoops, pkg/PLIST doesn't need an update, since the @info is still needed, right? -- Security is decided by quality -- Theo de Raadt -- Security is decided by quality -- Theo de Raadt
Re: plugins for xchat port (i386)
On Fri, 18 Nov 2005 16:51:31 +0100 Markus Hennecke [EMAIL PROTECTED] wrote: Robert Szasz wrote: Is there a way to get the xchat port to support plugins again? This is an update for the stable port bumping the version to 2.4.5 and enabling the perl plugin. Please apply the patch from the xchat directory with `zcat xchat.patch.gz | patch -p0` from inside the xchat directory. I hope that patching the configure script is the right way to tell libtool to include the DynaLoader.a and libintl.a files in the linking process of the perl plugin. I should look at his this week end. As far as i know the plugins didn't work on OpenBSD due to a dlsym() incompatibility. Damien
Re: libtool no symlinked libs patch
On Tue, Nov 22, 2005 at 09:58:44AM +, Ralf Wildenhues wrote: Sorry for the delay. thanks for responding. it's good to have a libtool developer in this discussion :) Jacob Meuser jakemsr at jakemsr.com writes: On Sun, Nov 20, 2005 at 12:25:19AM -0500, Brad wrote: On Sat, Nov 19, 2005 at 09:10:33PM -0800, Jacob Meuser wrote: On Sat, Nov 19, 2005 at 09:12:36PM -0500, Brad wrote: So whatever the library name is supposed to be, either -lfoo or - lfoo-1.8 is up to the software author, most here roll their eyes at versioned libnames, but we accept them... just don't symlink them. Exactly, which means not removing the ability to create shared libs with the -release tag. This is a very bad idea. Just remove the symlinking. I strongly disagree. for example, we'd get _only_ libldap-2.3.so.8.1. then we'd have to change every port with -lldap to -lldap-2.3. I believe a better way would be to have less libraries with -release (but that may be me only). that is essentially the current situation in the ports tree. there are several patches to remove the -release flag from libtool invocations in Makefiles. Ports should already do the right thing with pkgconfig and the other mechanisms. If not then they need to be fixed. Removing -release support from libtool is not happening. Nope. There are some situations where it is necessary. such as? the patch I proposed only changes library_names_spec on OpenBSD. I wasn't really intending for that to go upstream, anyway ... I think this would be very common because of the comment that gets put into libtool just above the library_names_spec line: # List of archive names. First name is the real one, the rest are links. # The last name is the one that the linker finds with -lNAME. so the -release flag doesn't effectively create release named libraries anyway, since libtool will always create a symlink without the release part to the release library. Well, because it's a hack in a way. For your decision, it may be helpful to be aware of another related hack: http://lists.gnu.org/archive/html/libtool/2005-07/msg00028.html Without any symlinks, this won't work well. I do not know whether Keith has enabled this in X, but would assume so. It has not yet been integrated into GNU Libtool, but we would like to do so eventually, given that it can be made to work on as many systems as possible. interesting. not sure how this would affect OpenBSD. currently, there is no soname_spec in libtool for OpenBSD. SONAME seems to be rarely used in libraries on OpenBSD as well. the -old-abi idea is interesting as well :) I can see the value in having, say libfoo-1.0.so... and libfoo-2.0.so..., you may want to have both installed, for example. but this is not possible if both are trying to install libfoo.so... as well, which is what libtool would do. Well, but this nothing new. true, Keith even mentioned this issue in the above thread. there is something of a push to use a single libtool in the OpenBSD ports tree. that is, use the libtool from the ports tree for every port that uses libtool. really, OpenBSD support in libtool was not so good until fairly recently, so there are a lot of patches for the different libtool versions the various packages come with. but now that there is a libtool that works pretty well, it is a lot easier to just use that instead of trying to patch the various libtools that come with the various packages. my suggestion was intended to further reduce the number of patches for libtool related issues in the ports tree, nothing more, nothing less. In any case, however you decide: if you want to see the corresponding change in upstream Libtool as well, please let us know. Thanks. now that I've thought about it a little more, I can see the value in the -release flag from a developer's perspective. you could have a 1.0 release that you are maintaining, and a 1.1 release that is in development. you would might want to have both installed, and just change the symlink back and forth, assuming you would want backward compatability. while this could be useful from a developer's perspective, it is still a conflict from a packager's perspective. this doesn't seem to be how/why the -release flag is generally used, though. maybe the best solution would be to have an internal libtool, that is hacked in ways that would be useful for building ports but may limit overall usability/features, and a standard libtool port that does not contain such hacks? I dunno. it's not really my decision anyway ;P Cheers, Ralf -- [EMAIL PROTECTED]
