Permit to build Python 2 and Python 3 ports - diff modified
Hi,
I reworked on the diff to update python.port.mk to permit to have both Python
2.x and 3.x working on OpenBSD.
How it works:
1) Python2 port
- all ports existing don't need to change, they still build with Python 2
2) Python2 and Python3 port
- if you know that a port (and its dependencies...) work with Python 3 &&
Python 2, you just need to add:
FLAVORS ?= python3
Be carefull to add ${MODPY_FLAVOR} to your dependencies (see examples at the
end).
Next, to build your port you will need to precise the correct flavor: python3.
In this case, you must be very carreful with the conflict of the PLIST. If your
port is a library, there is often no problems, but you will have problem with
binaries/doc/examples/wub/...
So you will have to "play" with post-install, in moving files which are
conflicting by suffixing it (see examples at the end).
FYI the port built with python3 will replace the prefix py- by py3-.
3) Python3 port
- if you know that a port (and its dependencies) work with Python 3 only, you
just need to add:
MODPY_VERSION = ${MODPY_DEFAULT_VERSION3} and it will automatically build this
port with Python 3.
FYI the port built with python3 follow the same logic that in python2, so if
the port PKGNAME begins with py- it will automatically be replaced by py3-.
More details about modifications needed in the ports tree:
- remove the devel/py3-distribute, not used and useless to have py3 in the dir
name (maybe a quirks thing to permit distribute -> py3-distribute? If not used
actually, are modifications in quirks needed?)
- some people don't want to replace py-setuptools by py-distribute, so keep
py-setuptools (Python 2 only).
- add the port devel/py-distribute, only used with Python3 ports (MODPY_VERSION
= ${MODPY_DEFAULT_VERSION3}, will have the py3-distribute FULLPKGNAME.
- remove the MODPY_DISTRIBUTE, useless. Keep the MODPY_SETUPTOOLS only, easier
to maintain, even if we used distribute or setuptools after, it's not the
problem of the porters.
So, if your ports use:
1) Python 2 only
- nothing to change
2) Python 2 and Python 3:
- add FLAVORS ?= python3
- add to your *_DEPENDS : ${MODPY_FLAVOR}, without comma (example:
BUILD_DEPENDS: devel/py-distribute${MODPY_FLAVOR}).
- make sure your PLIST will not be in conflict by adding special tasks in
post-install. Example:
post-install:
.if defined(MODPY_DOC_PREFIX)
mv ${WRKINST}/${LOCALBASE}/share/doc/py-foo/
${WRKINST}/${LOCALBASE}/share/doc/py${MODPY_DOC_PREFIX}-foo/
.endif
If you use the default FLAVOR (Python 2), MODPY_BIN_SUFFIX is "",
MODPY_DOC_PREFIX is "" so there is no modification for people who use the
default.
If you use the FLAVOR Python 3, MODPY_BIN_SUFFIX = -3, MODPY_DOC_PREFIX = 3.
Idea is to add a suffix to binary to be easier to find the command with
auto-completion.
Add ${MODPY_BIN_SUFFIX} and ${MODPY_DOC_PREFIX} to your PLIST.
3) Python 3:
- add MODPY_VERSION = ${MODPY_DEFAULT_VERSION3}
Please test and give me your feedback.
Cheers,
--
Remi
Index: python.port.mk
===
RCS file: /cvs/ports/lang/python/python.port.mk,v
retrieving revision 1.48
diff -u -p -r1.48 python.port.mk
--- python.port.mk 29 Nov 2011 17:29:37 - 1.48
+++ python.port.mk 10 Dec 2011 06:39:23 -
@@ -7,25 +7,59 @@ SHARED_ONLY= Yes
CATEGORIES+= lang/python
-MODPY_VERSION?=2.7
+# define the default versions
+MODPY_DEFAULT_VERSION2 = 2.7
+MODPY_DEFAULT_VERSION3 = 3.2
-.if ${MODPY_VERSION} == "2.4" || ${MODPY_VERSION} == "2.5" || ${MODPY_VERSION}
== "2.7" || ${MODPY_VERSION} == "3.2"
+.if !defined(MODPY_VERSION)
-. if ${MODPY_VERSION} < 2.6
-MODPY_JSON = devel/py-simplejson
-. else
-MODPY_JSON =
-. endif
+FLAVOR?=
-. if ${MODPY_VERSION} < 3.2
-MODPY_WANTLIB =python${MODPY_VERSION}
-MODPY_INCDIR = ${LOCALBASE}/include/python${MODPY_VERSION}
+. if ${FLAVOR:L:Mpython3}
+# define default version 3
+MODPY_VERSION?=${MODPY_DEFAULT_VERSION3}
. else
-MODPY_WANTLIB = python${MODPY_VERSION}m
-MODPY_INCDIR = ${LOCALBASE}/include/python${MODPY_VERSION}m
+# without flavor, assume we use the default version 2
+MODPY_VERSION?=${MODPY_DEFAULT_VERSION2}
. endif
+
+# verify if MODPY_VERSION forced is correct
.else
+. if ${MODPY_VERSION} != "2.4" && \
+ ${MODPY_VERSION} != "2.5" && \
+ ${MODPY_VERSION} != "2.7" && \
+ ${MODPY_VERSION} != "3.2"
ERRORS += "Fatal: unknown or unsupported MODPY_VERSION: ${MODPY_VERSION}"
+. endif
+.endif
+
+_MODPY_MAJOR_VERSION = ${MODPY_VERSION:C/\.[1-9]*//g}
+
+.if ${_MODPY_MAJOR_VERSION} == 2
+MODPY_LIB_SUFFIX =
+MODPY_FLAVOR =
+MODPY_BIN_SUFFIX =
+MODPY_DOC_PREFIX =
+
+.elif ${_MODPY_MAJOR_VERSION} == 3
+MODPY_LIB_SUFFIX = m
+# replace py- prefix by py3-
+FULLPKGNAME = ${PKGNAME:S/^py-/py3-/}
+MODPY_FLAVOR = ,python3
+# use MODPY_SUFFIX for binaries to avoid conflict
+MODPY_BIN_SUFFIX = -3
+# use MODPY_SUFFIX for dir
more aggressive stance towards gnu-configure auto-detection
We've just put in place a better set of CONFIG_SITE fragments to prevent random ports from picking up gnu-tools. This is probably grow in the near future. For now, if your port *really* requires some gnu tools, be sure to have the right BUILD_DEPENDS, as the cache will say "nope, they don't live there" otherwise. e.g., unless BUILD_DEPENDS includes sysutils/ggrep, configure will assume (correctly) our *grep work just fine, thank you.
patches and stuff, confusion about external links
Whenever you send patches or new ports to the list, remember there's
some asynchronous behavior involved.
There's been some recent confusion as to which version of a patch someone
was referring to, because it was an external link, and the external link
got changed to something else.
That's a common rookie mistake: as soon as you publish/send a patch link
to someone, consider that link "eternal". If you change the patch later,
it's totally trivial to give it a version number, and *make sure to provide
a different link*.
Otherwise, it's really easy to lose track and attribution. And such mix-ups
tend to lead to the wrong code being committed ('but he said it was okay
nah, I never saw that version of the patch'), which leads to further
time lost to figure out the fuck-up...
Also, your work may be more easily/quickly reviewed if it's included
*directly* in your email.
For instance, very often, I don't have any modern browser available while
I'm testing dpb.
even if I have a browser, clicking on a link involves a second step.
heck, apart from ports, we routinely remove attachments to all the lists.
People with commit access are chronically overworked. every small thing you
can do to make things easier is generally appreciated, thank you.
Re: UPDATE: www/node 0.6.3 to 0.6.5
Hi, Aaron Bieber wrote on Fri, Dec 09, 2011 at 08:01:38AM -0700: > On Fri, Dec 09, 2011 at 01:54:12PM +0100, Jasper Lievisse Adriaanse wrote: >> On Wed, Dec 07, 2011 at 09:00:26AM -0700, Aaron wrote: >>> This patch updates nodejs from 0.6.3 to 0.6.5. Tested on i386/amd64 >> Shouldn't the manpages be installed to a more generic path? > I assume you are talking about the pages in > /usr/local/lib/node_modules/npm/man/man3/ . > > They are specific to npm, which was just recently added to node, and > are generally accessed from the npm command ( "npm help json" for > example ). > > Moving them will likely cause problems as npm expects them to be in its > "node_module" directory. Well, that could probably be fixed, no? But the names of these pages are too generic. So they either have to stay well well out of the way, in some non-generic path, as you proposed. Of course, then they are of rather limited usefulness, because man(1) and apropos(1) will not find them. Given the bad naming scheme, telling people to add that path to man.conf(5) would be a bad idea. Or alternatively, to make it possible to put them into /usr/local/man/, they have to be renamed to something sensible, like npm-init(1), npm-link(1), and so on, and npm has to be changed to cope. But probably that's beyond the scope of a port and should be fixed upstream instead. Yours, Ingo
dpb question regarding pseudo-flavors
Hi I lately started using dpb for building a subset of ports automagically. I now run into problems with building some openldap dependent ports. The point is I don't have ACCEPT_JRL_LICENSE=Yes in my /etc/mk.conf, because I actually do not need java. When I build by hand I just build "databases/db/v4" with (pseudo-) FLAVOR="no_java" and then build openldap and everything is fine. I added "databases/db/v4,no_java" to the pkgpath's but dpb does not seem to take no_java pseudo-flavor into account when trying to resolv dependencies and still tries to build devel/jdk/1.6. Is this expected behaviour? I "resolved" the problem by adjusting the db/v4 port so it does not use/build/wants java anymore, but that does not seem to be a very clean solution :-) Regards André
Re: dpb question regarding pseudo-flavors
On Sat, Dec 10, 2011 at 01:46:58PM +0100, Andre Keller wrote: > Hi > > I lately started using dpb for building a subset of ports > automagically. I now run into problems with building some openldap > dependent ports. > > The point is I don't have ACCEPT_JRL_LICENSE=Yes in my /etc/mk.conf, > because I actually do not need java. When I build by hand I just > build "databases/db/v4" with (pseudo-) FLAVOR="no_java" and then > build openldap and everything is fine. > > I added "databases/db/v4,no_java" to the pkgpath's but dpb does not > seem to take no_java pseudo-flavor into account when trying to > resolv dependencies and still tries to build devel/jdk/1.6. > > Is this expected behaviour? > > I "resolved" the problem by adjusting the db/v4 port so it does not > use/build/wants java anymore, but that does not seem to be a very > clean solution :-) Does look like "BUILD_ONCE=Yes" behavior, which does kick in when dpb is invoked with -a. Since you don't describe the command line used for firing up dpb, I'll have to assume that's what's going on. Notice the "bootstrap" pseudo-flavor in databases/db/v4 ? no go read through bsd.port.arch.mk(5) and dpb(1)... ;)
Re: dpb question regarding pseudo-flavors
Am 10.12.2011 15:03, schrieb Marc Espie: Does look like "BUILD_ONCE=Yes" behavior, which does kick in when dpb is invoked with -a. Since you don't describe the command line used for firing up dpb, I'll have to assume that's what's going on. Yes my bad: command line is "./dpb -q -c" followed by about 50 pkgpaths that I like to build. I did not specify -a, as I'm just building a subset of packages Notice the "bootstrap" pseudo-flavor in databases/db/v4 ? Yes I noticed but did not give it any further thought no go read through bsd.port.arch.mk(5) and dpb(1)... ;) I read dpb back and forth, but not bsd.port.arch.mk(5) No reading bsd.port.i386.mk and see whats op with the bootstrap pseudo-flavor... Thank you for taking the time and answering! Regards André
xfce4-weather-plugin fix
The weather.com XOAP API key used by the xfce weather plugin has expired. The plugin keeps showing "No data". The real problem is that weather.com is cancelling its free service. The plugin authors now want to rewrite the plugin to use a different provider. A different API key obtained from another open source project can keep the plugin working for now. See for details: https://bugzilla.xfce.org/show_bug.cgi?id=8105 Should we apply this patch? I don't know if this breaks weather.com terms of use. I don't care for my own personal use. But I don't know if committing this to the CVS repository is ok. The alternative is to mark the package BROKEN until upstream releases a new release which uses a free provider. We can always point people to this patch in the list archives if they need it. Thoughts? Index: Makefile === RCS file: /cvs/ports/x11/xfce4/xfce4-weather/Makefile,v retrieving revision 1.41 diff -u -p -r1.41 Makefile --- Makefile3 Dec 2011 22:39:12 - 1.41 +++ Makefile10 Dec 2011 13:54:47 - @@ -4,7 +4,7 @@ COMMENT=Xfce4 temperature/weather condi XFCE_VERSION= 0.7.4 XFCE_PLUGIN= weather -REVISION= 2 +REVISION= 3 # GPLv2 PERMIT_DISTFILES_CDROM=Yes Index: patches/patch-panel-plugin_weather_h === RCS file: patches/patch-panel-plugin_weather_h diff -N patches/patch-panel-plugin_weather_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-panel-plugin_weather_h10 Dec 2011 13:11:49 - @@ -0,0 +1,17 @@ +$OpenBSD$ +Temporary hack to get data updates working (expired XOAP license key). +See https://bugzilla.xfce.org/show_bug.cgi?id=8105 +and https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xfce4-weather-plugin&id=ea5bc563d6deeeb531a8509da684d36b3ad9a58e +--- panel-plugin/weather.h.origSat Dec 10 14:10:28 2011 panel-plugin/weather.h Sat Dec 10 14:10:47 2011 +@@ -21,8 +21,8 @@ + #include + #include + #define PLUGIN_WEBSITE "http://goodies.xfce.org/projects/panel-plugins/xfce4-weather-plugin"; +-#define PARTNER_ID "1121946239" +-#define LICENSE_KEY "3c4cd39ee5dec84f" ++#define PARTNER_ID "1003666583" ++#define LICENSE_KEY "4128909340a9b2fc" + + G_BEGIN_DECLS +
Re: dpb question regarding pseudo-flavors
No reading bsd.port.i386.mk ah thats actually bsd.port.arch.mk :-)
Re: dpb question regarding pseudo-flavors
On Sat, Dec 10, 2011 at 03:10:41PM +0100, Andre Keller wrote: > Am 10.12.2011 15:03, schrieb Marc Espie: > >Does look like "BUILD_ONCE=Yes" behavior, which does kick in when > >dpb is invoked with -a. > > > >Since you don't describe the command line used for firing up dpb, I'll > >have to assume that's what's going on. > > Yes my bad: > > command line is "./dpb -q -c" followed by about 50 pkgpaths that I > like to build. > > I did not specify -a, as I'm just building a subset of packages > So I expect your "full" db/v4 comes from elsewhere. Have a closer look at vars.log, in particular the (parent) stuff in parentheses, to figure out what pkgpath leads to full db/v4.
Re: UPDATE: QEMU 1.0
On Fri, Dec 09, 2011 at 09:08:17AM -0500, Brad wrote:
> On Fri, Dec 09, 2011 at 02:20:29AM -0500, Brad wrote:
> > On Fri, Dec 09, 2011 at 01:13:02AM +, Stuart Henderson wrote:
> > > On 2011-12-07, Brad wrote:
> > > > -@bin bin/qemu
> > >
> > > I'd prefer to keep this working via a courtesy symlink pointing at
> > > either qemu-system-i386 or qemu-system-x86_64. Otherwise there needs to
> > > be some clear information. Without one or other of these, people are
> > > going to wonder what's going on, tab-complete, see qemu-i386, try and
> > > run it, receive a segfault, then think, as well as forcing them to
> > > make changes to their scripts, that the update has totally broken qemu.
> >
> > I'm not adding a symlink as there will be another binary of the same
> > name there in the future. Users should be conditioned to use
> > qemu-system-i386
> > properly.
> >
> > Updated diff adding MESSAGE to mention the change. Maybe also mention
> > the change in the upgrade/current FAQ?
>
> and disable the BSD userland emulation support for now.
On amd64 this warning appears during the build:
/usr/ports/pobj/qemu-1.0/qemu-1.0/monitor.c: In function 'expire_password':
/usr/ports/pobj/qemu-1.0/qemu-1.0/monitor.c:944: warning: overflow in
implicit constant conversion
Qemu assumes time_t is long if TIME_MAX isn't defined. But time_t is int
on OpenBSD. Setting TIME_MAX to INT_MAX via CFLAGS fixes the warning.
Suggested diff with that change below.
I'm happy with this upgrade. My VMs are still working.
Index: Makefile
===
RCS file: /cvs/ports/emulators/qemu/Makefile,v
retrieving revision 1.80
diff -u -p -r1.80 Makefile
--- Makefile2 Dec 2011 14:36:14 - 1.80
+++ Makefile10 Dec 2011 14:40:17 -
@@ -1,15 +1,13 @@
# $OpenBSD: Makefile,v 1.80 2011/12/02 14:36:14 espie Exp $
-# no success building on other archs yet
-ONLY_FOR_ARCHS = amd64 arm i386 mips64 mips64el powerpc sparc sparc64
+ONLY_FOR_ARCHS=amd64 i386 mips64 mips64el powerpc sparc sparc64
COMMENT = multi system emulator
-DISTNAME = qemu-0.15.1
-REVISION= 1
+DISTNAME= qemu-1.0
CATEGORIES = emulators
MASTER_SITES = http://wiki.qemu.org/download/ \
- ${MASTER_SITE_SAVANNAH:=qemu/}
+ http://comstyle.com/source/
HOMEPAGE = http://www.qemu.org/
@@ -21,18 +19,30 @@ PERMIT_PACKAGE_FTP =Yes
PERMIT_DISTFILES_CDROM = Yes
PERMIT_DISTFILES_FTP = Yes
-WANTLIB = c curl jpeg m ncurses ossaudio png pthread util z
+WANTLIB= GL SDL X11 c curl glib-2.0 gthread-2.0 jpeg m ncurses \
+ png pthread util z
+MODULES= devel/gettext \
+ lang/python
BUILD_DEPENDS =textproc/texi2html
-LIB_DEPENDS = graphics/jpeg \
+LIB_DEPENDS= devel/glib2 \
+ devel/sdl \
+ graphics/jpeg \
graphics/png \
net/curl
+MODPY_RUNDEP= No
+
MAKE_ENV = V=1
FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples
-EXTRA_CFLAGS= -I${LOCALBASE}/include
-EXTRA_LDFLAGS= -L${LOCALBASE}/lib
+EXTRA_CFLAGS= -I${LOCALBASE}/include -I${X11BASE}/include
+EXTRA_LDFLAGS= -L${LOCALBASE}/lib -L${X11BASE}/lib
+
+# until the system headers are fixed properly.
+EXTRA_CFLAGS+= -Wno-redundant-decls
+
+EXTRA_CFLAGS+= -DTIME_MAX=INT_MAX
VMEM_WARNING = Yes
@@ -41,12 +51,15 @@ CONFIGURE_STYLE = simple
CONFIGURE_ARGS = --prefix=${PREFIX} \
--sysconfdir=${SYSCONFDIR} \
--mandir=${PREFIX}/man \
+ --python=${MODPY_BIN} \
--smbd=${LOCALBASE}/libexec/smbd \
--cc="${CC}" \
--host-cc="${CC}" \
--extra-cflags="${EXTRA_CFLAGS}" \
--extra-ldflags="${EXTRA_LDFLAGS}" \
- --disable-guest-agent \
+ --audio-drv-list=sdl \
+ --disable-bsd-user \
+ --disable-libiscsi \
--disable-smartcard-nss \
--disable-spice \
--disable-uuid \
@@ -58,39 +71,14 @@ CONFIGURE_ARGS =--prefix=${PREFIX} \
CONFIGURE_ARGS += --sparc_cpu=v7
.endif
-.if ${MACHINE_ARCH:Mamd64} || ${MACHINE_ARCH:Mi386} || ${MACHINE_ARCH:Msparc64}
-PKG_ARGS +=-Dbsduser=1
-.else
-CONFIGURE_ARGS += --disable-bsd-user
-PKG_ARGS +=-Dbsduser=0
-.endif
-
-FLAVORS = debug no_x11
+FLAVORS= debug
FLAVOR ?=
-.if ${FLAVOR:Mno_x11}
-CONFIGURE_ARGS += --disable-sdl --disable-opengl
-.else
-WANTLIB += GL SDL X11
-
-
Re: dpb question regarding pseudo-flavors
Hi Marc
Am 10.12.2011 15:34, schrieb Marc Espie:
So I expect your "full" db/v4 comes from elsewhere.
Have a closer look at vars.log, in particular the (parent) stuff in
parentheses, to figure out what pkgpath leads to full db/v4.
Well now I feel like a complete idiot. Not once I have looked into that
file before :-(
It turns out db/v4 is pulled in by the squidguard port, the openldap
port and the postfix port when building with db4 flaour. (I'm not sure
why though. Most of the other ports seem to request db4 with the no_java
flavor)
Thank you for putting me in the right direction and sorry for wasting
your time.
regards andré
PS: These patches "fix" the build for me:
--- ports/www/squidguard/Makefile.orig Sat Dec 10 16:27:23 2011
+++ ports/www/squidguard/Makefile Sat Dec 10 16:29:31 2011
@@ -23,7 +23,7 @@
CONFIG_DIR = ${SYSCONFDIR}/squidguard
SUBST_VARS = SG_DIR CONFIG_DIR
-LIB_DEPENDS = databases/db/v4
+LIB_DEPENDS = databases/db/v4,bootstrap,no_java,no_tcl
RUN_DEPENDS = www/squid
BUILD_DEPENDS =${RUN_DEPENDS}
--- ports/mail/postfix/Makefile.inc.origSat Dec 10 16:25:17 2011
+++ ports/mail/postfix/Makefile.inc Sat Dec 10 16:31:57 2011
@@ -74,7 +74,7 @@
.endif
.if ${FLAVOR:L:Mdb4}
-LIB_DEPENDS+= databases/db/v4>=4,<5
+LIB_DEPENDS+= databases/db/v4,bootstrap,no_java,no_tcl
WANTLIB+= lib/db4/db>=4
MAKE_CCARGS+= -I${LOCALBASE}/include/db4
MAKE_AUXLIBS+= -L${LOCALBASE}/lib/db4 -ldb
--- ports/databases/openldap/Makefile.orig Sat Dec 10 16:25:17 2011
+++ ports/databases/openldap/Makefile Sat Dec 10 16:33:23 2011
@@ -79,7 +79,7 @@
LIB_DEPENDS-server = ${LIB_DEPENDS-main} \
textproc/icu4c \
- databases/db/v4
+ databases/db/v4,bootstrap,no_java,no_tcl
CONFIGURE_ENV += CPPFLAGS="-I${LOCALBASE}/include/sasl
-I${LOCALBASE}/include/db4 -
I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib/db4 -L${LOCALBASE}/lib"
Re: [NEW] opencore-amr
Replying to an old thread when I finally got around to it, I am trying again to get this AMR port commited: http://stare.cz/~hans/.tmp/opencore-amr-0.1.2.tar.gz Meanwhile, I have found that David Coppa tried to get this in before (and later OK'd my attempt): http://marc.info/?t=12761017433&r=1&w=2 http://marc.info/?l=openbsd-ports&m=130952776413954&w=2 (David, why is it you were building --with-pic?) However, there were objections, which I try to address below. On Jul 01 17:01:41, Stuart Henderson wrote: > On 2011-07-01, Giovanni Bechis wrote: > > On 07/01/11 15:39, David Coppa wrote: > >> To anyone who wants to import it, you have my ok. > > Enable regression test as well, ok for me. > The following ports are very likely to pick this up: > > audio/sox I maintain audio/sox; in fact, the reason I am trying to import AMR is to have AMR support in SoX. SoX's configure has --with-amrnb and --with-amrwb, but also picks up http://opencore-amr.sourceforge.net/ or http://ftp.penguin.cz/pub/users/utx/amr/ silently, in that order of preference. That makes a hidden dependency if either is present. That's why we have --without-amrnb and --without-amrwb in the current SoX Makefile. (I have a sox diff prepared that I want to put in once the opencore-amr port gets in.) > graphics/ffmpeg ffmpeg's configure recognizes --enable-libopencore-amrnb and --enable-libopencore-amrwb which both default to 'no'; the port does not override this and ffmpeg ignores the installed openore-amr (and uses its own internal AMR implementation in libavcodec/*amr*, which in turn is itself a copy of the opencore implementation). ldd says the resulting ffmpeg does not depend on the opencore libraries. Anyway, we've been here: http://marc.info/?l=openbsd-ports&m=130956193621550&w=2 > multimedia/avidemux http://marc.info/?l=openbsd-ports&m=130969989416158&w=2 avidemux configure ignores the installed opencore-amr, and ldd says the resulting avidemux does not depend on it. However, it silently picks up another AMR implementation library, namely that provided at http://ftp.penguin.cz/pub/users/utx/amr/ So I think avidemux already has the problem we are trying to discover, but with respect to amrnb. Indeed, ldd says the resulting avidemux depends on libamrnb.so (those are NOT the opencore-amr liraries, but the http://ftp.penguin.cz/pub/users/utx/amr/ libs). > multimedia/gstreamer-0.10 (plugins-bad and plugins-ugly) The current gstreamer/core build breaks for me, for reasons unrelated to opencore-amr: checking for flex... /usr/local/bin/gflex /usr/ports/pobj/gstreamer-0.10.35/gstreamer-0.10.35/configure[21243]: /usr/local/bin/gflex: not found checking flex version >= 2.5.31... Use of uninitialized value $flex_version_major in numeric gt (>) at - line 3. It seems that gstreamer/core BUILD_DEPENDS on flex but doesn't say so. Similarly, the build apparently depends on gobject-introspection. Once gstreamer/core is installed and I try to build streamer/plugins-bad, the build stops with ===> Verifying specs: glib-2.0 gmodule-2.0 gobject-2.0 gthread-2.0 xml2 z m pcre gstreamer-0.10 intl>=5 iconv>=6 glib-2.0 gmodule-2.0 gobject-2.0 gthread-2.0 xml2 z m pcre gstreamer-0.10 intl>=5 iconv>=6 BPM GL SDL SoundTouch X11 Xau Xdamage Xdmcp Xext Xfixes Xrender Xxf86vm ass bz2 cairo cdaudio croco-0.6 crypto curl dca drm dvdnav dvdread enca expat fontconfig freetype gdk_pixbuf-2.0 gio-2.0 gsm gstaudio-0.10 gstbase-0.10 gstcontroller-0.10 gstinterfaces-0.10 gstpbutils-0.10 gstriff-0.10 gstrtp-0.10 gstsdp-0.10 gsttag-0.10 gstvideo-0.10 idn jasper lrdf mms mpcdec orc-0.4 pango-1.0 pangocairo-1.0 pangoft2-1.0 pixman-1 png pthread-stubs raptor rsvg-2 schroedinger-1.0 sndfile sndio ssl stdc++ usbhid vpx xcb xcb-render xcb-shm xslt glib-2.0 gmodule-2.0 gobject-2.0 gthread-2.0 xml2 z m pcre gstreamer-0.10 intl>=5 iconv>=6 gstbase-0.10 neon crypto expat ssl asn1 gssapi krb5 glib-2.0 gmodule-2.0 gobject-2.0 gthread-2.0 xml2 z m pcre gstreamer-0.10 intl>=5 iconv>=6 gstbase-0.10 stdc++ mjpegutils-1.9 mpeg2encpp-1.9 mplex2-1.9 Missing library for BPM>=0.0 Missing library for SoundTouch>=0.0 Missing library for croco-0.6>=0.0 Missing library for gstaudio-0.10>=0.0 Missing library for gstinterfaces-0.10>=0.0 Missing library for gstpbutils-0.10>=0.0 Missing library for gstriff-0.10>=0.0 Missing library for gstrtp-0.10>=0.0 Missing library for gstsdp-0.10>=0.0 Missing library for gsttag-0.10>=0.0 Missing library for gstvideo-0.10>=0.0 Missing library for rsvg-2>=0.0 Missing library for sndfile>=0.0 Missing library for mjpegutils-1.9>=0.0 Missing library for mpeg2encpp-1.9>=0.0 Missing library for mplex2-1.9>=0.0 Fatal error *** Error code 1 Is there something I need to install first that would pull these as dependencies, as opposed to installing them explicitly? Am I missing something? > These need to be built with opencore-amr already installed and checked as > to whether they need additional deps listing (WANTLIB/LIB_DEPENDS as usual, > but also
Re: [NEW] opencore-amr
On Jul 03 21:11:22, Christian Weisgerber wrote: > Jan Stary wrote: > > > http://stare.cz/~hans/.tmp/opencore-amr-0.1.2.tar.gz > > > > It comes with the Apache License 2.0; I am not sure > > what that means for the PERMIT_* variables; I asked > > upstream, but someone here surely knows. > > AMR is patent-encumbered. We may not be able to put this on the > CDROM. Is this OK? http://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec#Licensing_and_patent_issues # Apache 2.0 PERMIT_PACKAGE_CDROM= patents, http://www.voiceage.com/amr_licterms.php PERMIT_PACKAGE_FTP = Yes PERMIT_DISTFILES_CDROM = patents, http://www.voiceage.com/amr_licterms.php PERMIT_DISTFILES_FTP= Yes Jan
Re: new: games/nexuiz
On Sat, December 10, 2011 02:22, Pascal Stumpf wrote: > Nexuiz is a fast paced 3d deathmatch game project created online > by a team of developers called Alientrap. With an advanced UI the > user can select between over a dozen different player models with > an average of two skins for each and can connect to our master > server to play people from all over the world. > Hi. I've played two deathmatches on my amd64 with integrated intel video. The game is quite playable. I didn't look deep into compilation or packaging of this port.
=?utf-8?B?0KHQvtCx0LXRgNC10Lwg0LTQu9GPINCy0LDRgSDQv9C+INGB0LXRgtC4INC40L3RgtC10YDQvdC10YIg0LHQsNC30YMg0LTQsNC90L3Ri9GFINC/0L7RgtC10L3RhtC40LDQu9GM0L3Ri9GFINC60LvQuNC10L3RgtC+0LIg0LTQu9GPINCS0LDRiNC10L
Соберем для вас по сети интернет базу данных потенциальных клиентов для Вашего бизнеса. Все контактные данные.Много!Быстро!Недорого! Узнайте подробнее по телефону +79IЗЗ9I9ОIЗ Email: proda...@mixmail.com ICQ:6288862 Skype: s.3837
Re: UPDATE: QEMU 1.0
On 10/12/11 10:40 AM, Stefan Sperling wrote: On Fri, Dec 09, 2011 at 09:08:17AM -0500, Brad wrote: On Fri, Dec 09, 2011 at 02:20:29AM -0500, Brad wrote: On Fri, Dec 09, 2011 at 01:13:02AM +, Stuart Henderson wrote: On 2011-12-07, Brad wrote: -@bin bin/qemu I'd prefer to keep this working via a courtesy symlink pointing at either qemu-system-i386 or qemu-system-x86_64. Otherwise there needs to be some clear information. Without one or other of these, people are going to wonder what's going on, tab-complete, see qemu-i386, try and run it, receive a segfault, then think, as well as forcing them to make changes to their scripts, that the update has totally broken qemu. I'm not adding a symlink as there will be another binary of the same name there in the future. Users should be conditioned to use qemu-system-i386 properly. Updated diff adding MESSAGE to mention the change. Maybe also mention the change in the upgrade/current FAQ? and disable the BSD userland emulation support for now. On amd64 this warning appears during the build: /usr/ports/pobj/qemu-1.0/qemu-1.0/monitor.c: In function 'expire_password': /usr/ports/pobj/qemu-1.0/qemu-1.0/monitor.c:944: warning: overflow in implicit constant conversion Qemu assumes time_t is long if TIME_MAX isn't defined. But time_t is int on OpenBSD. Setting TIME_MAX to INT_MAX via CFLAGS fixes the warning. Suggested diff with that change below. Ya, I'm fine with that as a workaround for the time being and will take it up with upstream for a proper fix. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
