www/links+ wantlib
Hi,
The dependency to liblzma.so.1.0 is missing in the links+ port.
The executable /usr/local/bin/links is linked against it and does
not start if the xz package is not installed.
ok?
bluhm
Index: www/links+/Makefile
===
RCS file: /cvs/ports/www/links+/Makefile,v
retrieving revision 1.45
diff -u -p -r1.45 Makefile
--- www/links+/Makefile 10 Apr 2012 11:59:44 - 1.45
+++ www/links+/Makefile 17 Sep 2012 01:09:48 -
@@ -3,6 +3,7 @@
COMMENT= graphics and text browser
VER= 2.6
+REVISION= 1
DISTNAME= links-${VER}
PKGNAME= links+-${VER}
@@ -16,11 +17,12 @@ PERMIT_PACKAGE_FTP= Yes
PERMIT_DISTFILES_CDROM=Yes
PERMIT_DISTFILES_FTP= Yes
-WANTLIB= bz2>=10 c crypto m ssl z
+WANTLIB= bz2>=10 c crypto lzma m ssl z
MASTER_SITES= ${HOMEPAGE}download/
-LIB_DEPENDS= archivers/bzip2
+LIB_DEPENDS= archivers/bzip2 \
+ archivers/xz
AUTOCONF_VERSION=2.13
CONFIGURE_STYLE= autoconf
Re: lang/go build failing on i386
On Sun, Sep 16, 2012 at 16:58, Aaron Bieber wrote:
> I applied this diff, rebooted and successfully built lang/go, but I seem
> to be running into some pretty strange issues trying to go programs.
>
> Perhaps I did something wrong.. but every time I try to compile the
> below I get: "/usr/local/bin/go[1]: syntax error: `(' unexpected"
>
> package main
>
> import "fmt"
>
> func main{
> fmt.Println("hello world")
> }
>
> gofmt of the file containing above code results in:
> "/usr/local/bin/gofmt[1]: syntax error: `^W^Z4' unexpected"
That's more or less the same problem. If the kernel doesn't recognize
the resulting binaries, they are treated as shell scripts, and
obviously sh doesn't know what to do with them.
Re: lang/go build failing on i386
I applied this diff, rebooted and successfully built lang/go, but I seem
to be running into some pretty strange issues trying to go programs.
Perhaps I did something wrong.. but every time I try to compile the
below I get: "/usr/local/bin/go[1]: syntax error: `(' unexpected"
package main
import "fmt"
func main{
fmt.Println("hello world")
}
gofmt of the file containing above code results in:
"/usr/local/bin/gofmt[1]: syntax error: `^W^Z4' unexpected"
On Thu, Sep 13, 2012 at 04:10:31PM -0700, Matthew Dempsky wrote:
> On Thu, Sep 13, 2012 at 11:26:39PM +0100, Stuart Henderson wrote:
> > Seeing this repeatably fail in my current i386 build, the go port hasn't
> > changed, anyone have an idea what might be doing it?
>
> As mentioned on icb, the Go linker doesn't set a PT_NOTE segment for
> OpenBSD identification like it does for NetBSD executables. However,
> it does set EI_OSABI to ELFOSABI_OPENBSD, and it probably wouldn't
> hurt for the kernel to skip the PT_NOTE check in that case.
>
> Please try this diff to see if it fixes lang/go. (Sorry, untested.)
>
>
> Index: exec_elf.c
> ===
> RCS file: /cvs/src/sys/kern/exec_elf.c,v
> retrieving revision 1.88
> diff -u -p -r1.88 exec_elf.c
> --- exec_elf.c11 Sep 2012 15:44:19 - 1.88
> +++ exec_elf.c13 Sep 2012 23:07:36 -
> @@ -592,7 +592,8 @@ ELFNAME2(exec,makecmds)(struct proc *p,
>* set the ep_emul field in the exec package structure.
>*/
> error = ENOEXEC;
> - if (ELFNAME(os_pt_note)(p, epp, epp->ep_hdr, "OpenBSD", 8, 4) != 0) {
> + if (eh->e_ident[EI_OSABI] != ELFOSABI_OPENBSD &&
> + ELFNAME(os_pt_note)(p, epp, epp->ep_hdr, "OpenBSD", 8, 4) != 0) {
> for (i = 0; ELFNAME(probes)[i].func != NULL && error; i++)
> error = (*ELFNAME(probes)[i].func)(p, epp, interp,
> &pos);
> if (error)
>
Re: hs-* fallout, some notes about ghc
On 09/16/12 22:43, Matthias Kilian wrote: > Hi, > > On Sun, Sep 16, 2012 at 10:16:40PM +0100, Nigel Taylor wrote: >> Message-ID: <505641b8.9040...@asterisk.demon.co.uk> >> Date: Sun, 16 Sep 2012 22:16:40 +0100 >> From: Nigel Taylor >> To: ports >> Subject: Re: hs-* fallout, some notes about ghc >> >> On 09/08/12 22:22, Matthias Kilian wrote: >>> Please be aware that the patch is *not* a proper fix but rather a >>> quick hack. I only want to see wether it's worth patching ghc's >>> internal linker at all. The other option would be to enable shared >>> haskell libraries. > [...] >> Missed the e-mail on @ports till mentioned on icb, have only just tried this >> >> I applied the patches to both amd64 and i386, the two failing ports >> hs-vector and hs-type-level built on i386, not on amd64. > > Thanks for the tests. > > On amd64, did you still get messages like > > Loading package integer-gmp ... linking ... ghc: /usr/local/lib/libgmp.a: > unknown symbol `__guard_local' > > or just segfaults? (I'd expect the latter). > > Anyway, I tried to understand ghc's own runtime linker this day, > and got lost in #ifdef hell, so I'll probably just enable shared > libraries in ghc (in the hope that ghci will use dlopen(3) to load > hs-libraries). > > Ciao, > Kili > This is from log... Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.0 ... linking ... done. Loading package deepseq-1.3.0.0 ... linking ... done. Loading package containers-0.4.2.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-0.3.6.1 ... linking ... done. src/Data/TypeLevel/Num/Aliases.hs:24:1: Warning: The import of `Data.TypeLevel.Num.Reps' is redundant except perhaps to import instances from `Data.TypeLevel.Num.Reps' To import instances alone, use: import Data.TypeLevel.Num.Reps() [5 of 8] Compiling Data.TypeLevel.Bool ( src/Data/TypeLevel/Bool.hs, dist/build/Data/TypeLevel/Bool.o ) [6 of 8] Compiling Data.TypeLevel.Num.Ops ( src/Data/TypeLevel/Num/Ops.hs, dist/build/Data/TypeLevel/Num/Ops.o ) [7 of 8] Compiling Data.TypeLevel.Num ( src/Data/TypeLevel/Num.hs, dist/build/Data/TypeLevel/Num.o ) [8 of 8] Compiling Data.TypeLevel ( src/Data/TypeLevel.hs, dist/build/Data/TypeLevel.o ) Linking... /usr/bin/ar -r dist/build/libHStype-level-0.2.4.a dist/build/Data/TypeLevel.o dist/build/Data/TypeLevel/Bool.o dist/build/Data/TypeLevel/Num.o dist/build/Data/TypeLevel/Num/Reps.o dist/build/Data/TypeLevel/Nu m/Aliases.o dist/build/Data/TypeLevel/Num/Sets.o dist/build/Data/TypeLevel/Num/Ops.o dist/build/Data/TypeLevel/Num/Aliases/TH.o /usr/bin/ar: creating dist/build/libHStype-level-0.2.4.a /usr/bin/ld -x -r -o dist/build/HStype-level-0.2.4.o dist/build/Data/TypeLevel.o dist/build/Data/TypeLevel/Bool.o dist/build/Data/TypeLevel/Num.o dist/build/Data/TypeLevel/Num/Reps.o dist/build/Data/TypeLevel /Num/Aliases.o dist/build/Data/TypeLevel/Num/Sets.o dist/build/Data/TypeLevel/Num/Ops.o dist/build/Data/TypeLevel/Num/Aliases/TH.o Registering type-level-0.2.4... /usr/local/bin/ghc-pkg update - --global --no-user-package-conf --package-conf=dist/package.conf.inplace Running Haddock for type-level-0.2.4... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Preprocessing library type-level-0.2.4... haddock: /usr/local/lib/libgmp.a: unknown symbol `__guard_local' Haddock coverage: 100% ( 13 / 13) in 'Data.TypeLevel.Num.Reps' 100% ( 6 / 6) in 'Data.TypeLevel.Num.Sets' 67% ( 2 / 3) in 'Data.TypeLevel.Num.Aliases.TH' haddock: unable to load package `integer-gmp' I didn't look closely at the log just saw the error from dpb, log has a different message, from haddock, maybe I needed to rebuild haddock and other ghc packages. Looks like it got past load integer-gmp, which failed before. Checked i386 haddock was built after ghc, amd64 haddock built before ghc. Rebuilt haddock on amd64, then both hs-vector hs-type-level built. Needed a bump in ghc to force rebuild of haddock.
Re: hs-* fallout, some notes about ghc
Hi, On Sun, Sep 16, 2012 at 10:16:40PM +0100, Nigel Taylor wrote: > Message-ID: <505641b8.9040...@asterisk.demon.co.uk> > Date: Sun, 16 Sep 2012 22:16:40 +0100 > From: Nigel Taylor > To: ports > Subject: Re: hs-* fallout, some notes about ghc > > On 09/08/12 22:22, Matthias Kilian wrote: > > Please be aware that the patch is *not* a proper fix but rather a > > quick hack. I only want to see wether it's worth patching ghc's > > internal linker at all. The other option would be to enable shared > > haskell libraries. [...] > Missed the e-mail on @ports till mentioned on icb, have only just tried this > > I applied the patches to both amd64 and i386, the two failing ports > hs-vector and hs-type-level built on i386, not on amd64. Thanks for the tests. On amd64, did you still get messages like Loading package integer-gmp ... linking ... ghc: /usr/local/lib/libgmp.a: unknown symbol `__guard_local' or just segfaults? (I'd expect the latter). Anyway, I tried to understand ghc's own runtime linker this day, and got lost in #ifdef hell, so I'll probably just enable shared libraries in ghc (in the hope that ghci will use dlopen(3) to load hs-libraries). Ciao, Kili
Re: hs-* fallout, some notes about ghc
On 09/08/12 22:22, Matthias Kilian wrote:
> Hi,
>
> On Wed, Sep 05, 2012 at 10:01:37PM +0100, Stuart Henderson wrote:
>>> After the switch to __guard_local, ghc's "dynamic linker" currently
>>> doesn't work any longer, which causes *at least* devel/hs-vector
>>> and devel/hs-type-level builds to fail (probably other hs-* ports
>>> that use template-Haskell. I'm awaere of it, and I hope to find
>>> time to fix this soon.
>>
>> In an i386 bulk, these 2 were the only hs-* ports failing (plus any
>> depending on these which were knocked out of the build)
>
> And those depending are really wubscale ;-)
>
>> Both were related to gmp,
>>
>> Loading package integer-gmp ... linking ... ghc: /usr/local/lib/libgmp.a:
>> unknown symbol `__guard_local'
>
> Does the attached patch on i386
>
> - help to build hs-vector and hs-type-level,
>
> - allow to start ghci without immediately failing when loading
> integer-gmp?
>
> Please be aware that the patch is *not* a proper fix but rather a
> quick hack. I only want to see wether it's worth patching ghc's
> internal linker at all. The other option would be to enable shared
> haskell libraries.
>
> Ciao,
> Kili
>
>
> Index: patches/patch-rts_Linker_c
> ===
> RCS file: patches/patch-rts_Linker_c
> diff -N patches/patch-rts_Linker_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-rts_Linker_c8 Sep 2012 21:08:43 -
> @@ -0,0 +1,33 @@
> +$OpenBSD$
> +--- rts/Linker.c.origWed Jun 6 19:10:25 2012
> rts/Linker.c Fri Sep 7 00:46:07 2012
> +@@ -563,6 +563,13 @@ typedef struct _RtsSymbolVal {
> + #define RTS_DARWIN_ONLY_SYMBOLS
> + #endif
> +
> ++#if defined(openbsd_HOST_OS)
> ++#define RTS_OPENBSD_ONLY_SYMBOLS\
> ++ SymE_NeedsProto(__guard_local)
> ++#else
> ++#define RTS_OPENBSD_ONLY_SYMBOLS
> ++#endif
> ++
> + #ifndef SMP
> + # define MAIN_CAP_SYM SymI_HasProto(MainCapability)
> + #else
> +@@ -1084,6 +1091,7 @@ RTS_POSIX_ONLY_SYMBOLS
> + RTS_MINGW_ONLY_SYMBOLS
> + RTS_CYGWIN_ONLY_SYMBOLS
> + RTS_DARWIN_ONLY_SYMBOLS
> ++RTS_OPENBSD_ONLY_SYMBOLS
> + RTS_LIBGCC_SYMBOLS
> + RTS_LIBFFI_SYMBOLS
> + #undef SymI_NeedsProto
> +@@ -1119,6 +1127,7 @@ static RtsSymbolVal rtsSyms[] = {
> + RTS_MINGW_ONLY_SYMBOLS
> + RTS_CYGWIN_ONLY_SYMBOLS
> + RTS_DARWIN_ONLY_SYMBOLS
> ++ RTS_OPENBSD_ONLY_SYMBOLS
> + RTS_LIBGCC_SYMBOLS
> + RTS_LIBFFI_SYMBOLS
> + #if defined(darwin_HOST_OS) && defined(i386_HOST_ARCH)
>
>
Missed the e-mail on @ports till mentioned on icb, have only just tried this
I applied the patches to both amd64 and i386, the two failing ports
hs-vector and hs-type-level built on i386, not on amd64.
Re: [patch] Add static FLAVOR to www/cgit-8.3.5p1 (OPENBSD_5_1)
On Sun, Sep 16, 2012 at 12:11:10PM +0100, Stuart Henderson wrote:
> On 2012/09/16 10:56, Olivier Mehani wrote:
> > Hi all,
> >
> > Cgit in ports seems to be a ligtweight web interface to Git. However, to
> > run its binary from ports in a chroot requires to copy a bunch of
> > libraries in the chroot (or ???Premature end of script headers:
> > /cgi-bin/cgit.cgi??? will ensue; `ldd /var/www/cgi-bin/cgit.cgi` is your
> > friend), which I'd rather not.
> >
> > The attached patch to the Makefile fixes this by adding a static flavour
> > to the port. I have it running on my 5.1 server at the moment, without
> > shared libs, and it seems to behave fine, but I haven't tested it
> > thoroughly yet.
>
> Is there any point in making this a flavour, wouldn't this be a
> sane thing to do by default?
>
> > There might be a mistake in the way I handled the MODULES variable (it's
> > unconditionally set), which might result in the -static package to have
> > a spurious dependency. I'm happy to be corrected on that (:
>
> That's ok, you should have the dependency listed.
>
> For statically linked things I would also continue to use the WANTLIB
> on c/crypto/pthread/z even though it shows as "extra" in check-lib-depends,
> otherwise fixes in the base libraries won't trigger the package getting
> updated.
>
> btw this needs testing on -current before it can go in, 5.1 (and even
> 5.2) is too old for a valid test.
Here's a (simpler?) diff for -current that seems to work here.
Landry
Index: Makefile
===
RCS file: /cvs/ports/www/cgit/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile6 Mar 2012 17:17:09 - 1.5
+++ Makefile16 Sep 2012 19:15:03 -
@@ -3,6 +3,7 @@
COMMENT = web frontend for git repositories
DISTNAME = cgit-0.9.0.2
+REVISION = 0
CATEGORIES = www devel
DISTFILES =cgit-0.9.0.2.tar.gz:0 \
@@ -26,7 +27,7 @@
WANTLIB += c crypto pthread z
PREFIX = /var/www
-MAKE_FLAGS += V=1 NEEDS_LIBICONV=1 LDFLAGS+=-L${LOCALBASE}/lib
+MAKE_FLAGS += V=1 NEEDS_LIBICONV=1 LDFLAGS+='-static -L${LOCALBASE}/lib'
post-extract:
rmdir ${WRKSRC}/git
Re: databases/mongodb builds twice
On Sun, Sep 16, 2012 at 12:26:37AM +0100, Federico Schwindt wrote: > On Sat, Sep 15, 2012 at 11:33 PM, Christian Weisgerber > wrote: > > To whoever cares about databases/mongodb... > > > > I noticed that mongodb was spending an extraordinary amount of time > > in the fake stage, and a look at the log files shows that it actually > > builds all over again during fake. This appears to be a popular > > problem with scons-based ports. > > I will take a look. Yes, most scons ports do that, istr mapnik & archiveopteryx showed that broken behaviour. Landry
Re: vim with python support
On Sun, Sep 16, 2012 at 12:12:54PM -0500, Chris Bennett wrote: > On Sun, Sep 16, 2012 at 01:36:21AM +0200, Juan Francisco Cantero Hurtado > wrote: > > Yesterday I wanted install vim with python support enabled and no > > package was available in the FTP with this FLAVOR. The only FLAVORS > > available are gtk2 and no_x11. > > > > I use a feature of vim that requires python. Also I've read about > > plugins used by rails programmers that need the ruby support. If you > > search "openbsd vim python ports", you can see other users with the same > > problem. > > > > Any reason for not enable perl/python/ruby? :) > > > > Look at the vim port Makefile. > Look at the FLAVORS. > Try FLAVOR:Mpython > FLAVOR:Mruby > FLAVOR:Mhuge > FLAVOR:Mperl > > I don't have a copy of any -release versions, but that is what I find > in -current Makefile No. I was talking about the packages :) . The bulk build only builds the packages (and flavors) linked within editors/Makefile. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: vim with python support
On Sun, Sep 16, 2012 at 01:36:21AM +0200, Juan Francisco Cantero Hurtado wrote: > Yesterday I wanted install vim with python support enabled and no > package was available in the FTP with this FLAVOR. The only FLAVORS > available are gtk2 and no_x11. > > I use a feature of vim that requires python. Also I've read about > plugins used by rails programmers that need the ruby support. If you > search "openbsd vim python ports", you can see other users with the same > problem. > > Any reason for not enable perl/python/ruby? :) > Look at the vim port Makefile. Look at the FLAVORS. Try FLAVOR:Mpython FLAVOR:Mruby FLAVOR:Mhuge FLAVOR:Mperl I don't have a copy of any -release versions, but that is what I find in -current Makefile Chris Bennett > > Index: Makefile > === > RCS file: /cvs/ports/editors/Makefile,v > retrieving revision 1.88 > diff -u -p -r1.88 Makefile > --- Makefile 18 Aug 2012 07:25:25 - 1.88 > +++ Makefile 15 Sep 2012 22:57:28 - > @@ -53,7 +53,9 @@ > SUBDIR += texworks > SUBDIR += uemacs > SUBDIR += vim > + SUBDIR += vim,gtk2,perl,python,ruby > SUBDIR += vim,no_x11 > + SUBDIR += vim,no_x11,perl,python,ruby > SUBDIR += vim-spell > SUBDIR += xemacs21 > SUBDIR += xemacs21-sumo >
catppt coredump
Is anybody using catppt to extract information from ppt slides? This is what I get when trying to run catppt on a slides somebody sent me $ gdb -c catppt.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd5.1". Core was generated by `catppt'. Program terminated with signal 11, Segmentation fault. #0 0x1c00363a in ?? () My machine $ uname -a OpenBSD oko.bagdala2.net 5.1 GENERIC.MP#188 i386 Can anybody recommend another command line tool or script which can be used instead. I do not like to have OO on my computer so for now I am forced to upload things on Microsoft skydrive. Thanks, Predrag
NEW: net/ngircd
Hi, Attached is a port of ngircd, a lightweight irc server. I've been running it for a few days and I'm quite happy. Comments? OK? f.- ngircd.tgz Description: GNU Zip compressed data
Re: Intel GM 3150 driver
better ask on misc@ On Sun, Sep 16, 2012 at 12:24:19PM +0100, Mike Williams wrote: ; Hi, ; ; An old VIA mini-itx board has died after 5 years continuous use and ; I want replace the m/board (low power and case size is useful to ; me). I use it as a desktop machine so looking for better than VESA ; fb graphics support but not used for games so not looking for ; stellar 3D performance. ; ; VIA seem to have all but dropped out of the retail market, all I can ; find is the VIA VE-900 with VX900 which seems to be too bleedin' ; edge for openchrome support for a year or so. ; ; So I am looking at the Gigabyte GA-D525TUD with a Intel GMA 3150. ; The only references I can find on marc.info are from 2 years ago and ; implies it has been supported since OBSD 4.8. It is not listed ; under the intel(4) driver. Can anyone confirm it is supported? And ; if so which driver is used? ; ; One alternative is the Intel D2700MUD with an Intel GMA 3650 which ; seems to be a re-badged PowerVR. But all I can google up is that ; Intel have no open-sourced their drivers so seem unlikely to be ; supported by OBSD. ; ; Any experiences with using OBSD for desktop use on mini-itx boards ; much appreciated. FWIW the case is small (wont support a video ; card) with an 80W supply a HDD and a DVD drive, so a socketed ; m/board is not an option. ; ; Mike ; -- Sending from my VCR...
Re: Intel GM 3150 driver
My real bad - sent to wrong list. Resent to misc@, any replies to there please. I'll get my coat ... On 16/09/2012 12:24, Mike Williams wrote: Hi, An old VIA mini-itx board has died after 5 years continuous use and I want replace the m/board (low power and case size is useful to me). I use it as a desktop machine so looking for better than VESA fb graphics support but not used for games so not looking for stellar 3D performance. VIA seem to have all but dropped out of the retail market, all I can find is the VIA VE-900 with VX900 which seems to be too bleedin' edge for openchrome support for a year or so. So I am looking at the Gigabyte GA-D525TUD with a Intel GMA 3150. The only references I can find on marc.info are from 2 years ago and implies it has been supported since OBSD 4.8. It is not listed under the intel(4) driver. Can anyone confirm it is supported? And if so which driver is used? One alternative is the Intel D2700MUD with an Intel GMA 3650 which seems to be a re-badged PowerVR. But all I can google up is that Intel have no open-sourced their drivers so seem unlikely to be supported by OBSD. Any experiences with using OBSD for desktop use on mini-itx boards much appreciated. FWIW the case is small (wont support a video card) with an 80W supply a HDD and a DVD drive, so a socketed m/board is not an option. Mike
Intel GM 3150 driver
Hi, An old VIA mini-itx board has died after 5 years continuous use and I want replace the m/board (low power and case size is useful to me). I use it as a desktop machine so looking for better than VESA fb graphics support but not used for games so not looking for stellar 3D performance. VIA seem to have all but dropped out of the retail market, all I can find is the VIA VE-900 with VX900 which seems to be too bleedin' edge for openchrome support for a year or so. So I am looking at the Gigabyte GA-D525TUD with a Intel GMA 3150. The only references I can find on marc.info are from 2 years ago and implies it has been supported since OBSD 4.8. It is not listed under the intel(4) driver. Can anyone confirm it is supported? And if so which driver is used? One alternative is the Intel D2700MUD with an Intel GMA 3650 which seems to be a re-badged PowerVR. But all I can google up is that Intel have no open-sourced their drivers so seem unlikely to be supported by OBSD. Any experiences with using OBSD for desktop use on mini-itx boards much appreciated. FWIW the case is small (wont support a video card) with an 80W supply a HDD and a DVD drive, so a socketed m/board is not an option. Mike
Re: [patch] Add static FLAVOR to www/cgit-8.3.5p1 (OPENBSD_5_1)
On 2012/09/16 10:56, Olivier Mehani wrote: > Hi all, > > Cgit in ports seems to be a ligtweight web interface to Git. However, to > run its binary from ports in a chroot requires to copy a bunch of > libraries in the chroot (or “Premature end of script headers: > /cgi-bin/cgit.cgi” will ensue; `ldd /var/www/cgi-bin/cgit.cgi` is your > friend), which I'd rather not. > > The attached patch to the Makefile fixes this by adding a static flavour > to the port. I have it running on my 5.1 server at the moment, without > shared libs, and it seems to behave fine, but I haven't tested it > thoroughly yet. Is there any point in making this a flavour, wouldn't this be a sane thing to do by default? > There might be a mistake in the way I handled the MODULES variable (it's > unconditionally set), which might result in the -static package to have > a spurious dependency. I'm happy to be corrected on that (: That's ok, you should have the dependency listed. For statically linked things I would also continue to use the WANTLIB on c/crypto/pthread/z even though it shows as "extra" in check-lib-depends, otherwise fixes in the base libraries won't trigger the package getting updated. btw this needs testing on -current before it can go in, 5.1 (and even 5.2) is too old for a valid test.
[Update] pgpool 3.2.0
Hi, Diff to update pgpool to it's latest version (and allow it to build with postgresql 9.2). Tested on @amd64 and @i386. Regards, Index: Makefile === RCS file: /cvs/ports/databases/pgpool/Makefile,v retrieving revision 1.2 diff -u -p -r1.2 Makefile --- Makefile 18 Jun 2012 11:39:47 - 1.2 +++ Makefile 16 Sep 2012 10:34:13 - @@ -2,7 +2,7 @@ COMMENT= connection pool server for PostgreSQL -DISTNAME= pgpool-II-3.1.3 +DISTNAME= pgpool-II-3.2.0 CATEGORIES= databases @@ -20,7 +20,7 @@ PERMIT_DISTFILES_CDROM= Yes MASTER_SITES= http://www.pgpool.net/mediawiki/images/ -WANTLIB= c crypto m pq ssl +WANTLIB= c crypto m pq ssl pthread CONFIGURE_STYLE= gnu CONFIGURE_ARGS= --with-openssl Index: distinfo === RCS file: /cvs/ports/databases/pgpool/distinfo,v retrieving revision 1.2 diff -u -p -r1.2 distinfo --- distinfo 18 Jun 2012 11:39:47 - 1.2 +++ distinfo 16 Sep 2012 10:34:13 - @@ -1,5 +1,2 @@ -MD5 (pgpool-II-3.1.3.tar.gz) = MJT0qMwkp/9eQON7HbJD5w== -RMD160 (pgpool-II-3.1.3.tar.gz) = LjXUX0iIfmJOA+KdISCACHjIZpo= -SHA1 (pgpool-II-3.1.3.tar.gz) = meRb0hireA6YIRaGD+4RpgW9g08= -SHA256 (pgpool-II-3.1.3.tar.gz) = 5Oud2AmkuPOWJ2lVjs6lJJCO3+1YFrcSC0SPTq/YIkk= -SIZE (pgpool-II-3.1.3.tar.gz) = 1402843 +SHA256 (pgpool-II-3.2.0.tar.gz) = LkHOeBVPx+nhPrNPC2DjUtYYPeCMQEC+qfvdkU4+KOA= +SIZE (pgpool-II-3.2.0.tar.gz) = 1599391 Index: patches/patch-pool_memqcache_c === RCS file: patches/patch-pool_memqcache_c diff -N patches/patch-pool_memqcache_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-pool_memqcache_c 16 Sep 2012 10:34:13 - @@ -0,0 +1,11 @@ +$OpenBSD$ +--- pool_memqcache.c.orig Sun Sep 16 12:23:15 2012 pool_memqcache.c Sun Sep 16 12:23:26 2012 +@@ -36,6 +36,7 @@ + #include + #include + #include ++#include + + #ifdef USE_MEMCACHED + #include Index: patches/patch-pool_select_walker_c === RCS file: patches/patch-pool_select_walker_c diff -N patches/patch-pool_select_walker_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-pool_select_walker_c 16 Sep 2012 10:34:13 - @@ -0,0 +1,11 @@ +$OpenBSD$ +--- pool_select_walker.c.orig Sun Sep 16 12:30:03 2012 pool_select_walker.c Sun Sep 16 12:30:16 2012 +@@ -22,6 +22,7 @@ + #include + #include + #include ++#include + + #include "pool.h" + #include "pool_config.h" Index: patches/patch-watchdog_watchdog_c === RCS file: patches/patch-watchdog_watchdog_c diff -N patches/patch-watchdog_watchdog_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-watchdog_watchdog_c 16 Sep 2012 10:34:13 - @@ -0,0 +1,11 @@ +$OpenBSD$ +--- watchdog/watchdog.c.orig Sun Sep 16 12:26:05 2012 watchdog/watchdog.c Sun Sep 16 12:26:12 2012 +@@ -25,7 +25,6 @@ + #include + #include + #include +-#include + #include + #include + #include Index: patches/patch-watchdog_wd_lifecheck_c === RCS file: patches/patch-watchdog_wd_lifecheck_c diff -N patches/patch-watchdog_wd_lifecheck_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-watchdog_wd_lifecheck_c 16 Sep 2012 10:34:13 - @@ -0,0 +1,11 @@ +$OpenBSD$ +--- watchdog/wd_lifecheck.c.orig Sun Sep 16 12:23:44 2012 watchdog/wd_lifecheck.c Sun Sep 16 12:23:52 2012 +@@ -30,6 +30,7 @@ + #include + #include + #include ++#include + #include "pool.h" + #include "pool_config.h" + #include "watchdog.h" Index: patches/patch-watchdog_wd_packet_c === RCS file: patches/patch-watchdog_wd_packet_c diff -N patches/patch-watchdog_wd_packet_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-watchdog_wd_packet_c 16 Sep 2012 10:34:13 - @@ -0,0 +1,16 @@ +$OpenBSD$ +--- watchdog/wd_packet.c.orig Sun Sep 16 12:24:07 2012 watchdog/wd_packet.c Sun Sep 16 12:24:23 2012 +@@ -34,10 +34,12 @@ + #include + #include + #include ++#include + #include + #include + #include + #include ++#include + + #include "pool.h" + #include "pool_config.h" Index: patches/patch-watchdog_wd_ping_c === RCS file: patches/patch-watchdog_wd_ping_c diff -N patches/patch-watchdog_wd_ping_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-watchdog_wd_ping_c 16 Sep 2012 10:34:13 - @@ -0,0 +1,11 @@ +$OpenBSD$ +--- watchdog/wd_ping.c.orig Sun Sep 16 12:24:32 2012 watchdog/wd_ping.c Sun Sep 16 12:24:44 2012 +@@ -31,6 +31,7 @@ + #include + #include + #include ++#include + #include "pool.h" + #include "pool_config.h" + #include "watchdog.h"
audio/ardour builds twice
Christian Weisgerber wrote: > I noticed that mongodb was spending an extraordinary amount of time > in the fake stage, and a look at the log files shows that it actually > builds all over again during fake. This appears to be a popular > problem with scons-based ports. audio/ardour has the same problem. -- Christian "naddy" Weisgerber na...@mips.inka.de
[Update] Skytools 3.1
Hi,
This a major update to skytools 3.1.
Tested on @amd64 with PostgreSQL 9.2.
Comments/feedbacks welcome.
Regards,Index: Makefile
===
RCS file: /cvs/ports/databases/skytools/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile 4 Nov 2011 08:16:24 - 1.16
+++ Makefile 16 Sep 2012 10:07:06 -
@@ -2,9 +2,8 @@
COMMENT= PostgreSQL tools from Skype
-MODPY_EGG_VERSION= 2.1.12
+MODPY_EGG_VERSION= 3.1
DISTNAME= skytools-${MODPY_EGG_VERSION}
-REVISION = 2
CATEGORIES= databases
@@ -20,7 +19,7 @@ PERMIT_DISTFILES_CDROM= Yes
WANTLIB= c ${MODPY_WANTLIB}
-MASTER_SITES= http://pgfoundry.org/frs/download.php/2872/
+MASTER_SITES= http://pgfoundry.org/frs/download.php/3321/
MODULES= lang/python
@@ -45,10 +44,5 @@ pre-configure:
@find ${WRKSRC} -name '*.py' \
-exec perl -pi -e 's,/usr/bin/env python,${MODPY_BIN},' {} \;
@perl -pi -e 's,share/doc,share/examples,' ${WRKSRC}/setup.py
-
-post-install:
-.for i in ${BINFILES}
- @cd ${PREFIX}/bin && mv ${i} `basename ${i} .py`
-.endfor
.include
Index: distinfo
===
RCS file: /cvs/ports/databases/skytools/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo 16 Nov 2010 12:28:42 - 1.7
+++ distinfo 16 Sep 2012 10:07:06 -
@@ -1,5 +1,2 @@
-MD5 (skytools-2.1.12.tar.gz) = lPM5HVs8OsbC7cv72nBVcw==
-RMD160 (skytools-2.1.12.tar.gz) = GYNWB3kRkOdErvTX8ViedySux3w=
-SHA1 (skytools-2.1.12.tar.gz) = ttriWLVBrDALBb60oU4D5vsoW80=
-SHA256 (skytools-2.1.12.tar.gz) = 84WUexIaBdnWTKcN1GWF9ZIWGtk5MDc167nWLyRtasA=
-SIZE (skytools-2.1.12.tar.gz) = 259101
+SHA256 (skytools-3.1.tar.gz) = uSo4eKcRwlekTdci2q4l3uUEGwS1nlGtihCy2Z9STpc=
+SIZE (skytools-3.1.tar.gz) = 620850
Index: patches/patch-doc_Makefile
===
RCS file: /cvs/ports/databases/skytools/patches/patch-doc_Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 patch-doc_Makefile
--- patches/patch-doc_Makefile 16 Nov 2010 12:28:42 - 1.2
+++ patches/patch-doc_Makefile 16 Sep 2012 10:07:06 -
@@ -1,12 +1,14 @@
$OpenBSD: patch-doc_Makefile,v 1.2 2010/11/16 12:28:42 pea Exp $
doc/Makefile.orig Wed Nov 10 14:26:13 2010
-+++ doc/Makefile Tue Nov 16 11:34:20 2010
-@@ -21,7 +21,7 @@ SCRIPT_HTMLS = $(SCRIPT_TXTS:.txt=.html)
+--- doc/Makefile.orig Thu Jul 19 13:27:01 2012
doc/Makefile Wed Sep 12 13:56:46 2012
+@@ -34,8 +34,8 @@ FQMAN = $(FQMAN1) $(FQMAN1_SFX) $(FQMAN5)
- COMMON = common.switches.txt common.config.txt common.logutriga.txt
+ COMMON = common.switches.txt common.config.txt
--GETATTRS = python ./getattrs.py
-+GETATTRS = ${MODPY_BIN} ./getattrs.py
-
- all: man
+-GETATTRS = python ../misc/getattrs.py
+-FIXMAN = python ../misc/fixman.py
++GETATTRS = ${MODPY_BIN} ../misc/getattrs.py
++FIXMAN = ${MODPY_BIN} ../misc/fixman.py
+ #AFLAGS = -a linkcss
+ #AFLAGS = -a stylesheet=extra.css
Index: pkg/PLIST
===
RCS file: /cvs/ports/databases/skytools/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 10 Apr 2009 12:00:13 - 1.4
+++ pkg/PLIST 16 Sep 2012 10:07:06 -
@@ -1,28 +1,44 @@
@comment $OpenBSD: PLIST,v 1.4 2009/04/10 12:00:13 pea Exp $
-bin/bulk_loader
-bin/cube_dispatcher
-bin/londiste
-bin/pgqadm
-bin/queue_mover
-bin/queue_splitter
-bin/scriptmgr
-bin/skytools_upgrade
-bin/table_dispatcher
-bin/walmgr
-lib/postgresql/logtriga.so
+bin/londiste3
+@bin bin/pgqd
+bin/qadmin
+bin/queue_mover3
+bin/queue_splitter3
+bin/scriptmgr3
+bin/simple_consumer3
+bin/simple_local_consumer3
+bin/skytools_upgrade3
+bin/walmgr3
lib/postgresql/pgq_lowlevel.so
lib/postgresql/pgq_triggers.so
lib/python${MODPY_VERSION}/site-packages/londiste/
lib/python${MODPY_VERSION}/site-packages/londiste/__init__.py
lib/python${MODPY_VERSION}/site-packages/londiste/__init__.pyc
+lib/python${MODPY_VERSION}/site-packages/londiste/bublin.py
+lib/python${MODPY_VERSION}/site-packages/londiste/bublin.pyc
lib/python${MODPY_VERSION}/site-packages/londiste/compare.py
lib/python${MODPY_VERSION}/site-packages/londiste/compare.pyc
-lib/python${MODPY_VERSION}/site-packages/londiste/file_read.py
-lib/python${MODPY_VERSION}/site-packages/londiste/file_read.pyc
-lib/python${MODPY_VERSION}/site-packages/londiste/file_write.py
-lib/python${MODPY_VERSION}/site-packages/londiste/file_write.pyc
-lib/python${MODPY_VERSION}/site-packages/londiste/installer.py
-lib/python${MODPY_VERSION}/site-packages/londiste/installer.pyc
+lib/python${MODPY_VERSION}/site-packages/londiste/exec_attrs.py
+lib/python${MODPY_VERSION}/site-packages/londiste/exec_attrs.pyc
+lib/python${MODPY_VERSION}/site-packages/londiste/handler.py
+lib/python${MODPY_VERSION}/site-packages/londiste/handler.pyc
+lib/python${MODPY_VERSION}/site-packages/londiste/handlers/
+lib/python${MODPY_VERSION}/site-packages/londiste/handlers/__init__.py
+l
[patch] Add static FLAVOR to www/cgit-8.3.5p1 (OPENBSD_5_1)
Hi all,
Cgit in ports seems to be a ligtweight web interface to Git. However, to
run its binary from ports in a chroot requires to copy a bunch of
libraries in the chroot (or ???Premature end of script headers:
/cgi-bin/cgit.cgi??? will ensue; `ldd /var/www/cgi-bin/cgit.cgi` is your
friend), which I'd rather not.
The attached patch to the Makefile fixes this by adding a static flavour
to the port. I have it running on my 5.1 server at the moment, without
shared libs, and it seems to behave fine, but I haven't tested it
thoroughly yet.
There might be a mistake in the way I handled the MODULES variable (it's
unconditionally set), which might result in the -static package to have
a spurious dependency. I'm happy to be corrected on that (:
Hope this helps!
--
Olivier Mehani
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655
Index: Makefile
===
@@ -23,8 +23,17 @@
USE_GMAKE =yes
+FLAVORS= static
+FLAVOR?=
+
MODULES = converters/libiconv
+.if ${FLAVOR:L} == "static"
+CFLAGS += -static
+LDFLAGS += -static
+MAKEFLAGS += CFLAGS+=-static LDFLAGS+=-static
+.else
WANTLIB += c crypto pthread z
+.endif
PREFIX = /var/www
MAKE_FLAGS += V=1 NEEDS_LIBICONV=1 LDFLAGS+=-L${LOCALBASE}/lib
[UPDATE] www/py-tornado
Hi,
this is the diff to update tornado to last release: 2.4.
Are you ok?
Cheers,
Remi.
Index: Makefile
===
RCS file: /cvs/ports/www/py-tornado/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile3 Jul 2012 09:00:33 - 1.4
+++ Makefile16 Sep 2012 07:53:26 -
@@ -2,7 +2,7 @@
COMMENT = scalable, non-blocking web server
-MODPY_EGG_VERSION =2.3
+MODPY_EGG_VERSION =2.4
DISTNAME = tornado-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
Index: distinfo
===
RCS file: /cvs/ports/www/py-tornado/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo3 Jul 2012 09:00:33 - 1.4
+++ distinfo16 Sep 2012 07:53:26 -
@@ -1,5 +1,2 @@
-MD5 (tornado-2.3.tar.gz) = gQw+zUJZJPvwqh+gQPk60Q==
-RMD160 (tornado-2.3.tar.gz) = sydGyIo8/g4yf4ef2XjLDx/5hAI=
-SHA1 (tornado-2.3.tar.gz) = Cr7GrMK6iAyq39ppDN63P0RbwHI=
-SHA256 (tornado-2.3.tar.gz) = Yn71i3E0eByBSsgdg81DXUuevztbqUwhAqEll0DEQVw=
-SIZE (tornado-2.3.tar.gz) = 338950
+SHA256 (tornado-2.4.tar.gz) = FU9pVH/Ucx80crQJQFVWfDg2sq9hMGhJnMbQnCMz/78=
+SIZE (tornado-2.4.tar.gz) = 347522
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/py-tornado/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 3 Jul 2012 09:00:33 - 1.2
+++ pkg/PLIST 16 Sep 2012 07:53:26 -
@@ -61,12 +61,19 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/tornado/test/__init__.pyc
lib/python${MODPY_VERSION}/site-packages/tornado/test/auth_test.py
lib/python${MODPY_VERSION}/site-packages/tornado/test/auth_test.pyc
+lib/python${MODPY_VERSION}/site-packages/tornado/test/csv_translations/
+lib/python${MODPY_VERSION}/site-packages/tornado/test/csv_translations/fr_FR.csv
lib/python${MODPY_VERSION}/site-packages/tornado/test/curl_httpclient_test.py
lib/python${MODPY_VERSION}/site-packages/tornado/test/curl_httpclient_test.pyc
lib/python${MODPY_VERSION}/site-packages/tornado/test/escape_test.py
lib/python${MODPY_VERSION}/site-packages/tornado/test/escape_test.pyc
lib/python${MODPY_VERSION}/site-packages/tornado/test/gen_test.py
lib/python${MODPY_VERSION}/site-packages/tornado/test/gen_test.pyc
+lib/python${MODPY_VERSION}/site-packages/tornado/test/gettext_translations/
+lib/python${MODPY_VERSION}/site-packages/tornado/test/gettext_translations/fr_FR/
+lib/python${MODPY_VERSION}/site-packages/tornado/test/gettext_translations/fr_FR/LC_MESSAGES/
+lib/python${MODPY_VERSION}/site-packages/tornado/test/gettext_translations/fr_FR/LC_MESSAGES/tornado_test.mo
+lib/python${MODPY_VERSION}/site-packages/tornado/test/gettext_translations/fr_FR/LC_MESSAGES/tornado_test.po
lib/python${MODPY_VERSION}/site-packages/tornado/test/httpclient_test.py
lib/python${MODPY_VERSION}/site-packages/tornado/test/httpclient_test.pyc
lib/python${MODPY_VERSION}/site-packages/tornado/test/httpserver_test.py
@@ -79,12 +86,12 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/tornado/test/ioloop_test.pyc
lib/python${MODPY_VERSION}/site-packages/tornado/test/iostream_test.py
lib/python${MODPY_VERSION}/site-packages/tornado/test/iostream_test.pyc
+lib/python${MODPY_VERSION}/site-packages/tornado/test/locale_test.py
+lib/python${MODPY_VERSION}/site-packages/tornado/test/locale_test.pyc
lib/python${MODPY_VERSION}/site-packages/tornado/test/options_test.py
lib/python${MODPY_VERSION}/site-packages/tornado/test/options_test.pyc
lib/python${MODPY_VERSION}/site-packages/tornado/test/process_test.py
lib/python${MODPY_VERSION}/site-packages/tornado/test/process_test.pyc
-lib/python${MODPY_VERSION}/site-packages/tornado/test/run_pyversion_tests.py
-lib/python${MODPY_VERSION}/site-packages/tornado/test/run_pyversion_tests.pyc
lib/python${MODPY_VERSION}/site-packages/tornado/test/runtests.py
lib/python${MODPY_VERSION}/site-packages/tornado/test/runtests.pyc
lib/python${MODPY_VERSION}/site-packages/tornado/test/simple_httpclient_test.py
