Re: NEW: games/xmoto + devel/ode
On Thu, Dec 11, 2008 at 12:42:01AM +0300, Kirill S. Bychkov wrote: > Hello, porters. > This is a port of xmoto and library it depends on. > > cat pkg/DESCR > X-Moto is a challenging 2D motocross platform game, where physics plays an all > important role in the gameplay. You need to control your bike to its limits, > if you want to have a chance to finish the most difficult challenges. > > and > > cat pkg/DESCR > ODE is an open source, high performance library for simulating rigid body > dynamics. It is fully featured, stable, mature and platform > independent with an easy to use C/C++ API. It has advanced joint types and > integrated collision detection with friction. ODE is useful for simulating > vehicles, objects in virtual reality environments and virtual creatures. It is > currently used in many computer games, 3D authoring tools and simulation > tools. > > Runs fine on i386. > Please, test and commit. > Runs fine here (i386) with --ugly. Thanks for the port -- very challenging game! I've found out that the game supports experimental Chipmunk [0] physics as well. You can get example chipmunks levels here [1]; they are awesome! [0] - http://wiki.slembcke.net/main/published/Chipmunk [1] - http://download.tuxfamily.org/xmoto/xmoto/dev/chipmunk_levels/ -- C programmers never die. They're just cast into void. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
UPDATE: net/rrdtool
Hi!
This updates rrdtool-1.2.23 to 1.2.28. Use patch -E, one new patch was
added, and one removed.
It's been running for a while on i386 here without problems.
Please test/comment.
Daniel
--
LEVAI Daniel
PGP key ID = 0x4AC0A4B1
Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Index: Makefile
===
RCS file: /cvs/ports/net/rrdtool/Makefile,v
retrieving revision 1.43
diff -u -r1.43 Makefile
--- Makefile 7 Oct 2008 14:27:22 - 1.43
+++ Makefile 27 Nov 2008 09:16:38 -
@@ -6,11 +6,11 @@
COMMENT-perl= perl interface to librrd
COMMENT-python= python interface to librrd
-VERSION= 1.2.23
+VERSION= 1.2.28
DISTNAME= rrdtool-${VERSION}
PKGNAME-main= ${DISTNAME}p0
-PKGNAME-perl= p5-RRD-${VERSION}p1
-PKGNAME-python= py-rrd-${VERSION}p1
+PKGNAME-perl= p5-RRD-${VERSION}
+PKGNAME-python= py-rrd-${VERSION}p0
SHARED_LIBS+= rrd 3.0
SHARED_LIBS+= rrd_th 3.0
Index: distinfo
===
RCS file: /cvs/ports/net/rrdtool/distinfo,v
retrieving revision 1.9
diff -u -r1.9 distinfo
--- distinfo 12 Sep 2007 14:34:36 - 1.9
+++ distinfo 27 Nov 2008 09:16:38 -
@@ -1,5 +1,5 @@
-MD5 (rrdtool-1.2.23.tar.gz) = 2voWG8nGHldjamCFyHwf6A==
-RMD160 (rrdtool-1.2.23.tar.gz) = DBFHJCrfR29ek/TVm1U+4+o3iyM=
-SHA1 (rrdtool-1.2.23.tar.gz) = XaYQ4ci8AbgKvCGrnpjgBDY7Qpw=
-SHA256 (rrdtool-1.2.23.tar.gz) = Sx3wCyOnShyBc03SdOcuANi7KbEeHz0pOP+HaR7OHw8=
-SIZE (rrdtool-1.2.23.tar.gz) = 1061530
+MD5 (rrdtool-1.2.28.tar.gz) = xniBHCqsyGWr9C1dIeyNdg==
+RMD160 (rrdtool-1.2.28.tar.gz) = EaTGQUA3s84OSdSbRY+fwT8+97o=
+SHA1 (rrdtool-1.2.28.tar.gz) = qMp1/PezLKlLBX+mY+X5iVIuLfk=
+SHA256 (rrdtool-1.2.28.tar.gz) = oAj+yYuzbQmnvogQr73Rv1HXNlIA0DoOlmopv4cbMEE=
+SIZE (rrdtool-1.2.28.tar.gz) = 1089006
Index: patches/patch-bindings_Makefile_in
===
RCS file: /cvs/ports/net/rrdtool/patches/patch-bindings_Makefile_in,v
retrieving revision 1.1
diff -u -r1.1 patch-bindings_Makefile_in
--- patches/patch-bindings_Makefile_in 12 Sep 2007 14:34:36 - 1.1
+++ patches/patch-bindings_Makefile_in 27 Nov 2008 09:16:38 -
@@ -1,12 +1,21 @@
-$OpenBSD: patch-bindings_Makefile_in,v 1.1 2007/09/12 14:34:36 msf Exp $
bindings/Makefile.in.orig Wed May 2 19:06:59 2007
-+++ bindings/Makefile.in Tue Sep 11 14:31:11 2007
-@@ -550,7 +550,7 @@ ruby:
+--- bindings/Makefile.in.orig Wed Jul 23 15:56:19 2008
bindings/Makefile.in Sat Nov 22 14:09:31 2008
+@@ -552,15 +552,15 @@ install-data-local:
+ test -f ruby/Makefile && cd ruby && $(MAKE) EPREFIX=$(DESTDIR)$(exec_prefix) $(RUBY_MAKE_OPTIONS) install || true
+ test -d python/build && cd python && env BUILDLIBDIR=../../src/.libs $(PYTHON) setup.py install --skip-build --prefix=$(DESTDIR)$(prefix) --exec-prefix=$(DESTDIR)$(exec_prefix) || true
- # rules for buildung the pyton module
+-# rules for buildung the ruby module
++# rules for building the ruby module
+ # RUBYARCHDIR= is to work around in a makefile quirk not sure
+ # it is is the right thing todo, but it makes rrdtool build on freebsd as well
+ ruby:
+ cd ruby && $(RUBY) extconf.rb && $(MAKE) EPREFIX=$(exec_prefix) $(RUBY_MAKE_OPTIONS) RUBYARCHDIR=
+
+-# rules for buildung the pyton module
++# rules for building the python module
python:
-- cd python && env LIBDIR=../../src/.libs $(PYTHON) setup.py build
-+ cd python && env LIBDIR=../../src/.libs INCDIR=../../src $(PYTHON) setup.py build
+- cd python && env BUILDLIBDIR=../../src/.libs $(PYTHON) setup.py build_ext --rpath=$(libdir) && env LIBDIR=../../src/.libs $(PYTHON) setup.py build
++ cd python && env BUILDLIBDIR=../../src/.libs INCDIR=../../src $(PYTHON) setup.py build_ext --rpath=$(libdir) && env LIBDIR=../../src/.libs $(PYTHON) setup.py build
# rules for building the perl module
perl_piped: perl-piped/Makefile
Index: patches/patch-doc_Makefile_in
===
RCS file: /cvs/ports/net/rrdtool/patches/patch-doc_Makefile_in,v
retrieving revision 1.6
diff -u -r1.6 patch-doc_Makefile_in
--- patches/patch-doc_Makefile_in 12 Sep 2007 14:34:36 - 1.6
+++ patches/patch-doc_Makefile_in 27 Nov 2008 09:16:38 -
@@ -1,7 +1,7 @@
-$OpenBSD: patch-doc_Makefile_in,v 1.6 2007/09/12 14:34:36 msf Exp $
doc/Makefile.in.orig Thu May 3 03:06:59 2007
-+++ doc/Makefile.in Wed Jun 20 08:48:25 2007
-@@ -147,7 +147,7 @@ PYTHON_PLATFORM = @PYTHON_PLATFORM@
+$OpenBSD$
+--- doc/Makefile.in.orig Wed Jul 23 15:56:19 2008
doc/Makefile.in Sat Nov 22 14:09:31 2008
+@@ -150,7 +150,7 @@ PYTHON_PLATFORM = @PYTHON_PLATFORM@
PYTHON_PREFIX = @PYTHON_PREFIX@
PYTHON_VERSION = @PYTHON_VERSION@
RANLIB = @RANLIB@
Index: patches/patch-examples_Makefile_in
===
RCS file: /cvs/ports/net/rrdtool/patches/patch-examples_Makefile_in,v
retrieving revision 1.6
diff -u -r1.6 patch-examples_Makefile
Re: Xine-lib sndio backend
On Thu, Dec 11, 2008 at 12:45:57AM -0500, Brad wrote:
> The following diff adds a sndio backend to the Xine-lib library
> which is used by Kaffeine / Xine(-ui), Gwenview (via Kaffeine)
> and some parts of KDE via kdemultimedia.
>
> I must note that while working on the sndio backend I found that
> once implemented that even without using the aucat sound server,
> Xine(-lib) based apps gracefully would deal with the lack of an
> audio device if it was already open by another app. Where as with
> the existing Sun audio backend the other apps would just outright
> not play the content at all if the backend failed to open the
> device, which I found really annoying. aucat is just icing on the
> cake :)
>
> Please test as much as possible. Nothing special needs to be done
> other than building and upgrading the xine-lib package. The new
> sndio backend has the highest priority so it'll be used automatically
> over the Sun backend unless specifically overridden in the application
> settings.
>
very cool. I can't test it right now (no access to openbsd), so i
quickly comment the diff. More comments this evening.
> Index: files/audio_sndio_out.c
> ===
> RCS file: files/audio_sndio_out.c
> diff -N files/audio_sndio_out.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ files/audio_sndio_out.c 11 Dec 2008 03:54:26 -
> @@ -0,0 +1,415 @@
> +/* -*- Mode: C; c-basic-offset: 2; indent-tabs-mode: nil -*- */
> +
> +/*
> + * Copyright (C) 2008 the xine project
> + *
> + * This file is part of xine, a free video player.
> + *
> + * xine is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
files in files/ subdirectories should use license.template. Once
the code is ready to go upstream we're supposed to send the files
with the project license if necessary. That's what i got after a
private discussion with [EMAIL PROTECTED]
> +static int ao_sndio_delay (ao_driver_t *this_gen)
> +{
> + sndio_driver_t *this = (sndio_driver_t *) this_gen;
> + int ret = 0;
> +
> + return ret;
> +}
afaiu this is the delay (sample periods) between the moment the
last sample was written and the moment the user hears it. It cannot
be zero. See for instance ports/x11/mplayer/files/ao_libsndio.c or
src/regress/lib/libsndio/play/play.c
if you're bored by this stuff and can wait until this week-end i
can add the missing bits, let me know
> +
> +static int ao_sndio_set_property (ao_driver_t *this_gen, int property, int
> value)
> +{
> + sndio_driver_t *this = (sndio_driver_t *) this_gen;
> + int vol;
> +
> + switch(property) {
> + case AO_PROP_PCM_VOL:
> + case AO_PROP_MIXER_VOL:
> +this->mixer.volume = value;
> +if (!this->mixer.mute)
> + sio_setvol(this->hdl, this->mixer.volume);
> +return this->mixer.volume;
> +break;
> +
if two knobs control the volume, there will be abrupt jumps in the
volume if both knobs are touched. Imo you should either ignore
AO_PROP_MIXER or (if you think both are required) use the product
of the two values:
val = val_mixer * val_pcm / 127;
> +static int ao_sndio_ctrl(ao_driver_t *this_gen, int cmd, ...)
> +{
> + sndio_driver_t *this = (sndio_driver_t *) this_gen;
> + int ret = 0;
> +
> + switch (cmd) {
> + case AO_CTRL_FLUSH_BUFFERS:
> +break;
> +
> + case AO_CTRL_PLAY_RESUME:
> +if (!sio_start(this->hdl)) {
> + xprintf (this->xine, XINE_VERBOSITY_DEBUG,
> + "audio_sndio_out: ao_sndio_ctrl could not start\n");
> + ret = 1;
> +}
> +break;
> +
> + case AO_CTRL_PLAY_PAUSE:
> +if (!sio_stop(this->hdl)) {
> + xprintf (this->xine, XINE_VERBOSITY_DEBUG,
> + "audio_sndio_out: ao_sndio_ctrl could not stop\n");
> + ret = 1;
> +}
> +break;
> + }
> +
if you implement ao_sndio_delay() this will hurt you because
sio_stop() will consume the buffered samples and video/audio will
go out of sync. The easier is to leave pause/resume stuff empty;
libsndio pauses audio if there are no more samples to play and
resumes when there are enough samples again.
> +
> + /*
> + * set capabilities
> + */
> + this->capabilities =
> +AO_CAP_MODE_MONO | AO_CAP_MODE_STEREO | AO_CAP_MODE_4CHANNEL |
> +AO_CAP_MODE_4_1CHANNEL | AO_CAP_MODE_5CHANNEL | AO_CAP_MODE_5_1CHANNEL |
> +AO_CAP_MIXER_VOL | AO_CAP_PCM_VOL | AO_CAP_MUTE_VOL |
> +AO_CAP_8BITS | AO_CAP_16BITS | AO_CAP_24BITS | AO_CAP_FLOAT32;
we don't support AU_CAP_FLOAT32 encoding.
-- Alexandre
Re: UPDATE: net/rrdtool
On 2008/12/11 10:44, LÉVAI Dániel wrote:
> This updates rrdtool-1.2.23 to 1.2.28. Use patch -E, one new patch was
> added, and one removed.
> It's been running for a while on i386 here without problems.
>
> Please test/comment.
> PKGNAME-main=${DISTNAME}p0
this can go completely
> -PKGNAME-python= py-rrd-${VERSION}p1
> +PKGNAME-python= py-rrd-${VERSION}p0
and remove p0 here
> SHARED_LIBS+=rrd 3.0
> SHARED_LIBS+=rrd_th 3.0
diff doesn't show any API changes so that looks alright, but you should
always check (and if you did already check, please mention that :-)
> +-# rules for buildung the ruby module
> ++# rules for building the ruby module
> +-# rules for buildung the pyton module
> ++# rules for building the python module
it's pointless to fix these in a ports diff, please just send them upstream
> +-#if defined(HAVE_SYS_MMAN_H)
> +-#include
> +-#endif
> +-
> + #ifdef HAVE_SYS_TYPES_H
> + # include
> ++#endif
> ++
> ++#if defined(HAVE_SYS_MMAN_H)
> ++#include
> + #endif
I agree with doing that here for now but it also should go upstream.
WANTLIB-perl needed an update, and the PLISTs needed changing.
I'll send an updated diff to the port's maintainer.
Re: FIX: lang/python (correct .py path in installed .pyc)
On Sun, 7 Dec 2008 21:11:15 +0100 (CET) Antoine Jacoutot <[EMAIL PROTECTED]> wrote: > On Sun, 7 Dec 2008, Eric Faurot wrote: > > Just like a port are not generally bumped when a lib in WANTLIB change, but > > the > > If we change a WANTLIB, we *do* bump the PKGNAME. Sorry, I did not make myself clear. The exact dependencies recorded in the packages are the ones found when the packages are built; when a lib (libm for example) is bumped, the packages change on next build, but not their port versions. That's why I think this is not really a big issue not to update the port version; it is more or less the same thing. Eric.
Re: UPDATE: net/rrdtool
Stuart Henderson wrote:
On 2008/12/11 10:44, LÉVAI Dániel wrote:
PKGNAME-main= ${DISTNAME}p0
this can go completely
-PKGNAME-python= py-rrd-${VERSION}p1
+PKGNAME-python= py-rrd-${VERSION}p0
and remove p0 here
SHARED_LIBS+= rrd 3.0
SHARED_LIBS+= rrd_th 3.0
diff doesn't show any API changes so that looks alright, but you should
always check (and if you did already check, please mention that :-)
I'll do that next time, sorry.
+-# rules for buildung the ruby module
++# rules for building the ruby module
+-# rules for buildung the pyton module
++# rules for building the python module
it's pointless to fix these in a ports diff, please just send them upstream
Alright.
+-#if defined(HAVE_SYS_MMAN_H)
+-#include
+-#endif
+-
+ #ifdef HAVE_SYS_TYPES_H
+ # include
++#endif
++
++#if defined(HAVE_SYS_MMAN_H)
++#include
+ #endif
I agree with doing that here for now but it also should go upstream.
Okay, I'll send them.
WANTLIB-perl needed an update, and the PLISTs needed changing.
I'll send an updated diff to the port's maintainer.
Thank you!
Daniel
--
LEVAI Daniel
PGP key ID = 0x4AC0A4B1
Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
lib-depends-check question
Hi everyone. I've installed -curent (OpenBSD 4.4-current (GENERIC) #1558: Fri Dec 5 23:56:03 MST 2008 \ [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC) and checkouted ports tree (Dec, 8th). When I'm running make lib-depends-check on some of my ports, I've got such output: WANTLIB: dbus-1.7 from dbus-1.2.4p0 (/usr/local/bin/gapcmon) LIB_DEPENDS: gio-2.0.1800 from glib2-2.18.3 (/usr/local/bin/gapcmon) WANTLIB += dbus-1 The same situation with some other ports, which depend on glib. And I'm sure they are not using DBus and, probably, gio. And were pretty working without these dependencies earlier. So the question: should I ignore these new dependencies or not?
Re: lib-depends-check question
On 2008/12/11 15:38, Kirill S. Bychkov wrote: > Hi everyone. > I've installed -curent (OpenBSD 4.4-current (GENERIC) #1558: Fri Dec 5 > 23:56:03 MST 2008 \ > [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC) and > checkouted ports tree (Dec, 8th). > When I'm running make lib-depends-check on some of my ports, I've got such > output: > WANTLIB: dbus-1.7 from dbus-1.2.4p0 (/usr/local/bin/gapcmon) > LIB_DEPENDS: gio-2.0.1800 from glib2-2.18.3 (/usr/local/bin/gapcmon) > WANTLIB += dbus-1 > The same situation with some other ports, which depend on glib. And I'm sure > they are not using DBus and, probably, gio. And were pretty working without > these dependencies earlier. > > So the question: should I ignore these new dependencies or not? no, they should be added.
Re: lib-depends-check question
Tahnks for fast reply. And why the appeared? Due port-tree infrastructure changes or updates of dbus/glib? On Thu, December 11, 2008 15:59, Stuart Henderson wrote: > On 2008/12/11 15:38, Kirill S. Bychkov wrote: >> Hi everyone. >> I've installed -curent (OpenBSD 4.4-current (GENERIC) #1558: Fri Dec 5 >> 23:56:03 MST 2008 \ >> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC) and >> checkouted ports tree (Dec, 8th). >> When I'm running make lib-depends-check on some of my ports, I've got such >> output: >> WANTLIB: dbus-1.7 from dbus-1.2.4p0 (/usr/local/bin/gapcmon) >> LIB_DEPENDS: gio-2.0.1800 from glib2-2.18.3 (/usr/local/bin/gapcmon) >> WANTLIB += dbus-1 >> The same situation with some other ports, which depend on glib. And I'm sure >> they are not using DBus and, probably, gio. And were pretty working without >> these dependencies earlier. >> >> So the question: should I ignore these new dependencies or not? > > no, they should be added. >
Re: mplayer audio and video stutters on CURRENT
On Wed, Dec 10, 2008 at 01:57:59PM -0500, STeve Andre' wrote:
> On Wednesday 10 December 2008 02:28:36 Claudio Jeker wrote:
> > On Wed, Dec 10, 2008 at 07:55:59AM +0100, Andreas Bartelt wrote:
> > > Hello,
> > >
> > > I've updated my systems to CURRENT on Dec, 7th. Since then, I'm
> > > experiencing problems with mplayer audio and video playback on one of my
> > > boxes (audio and video stutters about every 5 seconds). Could this be
> > > caused by the libsndio related changes which have been committed to the
> > > mplayer port about one month ago?
> >
> > Try running mplayer with -ao sun to use the old audio code and see if that
> > helps. If the symptoms go away it could be something with libsndio.
>
> I have a W500 ThinkPad, and have the stutter problem. I just tried running
> mplayer with -ao sun, and the .mov file I first noticed the problem with plays
> perfectly. Running without the -ao switch caused the stuttering again.
>
> This is on a -current system last compiled Dec 3rd.
Absolutely the same here with a -current system compiled on Dec 2nd.
Stefan
OpenBSD 4.4-current (GENERIC.MP) #14: Tue Dec 2 00:44:37 CET 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Genuine Intel(R) CPU L2400 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,VMX,EST,TM2,xTPR
real mem = 1063677952 (1014MB)
avail mem = 1020190720 (972MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/31/08, BIOS32 rev. 0 @ 0xfd690, SMBIOS
rev. 2.4 @ 0xe0010 (67 entries)
bios0: vendor LENOVO version "7BETD5WW (2.16 )" date 03/31/2008
bios0: LENOVO 170255G
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4)
EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 166MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU L2400 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,VMX,EST,TM2,xTPR
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2
acpicpu1 at acpi0: C3, C2
acpitz0 at acpi0: critical temperature 127 degC
acpitz1 at acpi0: critical temperature 97 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "92P1163" serial 1585 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0
acpidock at acpi0 not configured
acpivideo at acpi0 not configured
acpivideo at acpi0 not configured
bios0: ROM list: 0xc/0xea00! 0xcf000/0x1000 0xd/0x1000 0xdc000/0x4000!
0xe/0x1!
cpu0: unknown Enhanced SpeedStep CPU, msr 0x06130a2206000613
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 1000 MHz (1004 mV): speeds: 1667, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
vga1 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: apic 1 int
17 (irq 11)
azalia0: codecs: Analog Devices/0x1981, Conexant/0x2bfa, using Analog
Devices/0x1981
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 20
(irq 11)
pci1 at ppb0 bus 2
em0 at pci1 dev 0 function 0 "Intel PRO/1000MT (82573L)" rev 0x00: apic 1 int
16 (irq 11), address 00:0a:e4:3e:f1:4e
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 21
(irq 11)
pci2 at ppb1 bus 3
wpi0 at pci2 dev 0 function 0 "Intel PRO/Wireless 3945ABG" rev 0x02: apic 1 int
17 (irq 11), MoW2, address 00:13:02:03:a5:e7
ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 22
(irq 11)
pci3 at ppb2 bus 4
ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 1 int 23
(irq 11)
pci4 at ppb3 bus 12
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 16
(irq 11)
uhci1 at p
Re: mplayer audio and video stutters on CURRENT
Hi! On Wed, Dec 10, 2008 at 06:18:20PM +0100, Alexandre Ratchov wrote: >On Wed, Dec 10, 2008 at 05:53:42PM +0100, Andreas Bartelt wrote: >> Alexandre Ratchov wrote: >>> On Wed, Dec 10, 2008 at 07:55:59AM +0100, Andreas Bartelt wrote: I've updated my systems to CURRENT on Dec, 7th. Since then, I'm experiencing problems with mplayer audio and video playback on one of my boxes (audio and video stutters about every 5 seconds). Could this be caused by the libsndio related changes which have been committed to the mplayer port about one month ago? >>> does it happen both with and without "aucat -l" running? >> with "aucat -l" running, there are no problems with mplayer/libsndio. >> Perhaps I did miss something in the last weeks -- will there be an aucat >> daemon in the future which should run by default in order to handle >> audio? >yes i hope this will be possible. First we have to update all ports >to use libsndio, because while aucat is running, programs trying to >open directly /dev/audio will fail with "Device busy". Couldn't aucat free the sound device after some idle time (and re-open when needed), just like esd or arts do it? Then it could co-habitate a bit better with applications that do not use aucat. >[...] Kind regards, Hannah.
Re: lib-depends-check question
On Thu, Dec 11, 2008 at 04:06:56PM +0300, Kirill S. Bychkov wrote: > Tahnks for fast reply. And why the appeared? Due port-tree infrastructure > changes or updates of dbus/glib? Updates to dbus/glib/gnome, most probably. The reason they should be added is updates. It's the only way for the pkg system to know that a given library with a given version is still needed for something.
Re: mplayer audio and video stutters on CURRENT
On Thu, Dec 11, 2008 at 02:18:53PM +0100, Hannah Schroeter wrote: > Hi! > > On Wed, Dec 10, 2008 at 06:18:20PM +0100, Alexandre Ratchov wrote: > >yes i hope this will be possible. First we have to update all ports > >to use libsndio, because while aucat is running, programs trying to > >open directly /dev/audio will fail with "Device busy". > > Couldn't aucat free the sound device after some idle time (and re-open > when needed), just like esd or arts do it? Then it could co-habitate a > bit better with applications that do not use aucat. +1 For example, xmms and aucat cannot be used together right now, which prevents me from testing aucat altogether (I need my sound card to play music, you know :) Converting all ports should be a long-term goal, but having a simple mechanism for cooperation between aucat and non-aucat apps would be very nice. There will likely always be new sound apps that get ported and initially lack a libsndio backend. Stefan
New port: sysutils/faubackup
Hej, appended tarball contains a port of faubackup: (from DESCR): faubackup uses a filesystem on a hard drive for incremental and full backups. All backups can easily be accessed by standard filesystem tools. Later backups to the same filesystem will automatically be incremental, as unchanged files are only hard-linked with the existing version of the file. Tested and working on i386. Please test, comment, commit. Thanks Sebastian -- gpg:0xba19b59ccdb73113 www:http://basti.schleifi.com/ mail: [EMAIL PROTECTED] faubackup-0.9.5.tgz Description: GNU Unix tar archive signature.asc Description: Digital signature
Re: New port: sysutils/faubackup
Sebastian Trahm wrote: Tested and working on i386. Please test, comment, commit. Tested @amd64, works well, nice utility. A few things about the port: The license is GPLv2 SEPARATE_BUILD works so why not enabling it ? Cheers Giovanni
how to config arpwatch
I use OpenBSD 4.4 and install arpwatch with port how I can config it right now and say to arpwatch send me eamil.
Re: mplayer audio and video stutters on CURRENT
On Thu, Dec 11, 2008 at 01:51:55PM +, Stefan Sperling wrote: > On Thu, Dec 11, 2008 at 02:18:53PM +0100, Hannah Schroeter wrote: > > Hi! > > > > On Wed, Dec 10, 2008 at 06:18:20PM +0100, Alexandre Ratchov wrote: > > >yes i hope this will be possible. First we have to update all ports > > >to use libsndio, because while aucat is running, programs trying to > > >open directly /dev/audio will fail with "Device busy". > > > > Couldn't aucat free the sound device after some idle time (and re-open > > when needed), just like esd or arts do it? Then it could co-habitate a > > bit better with applications that do not use aucat. > > +1 > > For example, xmms and aucat cannot be used together right now, which > prevents me from testing aucat altogether (I need my sound card to > play music, you know :) > Unfortunately this requires intrusive changes that would complicate (and weaken) aucat. It would be a lot of work for something that will not be used in the long term. > Converting all ports should be a long-term goal, but having a simple > mechanism for cooperation between aucat and non-aucat apps would > be very nice. There will likely always be new sound apps that get > ported and initially lack a libsndio backend. > new apps will likely lack support for the sun audio api too. Adding support for libsndio is supposed to be easier than porting them to the sun audio api. -- Alexandre
sndio conversion list?
Has anybody bothered to maintain a list of ports that (still) could use conversion from a sun audio backend to sndio? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: sndio conversion list?
On Thu, Dec 11, 2008 at 06:35:01PM +, Christian Weisgerber wrote: > Has anybody bothered to maintain a list of ports that (still) could > use conversion from a sun audio backend to sndio? > afaik nobody maintains such a list; currently jakemsr and me notify each other about who's working on what, and we both follow ports@ i was thinking of setting up a ``conversion tips & todo list'' with the status of ports and the persons working on them but it wasn't useful until now. to get a complete list of ports that need conversion i unpack all distfiles and grep for AUDIO_SETINFO. -- Alexandre
Re: mplayer audio and video stutters on CURRENT
On Thu, Dec 11, 2008 at 01:51:55PM +, Stefan Sperling wrote: > On Thu, Dec 11, 2008 at 02:18:53PM +0100, Hannah Schroeter wrote: > > Hi! > > > > On Wed, Dec 10, 2008 at 06:18:20PM +0100, Alexandre Ratchov wrote: > > >yes i hope this will be possible. First we have to update all ports > > >to use libsndio, because while aucat is running, programs trying to > > >open directly /dev/audio will fail with "Device busy". > > > > Couldn't aucat free the sound device after some idle time (and re-open > > when needed), just like esd or arts do it? Then it could co-habitate a > > bit better with applications that do not use aucat. > > +1 as Alexandre said, that is bad for aucat. aucat is ultimately designed to be "professional quality". esd and artsd and anything else that releases the soundcard is not designed for "professional use". > For example, xmms and aucat cannot be used together right now, which > prevents me from testing aucat altogether (I need my sound card to > play music, you know :) $ aucat -l ^C you can't use the soundcard with more than one app at a time anyway ... that being said, I spent 30 min (while eating on "lunch break") last night on porting esound to libsndio. it should be done with another few minutes work. then you can use xmms-esd. > Converting all ports should be a long-term goal, but having a simple > mechanism for cooperation between aucat and non-aucat apps would > be very nice. there is. start and stop aucat manually. you can't use the soundcard with more than one app at a time anyway ... > There will likely always be new sound apps that get > ported and initially lack a libsndio backend. imo, it is very short sighted to port new audio apps to OpenBSD but not add libsndio support. especially if the porter has to touch the audio backend at all. the ports that have libsndio support are either very common (mplayer) or can be used by other ports. this was quite intentional. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: mplayer audio and video stutters on CURRENT
On Thu, Dec 11, 2008 at 07:22:44PM +, Jacob Meuser wrote: > I spent 30 min (while eating on "lunch break") last > night on porting esound to libsndio. it should be done with another > few minutes work. then you can use xmms-esd. Oh, that's neat. Thanks! I'll test that as soon as it's available. You have lunch at night? Stefan
Re: sndio conversion list?
On Thu, Dec 11, 2008 at 06:35:01PM +, Christian Weisgerber wrote: > Has anybody bothered to maintain a list of ports that (still) could > use conversion from a sun audio backend to sndio? not exactly, but http://jakemsr.trancell.org/libsndio.html has a list of what is being worked on, so work is not duplicated. *sigh* I kinda wish I had never fixed the problems in ossaudio(3). -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: sndio conversion list?
On Thu, Dec 11, 2008 at 08:18:40PM +0100, Alexandre Ratchov wrote: > On Thu, Dec 11, 2008 at 06:35:01PM +, Christian Weisgerber wrote: > > Has anybody bothered to maintain a list of ports that (still) could > > use conversion from a sun audio backend to sndio? > > > > afaik nobody maintains such a list; currently jakemsr and me notify > each other about who's working on what, and we both follow ports@ > > i was thinking of setting up a ``conversion tips & todo list'' with http://www.openbsd.org/audio-port.html would be a good place. > the status of ports and the persons working on them but it wasn't > useful until now. I intentionally left out who was working on sndio backends. no need to hold people "responsible" for unfinished work. although, if someone does say they are working on it, please do finish it or let us know work has been abandoned. > to get a complete list of ports that need conversion i unpack all > distfiles and grep for AUDIO_SETINFO. indeed. it is easier to find out what ports use ossaudio(3), since they have ossaudio in WANTLIB. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Help in compiling gtk2mm
After a lot of scrounging around I could use some help in getting gtk2mm to compile. I've rebuilt my package builder and I'm having problems with gtk2mm (and gcc 4.2 but thats seperate). It doesn't compile regardless of other installed packages, or standalone with nothing pre-installed. This is a -current system, compiled on Dec 8th, but this has been a problem since around the gtk+2 update. I know I'm missing something but for the life of me, I haven't found it. I have complete script(1) output if thats useful. Thanks... --STeve Andre' /usr/local/bin/libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"gtkmm\" -I../../gtk -I/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk -I../../pango -I/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/pango -I../../atk -I/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/atk -I../../gdk -I/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gdk -I../../gtk -I/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk -I/usr/local/include/glibmm-2.4 -I/usr/local/lib/glibmm-2.4/include -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/cairomm-1.0 -I/usr/local/include/gtk-2.0 -I/usr/local/include/gtk-unix-print-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/pango-1.0 -I/usr/X11R6/include -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/X11R6/include/pixman-1 -I/usr/local/include -I/usr/local/include/libpng -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R6/include/freetype2 -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -O2 -pipe -Wall -c -o toolbar.lo /usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk/gtkmm/toolbar.cc c++ -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"gtkmm\" -I../../gtk -I/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk -I../../pango -I/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/pango -I../../atk -I/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/atk -I../../gdk -I/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gdk -I../../gtk -I/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk -I/usr/local/include/glibmm-2.4 -I/usr/local/lib/glibmm-2.4/include -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/cairomm-1.0 -I/usr/local/include/gtk-2.0 -I/usr/local/include/gtk-unix-print-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/pango-1.0 -I/usr/X11R6/include -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/X11R6/include/pixman-1 -I/usr/local/include -I/usr/local/include/libpng -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R6/include/freetype2 -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -O2 -pipe -Wall -c /usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk/gtkmm/toolbar.cc -fPIC -DPIC -o .libs/toolbar.o /usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk/gtkmm/toolbar.cc: In member function `void Gtk::Toolbar::set_tooltips(bool)': /usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk/gtkmm/toolbar.cc:545: error: ` gtk_toolbar_set_tooltips' undeclared (first use this function) /usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk/gtkmm/toolbar.cc:545: error: (Each undeclared identifier is reported only once for each function it appears in.) /usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk/gtkmm/toolbar.cc: In member function `bool Gtk::Toolbar::get_tooltips() const': /usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/gtkmm-2.12.7/gtk/gtkmm/toolbar.cc:550: error: ` gtk_toolbar_get_tooltips' undeclared (first use this function) gmake[5]: *** [toolbar.lo] Error 1 gmake[5]: Leaving directory `/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/build-i386/gtk/gtkmm' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/build-i386/gtk/gtkmm' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/build-i386/gtk' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/build-i386/gtk' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/x11/gtk2mm/w-gtkmm-2.12.7/build-i386' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/x11/gtk2mm (line 2172 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/x11/gtk2mm (line 1427 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/x11/gtk2mm (line 1967 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/x11/gtk2mm (line 1947 of /usr/ports/infrastructure/mk/bsd.port.mk). vista /usr/ports/x11/gtk2mm
Re: mplayer audio and video stutters on CURRENT
On Thu, Dec 11, 2008 at 07:39:07PM +, Stefan Sperling wrote: > On Thu, Dec 11, 2008 at 07:22:44PM +, Jacob Meuser wrote: > > I spent 30 min (while eating on "lunch break") last > > night on porting esound to libsndio. it should be done with another > > few minutes work. then you can use xmms-esd. > > Oh, that's neat. Thanks! > I'll test that as soon as it's available. > > You have lunch at night? I have lunch when I'm hungry :) dinner to me means a nice meal with friends ;) -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
sndio for esound
please test ... and notice how much simpler this is than what it
replaces, even though esound prefers to use a fd for audio access.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: Makefile
===
RCS file: /cvs/ports/audio/esound/Makefile,v
retrieving revision 1.44
diff -u -r1.44 Makefile
--- Makefile31 Mar 2008 01:05:54 - 1.44
+++ Makefile11 Dec 2008 20:36:52 -
@@ -4,7 +4,7 @@
COMMENT= sound library for Enlightenment
DISTNAME= esound-0.2.38
-PKGNAME= ${DISTNAME}v0
+PKGNAME= ${DISTNAME}p0v0
SHARED_LIBS += esd 2.40 # .2.38
CATEGORIES=audio
MASTER_SITES= ${MASTER_SITE_GNOME:=sources/esound/0.2/}
@@ -18,7 +18,7 @@
PERMIT_PACKAGE_FTP=Yes
PERMIT_DISTFILES_CDROM=Yes
PERMIT_DISTFILES_FTP= Yes
-WANTLIB= c m wrap
+WANTLIB= c m sndio wrap
FLAVORS= arts
FLAVOR?=
@@ -47,7 +47,7 @@
esdconfdir=${PREFIX}/share/examples/esound
post-extract:
- @cp -f ${FILESDIR}/audio_sun.c ${WRKSRC}
+ @cp -f ${FILESDIR}/audio_sndio.c ${WRKSRC}
pre-configure:
@perl -pi -e 's|_LOCALBASE_|${LOCALBASE}|' \
Index: files/audio_sndio.c
===
RCS file: files/audio_sndio.c
diff -N files/audio_sndio.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/audio_sndio.c 11 Dec 2008 20:36:52 -
@@ -0,0 +1,112 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2008 Jacob Meuser
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistribution of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Neither the name of CubeSoft Communications, nor the names of its
+ *contributors may be used to endorse or promote products derived from
+ *this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
+ * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OF THIS SOFTWARE EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "config.h"
+
+#include
+
+struct sio_hdl *hdl = NULL;
+
+#define ARCH_esd_audio_open
+int esd_audio_open()
+{
+char *device;
+struct sio_par par;
+int mode = SIO_PLAY;
+
+sio_initpar(&par);
+
+if ((esd_audio_format & ESD_MASK_FUNC) == ESD_RECORD)
+mode |= SIO_REC;
+
+device = esd_audio_device ? esd_audio_device : getenv("AUDIODEVICE");
+if ((hdl = sio_open(device, mode, 0)) == NULL) {
+fprintf(stderr, "sio_open failed\n");
+return( -2 );
+}
+
+if ((esd_audio_format & ESD_MASK_BITS) == ESD_BITS16) {
+par.bits = 16;
+par.sig = 1;
+par.le = (BYTE_ORDER == 4321) ? 0 : 1;
+} else {
+par.bits = 8;
+par.sig = 0;
+par.le = (BYTE_ORDER == 4321) ? 0: 1;
+}
+
+par.pchan = (((esd_audio_format & ESD_MASK_CHAN) == ESD_STEREO) ? 2 : 1);
+if (mode & SIO_REC)
+par.rchan = par.pchan;
+
+par.bufsz = ESD_BUF_SIZE;
+
+par.rate = esd_audio_rate;
+
+if (!sio_setpar(hdl, &par)) {
+fprintf(stderr, "sio_setpar failed\n");
+return(-1);
+}
+
+if (!sio_getpar(hdl, &par)) {
+fprintf(stderr, "sio_getpar failed\n");
+return(-1);
+}
+
+if (fabs(par.rate - esd_audio_rate) > esd_audio_rate * 0.05) {
+fprintf(stderr, "Unsupported rate: %i Hz\n", esd_audio_rate);
+return(-1);
+}
+
+if (!sio_start(hdl)) {
+fprintf(stderr, "sio_start failed\n");
+return(-1);
+}
+
+return(1);
+}
+
+#define ARCH_esd_audio_close
+void esd_audio_close()
+{
+if (hdl != NULL) {
+sio_close(hdl);
+hdl = NULL;
+}
+}
+
+#define ARCH_esd_audio_write
+int esd_audio_write(void *buffer, int buf_size)
+{
+return sio_write(hdl, buffer, buf_size);
+}
+
+#define ARCH_esd_audio_read
+int esd_audio_read(void *buffer, int buf_size)
+{
+return sio_read(hdl, buffer, buf_size);
+}
Index: files/audio_sun.c
===
RCS file: files/audio_sun.c
diff -N files/audio_sun.c
--- fil
Re: sndio conversion list?
On Thu, Dec 11, 2008 at 12:02 PM, Jacob Meuser wrote: > On Thu, Dec 11, 2008 at 06:35:01PM +, Christian Weisgerber wrote: >> Has anybody bothered to maintain a list of ports that (still) could >> use conversion from a sun audio backend to sndio? > > not exactly, but > > http://jakemsr.trancell.org/libsndio.html > > has a list of what is being worked on, so work is not duplicated. > > *sigh* I kinda wish I had never fixed the problems in ossaudio(3). I'm the audio/aqualung maintainer (and recently became an upstream developer) and have already committed libsndio support upstream. I was waiting until the next release of aqualung to update the port, but if you want me to backport the libsndio diff to the current port version, I could probably do that. Jeremy
Re: sndio conversion list?
On Thu, Dec 11, 2008 at 01:36:43PM -0800, Jeremy Evans wrote: > On Thu, Dec 11, 2008 at 12:02 PM, Jacob Meuser > wrote: > > On Thu, Dec 11, 2008 at 06:35:01PM +, Christian Weisgerber wrote: > >> Has anybody bothered to maintain a list of ports that (still) could > >> use conversion from a sun audio backend to sndio? > > > > not exactly, but > > > > http://jakemsr.trancell.org/libsndio.html > > > > has a list of what is being worked on, so work is not duplicated. > > > > *sigh* I kinda wish I had never fixed the problems in ossaudio(3). > > I'm the audio/aqualung maintainer (and recently became an upstream > developer) and have already committed libsndio support upstream. I cool, thanks! > was waiting until the next release of aqualung to update the port, but > if you want me to backport the libsndio diff to the current port > version, I could probably do that. it's basically up to you. if there will be an aqualung release in the near future, there probably isn't much point in adding patches to the existing port. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: UPDATE: net/rrdtool
Is anyone work for RRDtool 1.3.4 ? 2008/12/11 LÉVAI Dániel : > Hi! > > This updates rrdtool-1.2.23 to 1.2.28. Use patch -E, one new patch was > added, and one removed. > It's been running for a while on i386 here without problems. > > Please test/comment. > > Daniel > > -- > LEVAI Daniel > PGP key ID = 0x4AC0A4B1 > Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1 >
Re: UPDATE: net/rrdtool
On 2008/12/12 09:31, Dongsheng Song wrote: > Is anyone work for RRDtool 1.3.4 ? i'll probably look at it in a day or two.
Re: UPDATE: net/rrdtool
On 2008/12/12 01:46, Stuart Henderson wrote:
> On 2008/12/12 09:31, Dongsheng Song wrote:
> > Is anyone work for RRDtool 1.3.4 ?
>
> i'll probably look at it in a day or two.
>
..or sooner.
Really lightly tested in standalone use on amd64 only so far.
Definitely needs much testing in other places and with the
bindings. Those using it in a chrooted environment will have
"a couple" more libraries to copy in...
Index: Makefile
===
RCS file: /cvs/ports/net/rrdtool/Makefile,v
retrieving revision 1.43
diff -u -p -r1.43 Makefile
--- Makefile7 Oct 2008 14:27:22 - 1.43
+++ Makefile12 Dec 2008 02:33:58 -
@@ -1,30 +1,30 @@
# $OpenBSD: Makefile,v 1.43 2008/10/07 14:27:22 sthen Exp $
-SHARED_ONLY= Yes
+SHARED_ONLY= Yes
COMMENT-main= system to store and display time-series data
COMMENT-perl= perl interface to librrd
COMMENT-python= python interface to librrd
-VERSION= 1.2.23
+VERSION= 1.3.4
DISTNAME= rrdtool-${VERSION}
-PKGNAME-main= ${DISTNAME}p0
-PKGNAME-perl= p5-RRD-${VERSION}p1
-PKGNAME-python= py-rrd-${VERSION}p1
+PKGNAME-main= ${DISTNAME}
+PKGNAME-perl= p5-RRD-${VERSION}
+PKGNAME-python=py-rrd-${VERSION}
-SHARED_LIBS+= rrd 3.0
-SHARED_LIBS+= rrd_th 3.0
+SHARED_LIBS+= rrd 4.0
+SHARED_LIBS+= rrd_th 4.0
CATEGORIES=net
MAINTAINER=Mathieu Sauve-Frankel
HOMEPAGE= http://oss.oetiker.ch/rrdtool/
-# GPL
-PERMIT_PACKAGE_CDROM= Yes
-PERMIT_PACKAGE_FTP=Yes
-PERMIT_DISTFILES_CDROM=Yes
-PERMIT_DISTFILES_FTP= Yes
+# GPLv2+
+PERMIT_PACKAGE_CDROM= Yes
+PERMIT_PACKAGE_FTP=Yes
+PERMIT_DISTFILES_CDROM=Yes
+PERMIT_DISTFILES_FTP= Yes
MASTER_SITES= ${HOMEPAGE}pub/
@@ -50,16 +50,21 @@ LDFLAGS+= -L${LOCALBASE}/lib -L${X11BASE
CONFIGURE_ENV+=CPPFLAGS="${CPPFLAGS}" LDFLAGS="${LDFLAGS}" \
PYTHON=${MODPY_BIN}
-WANTLIB-main= c m z freetype
+WANTLIB-main= c cairo expat fontconfig freetype glib-2.0 glitz \
+ gmodule-2.0 gobject-2.0 iconv intl m pcre pixman-1 z \
+ X11 Xau Xdmcp Xrender
+
LIB_DEPENDS-main= png::graphics/png \
- art_lgpl_2::graphics/libart
+ pango-1.0,pangoft2-1.0,pangocairo-1.0::devel/pango \
+ xml2::textproc/libxml
RUN_DEPENDS-main=
-WANTLIB-perl= m
+WANTLIB-perl=
LIB_DEPENDS-perl= rrd:rrdtool-${VERSION}:net/rrdtool
RUN_DEPENDS-perl=
LIB_DEPENDS-python=rrd:rrdtool-${VERSION}:net/rrdtool
RUN_DEPENDS-python=${MODPY_RUN_DEPENDS}
+MODPY_EGG_VERSION= 0.2.1
.include
Index: distinfo
===
RCS file: /cvs/ports/net/rrdtool/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- distinfo12 Sep 2007 14:34:36 - 1.9
+++ distinfo12 Dec 2008 02:33:58 -
@@ -1,5 +1,5 @@
-MD5 (rrdtool-1.2.23.tar.gz) = 2voWG8nGHldjamCFyHwf6A==
-RMD160 (rrdtool-1.2.23.tar.gz) = DBFHJCrfR29ek/TVm1U+4+o3iyM=
-SHA1 (rrdtool-1.2.23.tar.gz) = XaYQ4ci8AbgKvCGrnpjgBDY7Qpw=
-SHA256 (rrdtool-1.2.23.tar.gz) = Sx3wCyOnShyBc03SdOcuANi7KbEeHz0pOP+HaR7OHw8=
-SIZE (rrdtool-1.2.23.tar.gz) = 1061530
+MD5 (rrdtool-1.3.4.tar.gz) = fbO//D87JOgoqI/gIWUmbw==
+RMD160 (rrdtool-1.3.4.tar.gz) = FD6wYojU2zIUSZlD75d0OoGaS5k=
+SHA1 (rrdtool-1.3.4.tar.gz) = 1r+3AV2B23K8iAxqddgsoMI83Jw=
+SHA256 (rrdtool-1.3.4.tar.gz) = M+aNim2JBqXTttdiT8kYoMpJY3sSBIKhEY2U3lTYEW4=
+SIZE (rrdtool-1.3.4.tar.gz) = 1067603
Index: patches/patch-bindings_Makefile_in
===
RCS file: /cvs/ports/net/rrdtool/patches/patch-bindings_Makefile_in,v
retrieving revision 1.1
diff -u -p -r1.1 patch-bindings_Makefile_in
--- patches/patch-bindings_Makefile_in 12 Sep 2007 14:34:36 - 1.1
+++ patches/patch-bindings_Makefile_in 12 Dec 2008 02:33:58 -
@@ -1,12 +1,11 @@
-$OpenBSD: patch-bindings_Makefile_in,v 1.1 2007/09/12 14:34:36 msf Exp $
bindings/Makefile.in.orig Wed May 2 19:06:59 2007
-+++ bindings/Makefile.in Tue Sep 11 14:31:11 2007
-@@ -550,7 +550,7 @@ ruby:
+--- bindings/Makefile.in.orig Sat Oct 4 17:04:16 2008
bindings/Makefile.in Thu Dec 11 23:33:07 2008
+@@ -617,7 +617,7 @@ ruby:
# rules for buildung the pyton module
python:
-- cd python && env LIBDIR=../../src/.libs $(PYTHON) setup.py build
-+ cd python && env LIBDIR=../../src/.libs INCDIR=../../src $(PYTHON)
setup.py build
+- cd python && env BUILDLIBDIR=../../src/.libs $(PYTHON) setup.py
build_ext --rpath=$(libdir) && env LIBDIR=../../src/.libs $(PYTHON) setup.py
build
++ cd python && env BUILDLIBDIR=../../src/.libs INCDIR=../../src $(PYTHON)
setup.py build_ext --rpath=$(libdir) && env LIBDIR=../../src/.libs $(PYTHON)
setup.py build
# rules for building the perl module
perl_piped: perl-piped/Makefile
Index: patches/patch-doc_Makefile_in
cups-enable
wondering why things stopped working after an upgrade, it took me a little while to remember that lpr was overwritten. but then it took a while longer to find cups-enable, even after I remembered that I needed to run it, because it's not cupsenable, which is the only one that shows up when I type cups[tab]. I spent a good amount of time trying to find a program with a name just like cupsenable but that wasn't cupsenable. Why is cups-enable installed only runnable by root? It's harder to find this way. And why can't a normal user even read it? It already checks that you're root before doing anything, and we have tons of things that aren't useful to users but are still runnable. It's also not mentioned by pkg_info as something of interest. It should be, right? While on the subject, the lpd.pre-cups test is a little broken. I had my old lpd backed up (pre-upgrade). Now the 4.4 tools are gone, and the backups are from 4.3 or whenever.
Re: sndio for esound
On Thu, Dec 11, 2008 at 08:44:10PM +, Jacob Meuser wrote:
>
> please test ... and notice how much simpler this is than what it
> replaces, even though esound prefers to use a fd for audio access.
new version based on some feedback.
esd closes down stderr and stdout before starting the audio backend,
so you might not see some messages from errors in the backend.
for example:
$ esd -r 11025 -b
- server format: sample rate = 11025 Hz
- server format: 8 bit samples
but in fact, it is running at 16 bit 48 kHz, because the device does not
support 8-bit or 11025 Hz.
I patched out the closing of file descriptors in my tests but took
out that patch for submission here, because I really don't know why
esd was doing that.
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: Makefile
===
RCS file: /home2/cvs/OpenBSD/ports/audio/esound/Makefile,v
retrieving revision 1.44
diff -u -r1.44 Makefile
--- Makefile31 Mar 2008 01:05:54 - 1.44
+++ Makefile12 Dec 2008 04:46:39 -
@@ -4,7 +4,7 @@
COMMENT= sound library for Enlightenment
DISTNAME= esound-0.2.38
-PKGNAME= ${DISTNAME}v0
+PKGNAME= ${DISTNAME}p0v0
SHARED_LIBS += esd 2.40 # .2.38
CATEGORIES=audio
MASTER_SITES= ${MASTER_SITE_GNOME:=sources/esound/0.2/}
@@ -18,7 +18,7 @@
PERMIT_PACKAGE_FTP=Yes
PERMIT_DISTFILES_CDROM=Yes
PERMIT_DISTFILES_FTP= Yes
-WANTLIB= c m wrap
+WANTLIB= c m sndio wrap
FLAVORS= arts
FLAVOR?=
@@ -47,7 +47,7 @@
esdconfdir=${PREFIX}/share/examples/esound
post-extract:
- @cp -f ${FILESDIR}/audio_sun.c ${WRKSRC}
+ @cp -f ${FILESDIR}/audio_sndio.c ${WRKSRC}
pre-configure:
@perl -pi -e 's|_LOCALBASE_|${LOCALBASE}|' \
Index: files/audio_sndio.c
===
RCS file: files/audio_sndio.c
diff -N files/audio_sndio.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/audio_sndio.c 12 Dec 2008 04:46:39 -
@@ -0,0 +1,134 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2008 Jacob Meuser
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "config.h"
+
+#include
+
+struct sio_hdl *hdl = NULL;
+
+#define ARCH_esd_audio_close
+void esd_audio_close()
+{
+if (hdl != NULL) {
+sio_close(hdl);
+hdl = NULL;
+}
+}
+
+#define ARCH_esd_audio_open
+int esd_audio_open()
+{
+char *device;
+struct sio_par par;
+int mode = SIO_PLAY;
+
+if (hdl != NULL) {
+fprintf(stderr, "sndio already opened\n");
+return(1);
+}
+
+sio_initpar(&par);
+
+if ((esd_audio_format & ESD_MASK_FUNC) == ESD_RECORD)
+mode |= SIO_REC;
+
+device = esd_audio_device ? esd_audio_device : getenv("AUDIODEVICE");
+if ((hdl = sio_open(device, mode, 0)) == NULL) {
+fprintf(stderr, "sio_open failed\n");
+goto bad;
+}
+
+par.le = (BYTE_ORDER == 4321) ? 0 : 1;
+if ((esd_audio_format & ESD_MASK_BITS) == ESD_BITS16) {
+par.bits = 16;
+par.sig = 1;
+} else {
+par.bits = 8;
+par.sig = 0;
+}
+
+par.pchan = (((esd_audio_format & ESD_MASK_CHAN) == ESD_STEREO) ? 2 : 1);
+if (mode & SIO_REC)
+par.rchan = par.pchan;
+
+par.bufsz = ESD_BUF_SIZE;
+
+par.rate = esd_audio_rate;
+
+if (!sio_setpar(hdl, &par)) {
+fprintf(stderr, "sio_setpar failed\n");
+goto bad;
+}
+
+if (!sio_getpar(hdl, &par)) {
+fprintf(stderr, "sio_getpar failed\n");
+goto bad;
+}
+
+/* check that the actual parameters are what we asked for */
+if (fabs(par.rate - esd_audio_rate) > esd_audio_rate * 0.05) {
+fprintf(stderr, "Unsupported rate: %i Hz\n", esd_audio_rate);
+goto bad;
+}
+if ((esd_audio_format & ESD_MASK_BITS) == ESD_BITS16) {
+if (par.sig != 1 || par.bits != 16) {
+fprintf(stderr, "Unsupported bits: 16\n");
+goto bad;
+}
+} else {
+if (par.sig != 0 || par.bits != 8) {
+fprintf(stderr, "Unsupported bits: 8\n");
+goto bad;
+}
+}
+if ((esd_audio_format & ESD_MASK_CHAN) == ESD_STEREO) {
+
Re: cups-enable
On Fri, Dec 12, 2008 at 12:00:21AM -0500, Ted Unangst wrote: > wondering why things stopped working after an upgrade, it took me a > little while to remember that lpr was overwritten. but then it took a > while longer to find cups-enable, even after I remembered that I > needed to run it, because it's not cupsenable, which is the only one > that shows up when I type cups[tab]. I spent a good amount of time > trying to find a program with a name just like cupsenable but that > wasn't cupsenable. pkg_info -L cups | grep enable > Why is cups-enable installed only runnable by root? It's harder to > find this way. And why can't a normal user even read it? It already > checks that you're root before doing anything, and we have tons of > things that aren't useful to users but are still runnable. good point. > It's also not mentioned by pkg_info as something of interest. It > should be, right? pkg_info -M cups this message is also displayed when cups is installed. > While on the subject, the lpd.pre-cups test is a little broken. I had > my old lpd backed up (pre-upgrade). Now the 4.4 tools are gone, and > the backups are from 4.3 or whenever. well, it's been like that for close to 4 years now. anyway, how will the script know if the backed-up files are from a previous release? should the backups use `uname -r` in their names? or if it finds a backed-up file, should it ask again if you're sure you want to continue? -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: cups-enable
On Fri, Dec 12, 2008 at 05:33:17AM +, Jacob Meuser wrote: > On Fri, Dec 12, 2008 at 12:00:21AM -0500, Ted Unangst wrote: > > While on the subject, the lpd.pre-cups test is a little broken. I had > > my old lpd backed up (pre-upgrade). Now the 4.4 tools are gone, and > > the backups are from 4.3 or whenever. > > well, it's been like that for close to 4 years now. http://marc.info?l=openbsd-ports&m=104153716826223&w=2 for a bit of history on how this script came to be. only searched because I vaguely remembered that discussion. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: UPDATE: net/rrdtool
Stuart Henderson wrote: On 2008/12/12 01:46, Stuart Henderson wrote: On 2008/12/12 09:31, Dongsheng Song wrote: Is anyone work for RRDtool 1.3.4 ? i'll probably look at it in a day or two. ..or sooner. Really lightly tested in standalone use on amd64 only so far. Definitely needs much testing in other places and with the bindings. Those using it in a chrooted environment will have "a couple" more libraries to copy in... Index: Makefile [...] Hi! Do you plan to completely replace the 1.2 branch in the ports tree with the 1.3? Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: cups-enable
* Ted Unangst wrote: > wondering why things stopped working after an upgrade, it took me a > little while to remember that lpr was overwritten. but then it took a > while longer to find cups-enable, even after I remembered that I > needed to run it, because it's not cupsenable, which is the only one > that shows up when I type cups[tab]. I spent a good amount of time > trying to find a program with a name just like cupsenable but that > wasn't cupsenable. > > Why is cups-enable installed only runnable by root? It's harder to > find this way. And why can't a normal user even read it? It already > checks that you're root before doing anything, and we have tons of > things that aren't useful to users but are still runnable. > > It's also not mentioned by pkg_info as something of interest. It > should be, right? Your are wrong. When you install CUPS, a message is displayed. That message can be redisplayed at any time using 'pkg_info -M cups'. > While on the subject, the lpd.pre-cups test is a little broken. I had > my old lpd backed up (pre-upgrade). Now the 4.4 tools are gone, and > the backups are from 4.3 or whenever. -- Marc Balmer, Micro Systems, Wiesendamm 2a, Postfach, CH-4019 Basel, Switzerland http://www.msys.ch/ http://www.vnode.ch/ "In God we trust, in C we code."
Re: Help in compiling gtk2mm
On Thu, 11 Dec 2008, STeve Andre' wrote: >After a lot of scrounging around I could use some help in getting > gtk2mm to compile. I've rebuilt my package builder and I'm > having problems with gtk2mm (and gcc 4.2 but thats seperate). > >It doesn't compile regardless of other installed packages, or > standalone with nothing pre-installed. > >This is a -current system, compiled on Dec 8th, but this has > been a problem since around the gtk+2 update. This is a known issue. We warned about this at the time of gtk+2 update. A fix is ready but needs wider testing. Talk to landry@ for the gory details. Cheers! -- Antoine
