Re: Another fix for SDL's dynamic loading of X libs
On Wed, Mar 21, 2012 at 6:54 PM, Brad Smith wrote:
> *sigh* I had not noticed the second typo in the diff jsg@ sent out to
> correct the dynamic loading of the X libs and this resulted in SDL
> of course not using the dynamic loading with the XRender and Xrandr
> libraries and having downstream projects link to Xrender and Xrandr
> if using sdl-config.
Oops...
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/devel/sdl/Makefile,v
> retrieving revision 1.83
> diff -u -p -r1.83 Makefile
> --- Makefile 4 Mar 2012 01:33:22 - 1.83
> +++ Makefile 21 Mar 2012 17:32:06 -
> @@ -5,7 +5,7 @@ COMMENT= cross-platform multimedia libra
> VERSION= 1.2.15
> DISTNAME= SDL-${VERSION}
> PKGNAME= ${DISTNAME:L}
> -REVISION= 0
> +REVISION= 1
> CATEGORIES= devel
> MASTER_SITES= ${HOMEPAGE}release/
>
> Index: patches/patch-configure
> ===
> RCS file: /home/cvs/ports/devel/sdl/patches/patch-configure,v
> retrieving revision 1.23
> diff -u -p -r1.23 patch-configure
> --- patches/patch-configure 4 Mar 2012 01:33:22 - 1.23
> +++ patches/patch-configure 21 Mar 2012 17:42:21 -
> @@ -1,6 +1,6 @@
> $OpenBSD: patch-configure,v 1.23 2012/03/04 01:33:22 jsg Exp $
> --- configure.orig Thu Jan 19 01:30:12 2012
> -+++ configure Sat Mar 3 05:22:20 2012
> configure Wed Mar 21 13:42:07 2012
> @@ -21000,6 +21000,20 @@ _ACEOF
> fi
> }
> @@ -30,7 +30,7 @@ $OpenBSD: patch-configure,v 1.23 2012/03
> + x11_lib='libX11.so'
> + x11ext_lib='libXext.so'
> + xrender_lib='libXrender.so'
> -+ xrander_lib='libXrandr.so'
> ++ xrandr_lib='libXrandr.so'
> + ;;
> *)
> x11_lib=`find_lib "libX11.so.*" "$X_LIBS
> -L/usr/X11/$base_libdir -L/usr/X11R6/$base_libdir" | sed 's/.*\/\(.*\)/\1/;
> q'`
>
I'm going to commit this.
Thanks.
David
Re: Is the racket port going to be included?
On Thu, Mar 22, 2012 at 09:57:29AM +0200, Lars Engblom wrote: > Hello, > Yesterday I sent an email with the corrected version of my racket port > attached. I wonder if my mail got lost as I did not get any response. If > it is not of enough good quality, then response would be appreciated. I already replied yesterday. Be patient please, we do this on our spare time. -- Antoine
Re: Is the racket port going to be included?
Thank you! I do know you do it on your spare time. I just got worried when I got very fast response on the version still having something to be fixed, but nothing on the version that i corrected. I will wait patiently now :) On 03/22/12 10:16, Antoine Jacoutot wrote: On Thu, Mar 22, 2012 at 09:57:29AM +0200, Lars Engblom wrote: Hello, Yesterday I sent an email with the corrected version of my racket port attached. I wonder if my mail got lost as I did not get any response. If it is not of enough good quality, then response would be appreciated. I already replied yesterday. Be patient please, we do this on our spare time.
Re: Is the racket port going to be included?
On Thu, Mar 22, 2012 at 10:23:53AM +0200, Lars Engblom wrote: > Thank you! I do know you do it on your spare time. I just got > worried when I got very fast response on the version still having > something to be fixed, but nothing on the version that i corrected. > > I will wait patiently now :) We're obviously still looking hard for other nits to pick ;-P
Re: Is the racket port going to be included?
On Thu, Mar 22, 2012 at 09:57:29AM +0200, Lars Engblom wrote: > Hello, > Yesterday I sent an email with the corrected version of my racket port > attached. I wonder if my mail got lost as I did not get any response. If > it is not of enough good quality, then response would be appreciated. LIB_DEPENDS on gtk+2 but no corresponding WANTLIB. ONLY_FOR_ARCHS looks gratuitious, it needs to be explained. CONFIGURE_ENV is missing so iconv is not found. It compiles a bundled libffi instead of using the system one. All CONFIGURE_ARGS are missing. The patch was not created with make update-patches. ... and probably other things. This port is very far from being ready for import and I have no time to look into it any further. -- Antoine
Re: Is the racket port going to be included?
Thank you for your patience. We are all beginners at some point. If I can disturb with one thing more: Earlier Antoine wrote this: * I don't think CONFIGURE_ARGS is needed here, --prefix is the default. Now Antoine wrote: All CONFIGURE_ARGS are missing. I got confused and I hope somebody can explain so I can correct it. On 03/22/12 12:08, Antoine Jacoutot wrote: On Thu, Mar 22, 2012 at 09:57:29AM +0200, Lars Engblom wrote: Hello, Yesterday I sent an email with the corrected version of my racket port attached. I wonder if my mail got lost as I did not get any response. If it is not of enough good quality, then response would be appreciated. LIB_DEPENDS on gtk+2 but no corresponding WANTLIB. ONLY_FOR_ARCHS looks gratuitious, it needs to be explained. CONFIGURE_ENV is missing so iconv is not found. It compiles a bundled libffi instead of using the system one. All CONFIGURE_ARGS are missing. The patch was not created with make update-patches. ... and probably other things. This port is very far from being ready for import and I have no time to look into it any further.
Re: Is the racket port going to be included?
On Thu, Mar 22, 2012 at 12:29:03PM +0200, Lars Engblom wrote: > Thank you for your patience. We are all beginners at some point. If I can > disturb with one thing more: > > Earlier Antoine wrote this: > > * I don't think CONFIGURE_ARGS is needed here, --prefix is the default. > > Now Antoine wrote: > > All CONFIGURE_ARGS are missing. > > I got confused and I hope somebody can explain so I can correct it. There are _way_ more CONFIGURE_ARGS than --prefix > > > On 03/22/12 12:08, Antoine Jacoutot wrote: > >On Thu, Mar 22, 2012 at 09:57:29AM +0200, Lars Engblom wrote: > >>Hello, > >>Yesterday I sent an email with the corrected version of my racket port > >>attached. I wonder if my mail got lost as I did not get any response. If > >>it is not of enough good quality, then response would be appreciated. > >LIB_DEPENDS on gtk+2 but no corresponding WANTLIB. > >ONLY_FOR_ARCHS looks gratuitious, it needs to be explained. > >CONFIGURE_ENV is missing so iconv is not found. > >It compiles a bundled libffi instead of using the system one. > >All CONFIGURE_ARGS are missing. > >The patch was not created with make update-patches. > > > >... and probably other things. > > > >This port is very far from being ready for import and I have no time to > >look into it any further. > > -- Antoine
Re: new: lang/go
On Thursday 22 March 2012, Ted Unangst wrote: > On Thu, Mar 22, 2012, Joel Sing wrote: > > 1. Version numbering - in some ways once Go version 1 is release the > > versioning will be somewhat like Python and in the future you may want to > > install Go version 1 and Go version 2 on the same machine (different APIs > > for > > example). However, during the development phase there are weekly tagged > > releases that are simply -MM-DD versioned. For this reason I'm > > thinking that the version numbering should be 0.MMDD for now and 1.0 > > for the version 1 release. Continued development could then follow on the > > 0.MMDD releases. Or should we have two packages - a "go-weekly" > > package and a "go" package? > > My understanding is that the weekly releases will be a lot less > interesting/recommended after version 1. This is correct. > Just plain go should suffice until and if version 2 is released. I don't > think we need to provide a weekly port unless people are expected to use it > for something other than hacking on go itself. That is a fair call. Having also discussed this with a Go core team member, it would seem that I was pre-empting things when I probably do not need to. We can deal with this down the track if/when the need arises. > > 2. The installation locations is going to get somewhat messy - due to > > some of > > the internals of Go's design everything except a few user binaries (so > > documentaiton, libraries, source code, etc) needs to be under a single > > directory. For now I've used the "recommended" default of /usr/local/go, > > however this is not really acceptable for OpenBSD. Suggestions as to what > > would be the closest suitable location? I plan on talking with upstream > > re being able to split this so that we at least have tool/libexec type > > binaries and libraries separated out from the docs/source. > > some things, like ruby, pile everything under /usr/local/lib/ruby, but > I find that more annoying because the lib directory is already full of > real files. > > I've been waiting for them to make a stable release for a while now. -- "Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone." -- Ayn Rand
Re: new: lang/go
On Thursday 22 March 2012, Stuart Henderson wrote: > On 2012/03/22 02:09, Joel Sing wrote: > > 1. Version numbering - in some ways once Go version 1 is release the > > versioning will be somewhat like Python and in the future you may want to > > install Go version 1 and Go version 2 on the same machine (different APIs > > for example). However, during the development phase there are weekly > > tagged releases that are simply -MM-DD versioned. For this reason I'm > > thinking that the version numbering should be 0.MMDD for now and 1.0 > > for the version 1 release. > > How about 1.0pre2012mmdd? pkg_add knows how to handle these. Works for me. > > Continued development could then follow on the 0.MMDD > > releases. Or should we have two packages - a "go-weekly" package and a > > "go" package? > > I would probably go for ports/lang/go/1.0, ports/lang/go/2.0, etc. > For some things .../stable/ and .../devel/ would be more appropriate, > though I think that's probably not the case for this. I had a chat with a Go core team member and it would seem that I was probably planning too far ahead. For the time being I think we should stick with a ports/go/lang port for Go version 1 and we can revisit this in several years time when the next version appears. > > 2. The installation locations is going to get somewhat messy - due to > > some of the internals of Go's design everything except a few user > > binaries (so documentaiton, libraries, source code, etc) needs to be > > under a single directory. For now I've used the "recommended" default of > > /usr/local/go, however this is not really acceptable for OpenBSD. > > Suggestions as to what would be the closest suitable location? I plan on > > talking with upstream re being able to split this so that we at least > > have tool/libexec type binaries and libraries separated out from the > > docs/source. > > This wouldn't be the end of the world, we have a similar layout with Java. > You should plan to have the "main" version number in the directory name > to allow for multiple versions to be installed together. The preferred install location is /usr/local/go, so if there are no major objections then we should probably run with this. This is where the official Go distributions will be installed and it would be nice if it was consistent across platforms. > > 3. License - Go is released under a BSD-style license, however some parts > > (like the documentation) are under other licenses (Creative Commons > > Attribution 3.0 License). How do we handle this? > > Just list the various relevant licenses in the comment next to > the PERMIT_* markers, e.g. > > # software: BSD, documentation: CC-BY-3.0 Okay, thanks. -- "Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone." -- Ayn Rand
Re: new: lang/go - take 2
Attached is an updated version of the port for Go: - Version numbering is now 1.0preMMDD as suggested by sthen. - Fixed PLIST issue so that the port now works correctly on both amd64 and i386. - Fixed issue with USE_SYSTRACE - for the time being a Go binary needs to be able to use the sysarch() syscall in order to setup TLS. ok? On Thursday 22 March 2012, Joel Sing wrote: > The attached is an initial port for the Go programming language > (www.golang.org). A little background - Go is approaching a "Go version1" > release and at that point it will have a stable API. Unfortunately, for > several reasons Go version 1 will not be officially supported on OpenBSD, > however there are only a few issues that prevent this - the diffs included > in the port address known outstanding issues for the OpenBSD runtime, which > will let us provide a working port. > > Open questions: > > 1. Version numbering - in some ways once Go version 1 is release the > versioning will be somewhat like Python and in the future you may want to > install Go version 1 and Go version 2 on the same machine (different APIs > for example). However, during the development phase there are weekly tagged > releases that are simply -MM-DD versioned. For this reason I'm thinking > that the version numbering should be 0.MMDD for now and 1.0 for the > version 1 release. Continued development could then follow on the > 0.MMDD releases. Or should we have two packages - a "go-weekly" package > and a "go" package? > > 2. The installation locations is going to get somewhat messy - due to some > of the internals of Go's design everything except a few user binaries (so > documentaiton, libraries, source code, etc) needs to be under a single > directory. For now I've used the "recommended" default of /usr/local/go, > however this is not really acceptable for OpenBSD. Suggestions as to what > would be the closest suitable location? I plan on talking with upstream re > being able to split this so that we at least have tool/libexec type > binaries and libraries separated out from the docs/source. > > 3. License - Go is released under a BSD-style license, however some parts > (like the documentation) are under other licenses (Creative Commons > Attribution 3.0 License). How do we handle this? -- "Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone." -- Ayn Rand go-port.tar.gz Description: application/tgz
Re: [UPDATE] sox-14.4.0
Once more, *with* the forgotten twolame dependency
(thank you Alex).
Jan
Index: Makefile
===
RCS file: /cvs/ports/audio/sox/Makefile,v
retrieving revision 1.49
diff -u -p -u -p -r1.49 Makefile
--- Makefile15 Jun 2011 08:29:34 - 1.49
+++ Makefile20 Mar 2012 15:26:40 -
@@ -2,7 +2,7 @@
COMMENT= Sound eXchange, the Swiss Army knife of audio manipulation
-DISTNAME= sox-14.3.2
+DISTNAME= sox-14.4.0
SHARED_LIBS += sox 2.0 # .1.0
CATEGORIES=audio
@@ -20,6 +20,7 @@ MODULES= converters/libiconv
WANTLIB += c m ogg sndio z
WANTLIB += vorbis vorbisenc vorbisfile FLAC magic
WANTLIB += mad id3tag mp3lame wavpack png gsm
+WANTLIB += sndfile
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=sox/}
@@ -29,6 +30,7 @@ LIB_DEPENDS= audio/libvorbis \
devel/libmagic \
audio/libmad \
audio/libid3tag \
+ audio/twolame \
+ audio/libsndfile \
audio/lame \
audio/wavpack \
graphics/png \
@@ -38,6 +40,7 @@ USE_GROFF=Yes
USE_LIBTOOL= Yes
CONFIGURE_STYLE=gnu
CONFIGURE_ARGS=${CONFIGURE_SHARED} \
+ --datarootdir=${LOCALBASE} \
--disable-silent-libtool
# Don't use modules
@@ -46,11 +49,15 @@ CONFIGURE_ARGS+=--without-libltdl
# Sound drivers
CONFIGURE_ARGS+=--without-ao \
--without-oss \
+ --without-alsa \
+ --without-coreaudio \
+ --without-pulseaudio\
+ --without-waveaudio \
--with-sndio \
--without-sunaudio
# Additional file formats
-CONFIGURE_ARGS+=--without-sndfile \
+CONFIGURE_ARGS+=--with-sndfile \
--with-oggvorbis \
--with-flac \
--without-ffmpeg \
@@ -58,10 +65,12 @@ CONFIGURE_ARGS+=--without-sndfile \
--with-mad \
--with-id3tag \
--with-lame \
+ --with-twolame \
--without-amrwb \
--without-amrnb \
--with-wavpack \
--with-png \
+ --with-gsm \
--without-ladspa
CONFIGURE_ENV= \
Index: distinfo
===
RCS file: /cvs/ports/audio/sox/distinfo,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 distinfo
--- distinfo15 Jun 2011 08:29:34 - 1.11
+++ distinfo20 Mar 2012 15:26:40 -
@@ -1,5 +1,5 @@
-MD5 (sox-14.3.2.tar.gz) = 6dNc87D4h4WW4LfEn56DAg==
-RMD160 (sox-14.3.2.tar.gz) = W46GvWSt4tlTSZMxdHTDO0EJAYM=
-SHA1 (sox-14.3.2.tar.gz) = rUYhFP9HsJQHjxgUi8ninjG0K5I=
-SHA256 (sox-14.3.2.tar.gz) = BmjMCHw0b3xAhK4pTGdqEd3vtGKXS8P2e+MNeJyFDo8=
-SIZE (sox-14.3.2.tar.gz) = 1110175
+MD5 (sox-14.4.0.tar.gz) = sMFc/3pLoOwX/cdOah+c8Q==
+RMD160 (sox-14.4.0.tar.gz) = rxtsAtKcmI+bDf7Jyp67MJSbBmM=
+SHA1 (sox-14.4.0.tar.gz) = 2AnKs4LHqdAVSRxpBRqdHBoaRPE=
+SHA256 (sox-14.4.0.tar.gz) = PuNLFN0mfeN46KEXqugexMrjMHcjQualW79lIKCoiqM=
+SIZE (sox-14.4.0.tar.gz) = 1105756
Index: pkg/PLIST
===
RCS file: /cvs/ports/audio/sox/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 PLIST
--- pkg/PLIST 8 Jan 2009 19:48:21 - 1.6
+++ pkg/PLIST 20 Mar 2012 15:26:40 -
@@ -8,7 +8,6 @@ bin/rec
@bin bin/sox
bin/soxi
include/sox.h
-include/soxstdint.h
lib/libsox.a
lib/libsox.la
lib/pkgconfig/
Re: [UPDATE] sox-14.4.0
Index: Makefile
===
RCS file: /cvs/ports/audio/sox/Makefile,v
retrieving revision 1.49
diff -u -p -r1.49 Makefile
--- Makefile15 Jun 2011 08:29:34 - 1.49
+++ Makefile22 Mar 2012 21:15:25 -
@@ -2,7 +2,7 @@
COMMENT= Sound eXchange, the Swiss Army knife of audio manipulation
-DISTNAME= sox-14.3.2
+DISTNAME= sox-14.4.0
SHARED_LIBS += sox 2.0 # .1.0
CATEGORIES=audio
@@ -20,6 +20,7 @@ MODULES= converters/libiconv
WANTLIB += c m ogg sndio z
WANTLIB += vorbis vorbisenc vorbisfile FLAC magic
WANTLIB += mad id3tag mp3lame wavpack png gsm
+WANTLIB += sndfile twolame
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=sox/}
@@ -29,6 +30,8 @@ LIB_DEPENDS= audio/libvorbis \
devel/libmagic \
audio/libmad \
audio/libid3tag \
+ audio/libsndfile \
+ audio/twolame \
audio/lame \
audio/wavpack \
graphics/png \
@@ -38,6 +41,7 @@ USE_GROFF=Yes
USE_LIBTOOL= Yes
CONFIGURE_STYLE=gnu
CONFIGURE_ARGS=${CONFIGURE_SHARED} \
+ --datarootdir=${LOCALBASE} \
--disable-silent-libtool
# Don't use modules
@@ -46,11 +50,15 @@ CONFIGURE_ARGS+=--without-libltdl
# Sound drivers
CONFIGURE_ARGS+=--without-ao \
--without-oss \
+ --without-alsa \
+ --without-coreaudio \
+ --without-pulseaudio\
+ --without-waveaudio \
--with-sndio \
--without-sunaudio
# Additional file formats
-CONFIGURE_ARGS+=--without-sndfile \
+CONFIGURE_ARGS+=--with-sndfile \
--with-oggvorbis \
--with-flac \
--without-ffmpeg \
@@ -58,10 +66,12 @@ CONFIGURE_ARGS+=--without-sndfile \
--with-mad \
--with-id3tag \
--with-lame \
+ --with-twolame \
--without-amrwb \
--without-amrnb \
--with-wavpack \
--with-png \
+ --with-gsm \
--without-ladspa
CONFIGURE_ENV= \
Index: distinfo
===
RCS file: /cvs/ports/audio/sox/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- distinfo15 Jun 2011 08:29:34 - 1.11
+++ distinfo22 Mar 2012 21:15:25 -
@@ -1,5 +1,5 @@
-MD5 (sox-14.3.2.tar.gz) = 6dNc87D4h4WW4LfEn56DAg==
-RMD160 (sox-14.3.2.tar.gz) = W46GvWSt4tlTSZMxdHTDO0EJAYM=
-SHA1 (sox-14.3.2.tar.gz) = rUYhFP9HsJQHjxgUi8ninjG0K5I=
-SHA256 (sox-14.3.2.tar.gz) = BmjMCHw0b3xAhK4pTGdqEd3vtGKXS8P2e+MNeJyFDo8=
-SIZE (sox-14.3.2.tar.gz) = 1110175
+MD5 (sox-14.4.0.tar.gz) = sMFc/3pLoOwX/cdOah+c8Q==
+RMD160 (sox-14.4.0.tar.gz) = rxtsAtKcmI+bDf7Jyp67MJSbBmM=
+SHA1 (sox-14.4.0.tar.gz) = 2AnKs4LHqdAVSRxpBRqdHBoaRPE=
+SHA256 (sox-14.4.0.tar.gz) = PuNLFN0mfeN46KEXqugexMrjMHcjQualW79lIKCoiqM=
+SIZE (sox-14.4.0.tar.gz) = 1105756
Index: pkg/PLIST
===
RCS file: /cvs/ports/audio/sox/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST 8 Jan 2009 19:48:21 - 1.6
+++ pkg/PLIST 22 Mar 2012 21:15:25 -
@@ -8,7 +8,6 @@ bin/rec
@bin bin/sox
bin/soxi
include/sox.h
-include/soxstdint.h
lib/libsox.a
lib/libsox.la
lib/pkgconfig/
faac disabled in avidemux?
Hello, I use avidemux on an OpenBSD 5.0 machine to transcode video for playback on an Android phone; it works great. When I upgraded another machine to a -current snapshot, I found that faac was disabled for avidemux in August 2011. However, I couldn't find an explanation for why this was done. It looks like the discussion began off-list before ports@ was CC'ed in: http://marc.info/?l=openbsd-ports&m=131474115707784&w=2 Could anyone let me know why this was done, and if there's any chance of faac being re-enabled? Seems the Android media player requires AAC audio, unfortunately... Thanks in advance, -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: faac disabled in avidemux?
On 22/03/12 5:48 PM, Joe Gidi wrote: Hello, I use avidemux on an OpenBSD 5.0 machine to transcode video for playback on an Android phone; it works great. When I upgraded another machine to a -current snapshot, I found that faac was disabled for avidemux in August 2011. However, I couldn't find an explanation for why this was done. It looks like the discussion began off-list before ports@ was CC'ed in: http://marc.info/?l=openbsd-ports&m=131474115707784&w=2 Could anyone let me know why this was done, and if there's any chance of faac being re-enabled? Seems the Android media player requires AAC audio, unfortunately... Thanks in advance, Because of licensing issues faac cannot be distributed with packages which use the GPL license and everything in the ports tree it was being used with was GPL. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: new: lang/go - take 2
On Fri, Mar 23, 2012 at 01:08:48AM +1100, Joel Sing wrote: > Attached is an updated version of the port for Go: > > - Version numbering is now 1.0preMMDD as suggested by sthen. > > - Fixed PLIST issue so that the port now works correctly on both amd64 and > i386. > > - Fixed issue with USE_SYSTRACE - for the time being a Go binary needs to be > able to use the sysarch() syscall in order to setup TLS. > > ok? "make package" works perfect with USE_SYSTRACE. Just a warning in the "fake" step: "strip: /usr/ports/pobj/go-1.0pre20120313/fake-i386/usr/local/go/pkg/tool/openbsd_386/pprof: File format not recognized". I don't know if this is the correct behavior or not, but "make regress" uses the "go" command installed on /usr/local, not the "go" binary in the build directory. "make regress" with and without "go" installed, both fail. I've attached the logs of "make regress". -- Juan Francisco Cantero Hurtado http://juanfra.info logs-goport.tar.gz Description: application/tar-gz
Promoção Sushi Express Lojas Marechal Rondon e Pedro Celestino Rodízio só R$22,90 por pessoa.
[IMAGE] Não desejo mais receber estes e-mails.
