Re: Xorg server update

[Walter Schwarzenfeld]

Seems on a long way:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Canberra

[blubee blubeeme]

On Wed, Dec 20, 2017 at 3:04 PM, Sid  wrote:

> According to http://0pointer.de/lennart/projects/libcanberra/#status
> updated September 2012
>
> "libcanberra is mostly feature complete. For now however it includes
> backends only for ALSA, PulseAudio, OSS and GStreamer."
>
> "The OSS driver is incomplete: only sound files that are in a format
> natively understood by the sound card are supported. If the sample type,
> channel map or sampling rate of the sound file are not supported by the
> sound card no automatic conversion will take place and the file will not be
> played. Also note that the OSS backend is most likely incompatible with
> OSS4, due to subtle incompatibilities between OSS4 and the OSS 3.x."
>
> "It is recommended to always take the "shortest" path from libcanberra to
> the audio device. I.e. don't use the GStreamer plugin if libcanberra
> supports the final output target natively. Besides being more
> resource-friendly and less error-prone, some advanced functionality might
> get lost with each layer you add to your stack. For example: while you
> could use libcanberra's Gstreamer backend to output to a PulseAudio server
> this will not be able to make use of sample cacheing or will be able to
> attach additional meta data to the sounds played, which might be necessary
> for effects like positional event sounds."
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>

@Sid
I know this.
These are just some of the reasons why I wanted to make sure that the OSS
in FreeBSD is actually up to snuff
because working on fixing issues like these the easiest route is; just use
ALSA or some such crap which is
unacceptable to me if it can use OSS.

When devs take the easiest path then instead of fixing the root issues,
problems are compounded;
just like the example you gave of layering pulse on top of gstreamer, those
"solutions" are brittle and will
inevitably break.

I'd like to have a solid foundation and build from there, not be constantly
trying to re-implement the wheel.

This is just one OPTIONAL dependency for a piece of software that I want to
port and this software isn't
even audio related, it's an ibus plugin.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Canberra

[Sid]

According to http://0pointer.de/lennart/projects/libcanberra/#status updated 
September 2012

"libcanberra is mostly feature complete. For now however it includes backends 
only for ALSA, PulseAudio, OSS and GStreamer."

"The OSS driver is incomplete: only sound files that are in a format natively 
understood by the sound card are supported. If the sample type, channel map or 
sampling rate of the sound file are not supported by the sound card no 
automatic conversion will take place and the file will not be played. Also note 
that the OSS backend is most likely incompatible with OSS4, due to subtle 
incompatibilities between OSS4 and the OSS 3.x."

"It is recommended to always take the "shortest" path from libcanberra to the 
audio device. I.e. don't use the GStreamer plugin if libcanberra supports the 
final output target natively. Besides being more resource-friendly and less 
error-prone, some advanced functionality might get lost with each layer you add 
to your stack. For example: while you could use libcanberra's Gstreamer backend 
to output to a PulseAudio server this will not be able to make use of sample 
cacheing or will be able to attach additional meta data to the sounds played, 
which might be necessary for effects like positional event sounds."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Eugene Grosbein]

On 20.12.2017 01:03, Matthias Andree wrote:

> Dear Ted, Eugene,

[skip]

What happened with old good "Tools, not policy" thing?


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Xorg server update

[emilia]

Hello there, some time ago i saw a patch mentioned on a FreeBSD mailing list to 
update the X11 server.
If I remember correclty it would automatically handle new device nodes in 
/dev/input/,
this would be a real cool feature because e.g wacom tablets that use webcamd 
could 'just work' without X11 configs needed.
Does anyone have some info what happend to the patch?


regards,
emilia
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: devel/R-cran-gsubfn: broken because of missing dependency

[Walter Schwarzenfeld]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224472

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

rpi2 V1.1 vs. hard coded max_execution_time figures in /usr/local/share/poudriere/common.sh (package; also: extract, install, deinstall)

[Mark Millard]

I tied building devel/llvm50 on a rpi2 V1.1 via poudriere
and it got as far as:

. . .
===
===>  Building package for llvm50-5.0.0_6
=>> Killing timed out build after 7200 seconds

This was for:

---Begin OPTIONS List---
===> The following configuration options are available for llvm50-5.0.0_6:
 CLANG=on: Build clang
 DOCS=on: Build and/or install documentation
 EXTRAS=on: Extra clang tools
 LIT=on: Install lit and FileCheck test tools
 LLD=on: Install lld, the LLVM linker
 LLDB=on: Install lldb, the LLVM debugger

But I had set in /usr/local/etc/poudriere.conf :

# This defines the max time (in seconds) that a command may run for a build
# before it is killed for taking too long. Default: 86400
#MAX_EXECUTION_TIME=86400
MAX_EXECUTION_TIME=432000
 
# This defines the time (in seconds) before a command is considered to
# be in a runaway state for having no output on stdout. Default: 7200
#NOHANG_TIME=7200
NOHANG_TIME=28800

The magic 7200 is from /usr/local/share/poudriere/common.sh :

package)
max_execution_time=7200
. . .

There is also a lack of control over:

extract)
max_execution_time=3600
. . .
install)
max_execution_time=3600
. . .
deinstall)
max_execution_time=3600
. . .

The rpi2 is now busy constructing a bsdtar when it
could have had a llvm50 package. (I wonder if the
bsdtar takes less time than the package would have
taken.)

As stands the only way to allow such large builds
on the rpi2 is to edit:

/usr/local/share/poudriere/common.sh

after each poudriere installation/update.

The following large things did manage to build
packages:

lang/gcc7
devel/cmake (indirect from selecting devel/llvm50)

(I avoid WITH_DEBUG for devel/llvm50 in all
environments: that build is massive, needing
between 24 GiBytes and 26 GiBytes for RAM+SWAP
on a powerpc64, if I remember right.)



Other than the hard coded max_execution_time
examples I've no found any fundmental problems
with using poudriere when configured as
indicated below. (Being willing to give it
the time it needed.)

For these experiments I've used:

NO_ZFS=yes
USE_TMPFS=no
PARALLEL_JOBS=1
ALLOW_MAKE_JOBS=yes
MAX_EXECUTION_TIME=432000
NOHANG_TIME=28800

For what I tried I've not had to
use MAKE_JOBS_NUMBER_LIMIT?= or
MAKE_JOBS_NUMBER?= . (Say, in
/usr/local/etc/poudriere.d/make.conf
testing the likes of
.if ${.CURDIR:M*/devel/llvm*}
code.)

The rpi2 has world, kernel, and its dtb
file via a USB SSD Stick, not from a
usdcard. The usdcard is very minimal
as far as its UFS / file system goes:

/etc/fstab (redirecting to the USB SSD)
/boot/* (with /boot/kernel/ empty and /boot/dtb/ empty)

The USB SSD stick has:

# df -m
Filesystem  1M-blocks  Used  Avail Capacity  Mounted on
/dev/da0p1 195378 31305 14844317%/
devfs   0 0  0   100%/dev

(/dev/da0p1 has a UFS file system.)

# swapinfo
Device  1K-blocks UsedAvail Capacity
/dev/da0p2157286416876  1555988 1%


===
Mark Millard
markmi at dsl-only.net

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FLAVOR for Qt4 and Qt5 (was Re: Flavor or not for this port?)

[L.Bartoletti]

Hi,

Here's my WIP

https://gitlab.com/lbartoletti/freebsd_ports/tree/master/qwt6

Regards


On 18.12.2017 22:57, L.Bartoletti wrote:

Hi Rainer,

I have made a try with subpackages with success, but I think it's 
better with flavor (like on OpenBSD).


So, I have started to create flavors for this port.

For now, I success for qt4 but not yet for qt5.

Extract from my Makefile in progress:

FLAVORS=    qt5 qt4
FLAVOR?=

.if ${FLAVOR:Mqt5}
PKGNAMESUFFIX=    -qt5
USE_QT5=    widgets gui core designer gui opengl svg xml buildtools 
printsupport concurrent

PLIST=        ${PKGDIR}/pkg-plist.qt5
PLIST_SUB+=    QT_MKSPECDIR=lib/qt5/mkspecs
DOCSDIR=    ${PREFIX}/share/doc/qwt6-qt5
.else
PKGNAMESUFFIX=    -qt4
USE_QT4=     corelib gui opengl svg xml moc_build
PLIST=        ${PKGDIR}/pkg-plist.qt4
PLIST_SUB+=    QT_MKSPECDIR=lib/qt4/mkspecs
DOCSDIR=    ${PREFIX}/share/doc/qwt6-qt4
.endif

Ther error for qt5:

qwt-qt5-6.1.3 can't be installed: different Qt versions specified via
USE_QT[4 5].

Regards.

On 17.12.2017 10:12, Rainer Hurling wrote:

Am 02.11.2017 um 07:41 schrieb Rainer Hurling:

Am 02.11.2017 um 07:13 schrieb L.Bartoletti:

Hi,

I want to take x11-toolkits/qwt{5,6}-*

Both are built for Qt4. I especially need qwt6 for Qt5. Since we have
flavors. Is it better to add a Qt5 flavor for Qwt6 or simply add a
x11-toolkits/qwt6-qt5 (like security/qtkeychain-qt{4,5} ?)

Thanks.

Regards.

Loïc


Hi Loïc,

Thanks for your dedication. I am very interested in a qwt6-qt5 port,
since it is needed for the upcoming version 3.0 of graphics/qgis :)

Sorry for my inexperience. In case of adding the qwt6-qt5 as a flavor,
should we expect any change or restriction in the way, it would be used
as a dependency of e.g. QGIS?

Thanks for any answer.

Best wishes,
Rainer

Hi Loïc,

Again about x11-toolkits/qwt{5,6}-*

Now, that we have our first real world experiences with FLAVORS, it
seems to be functional to use flavors in this context. Something like

x11-toolkits/qwt6@qt4
x11-toolkits/qwt6@qt5

A bit tricky could be, that USE_QT* are different in both cases:

USE_QT4= corelib gui opengl svg xml moc_build
USE_QT5= core gui opengl svg xml printsupport qmake_build widgets

What do you think?

Best wishes,
Rainer
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Ted Hatfield]

On Tue, 19 Dec 2017, Matthias Andree wrote:

Am 19.12.2017 um 01:30 schrieb Ted Hatfield:



On Mon, 18 Dec 2017, Matthias Andree wrote:


Am 18.12.2017 um 00:17 schrieb Dave Horsfall:

Doing my regular update, and...

    Upgrading procmail from 3.22_9 to 3.22_10...

Good grief; who's the masochist who volunteered to support this
obscure insecure and hitherto-unsupported scripting language?


https://svnweb.freebsd.org/ports?view=revision=455800

I'd agree we should pull the plug on the package. We'll be in for the
usual "but it works for me" screaming of the irresponsible people who
don't care (and most of them won't know that they need to write the
exception/error handling themselves in their .procmailrc recipes).

Sunpoet, can we mark the port as deprecated given that even the upstream
once said it should best be abolished? I can't find the reference now,
the procmail.org website displays "Site hosting in transit, information
will be back up shortly."



Dear Matthias,

As one of the "irresponsible" people who is still using procmail on
our systems and has built an number of scripts and customer
infrastructure around it I take exception to the term irresponsible. 
Perhaps the better word is overworked.  If I had the time to move to
dovecot/sieve or maildrop as a local delivery agent I would have done
so by now.

Ted Hatfield


Dear Ted, Eugene,

I think if the procmail language were a bit more "regular", someone
would have written converter scripts long ago by now.

Other than that, I find it hard to believe that people don't have time
for over x in [3; 17] years to migrate, which in many cases would in my
book be more a situation of "I don't want to..." rather than "I am
unable to...". I don't mean to judge your situation, just that to me it
looks a matter that you have not yet found it important enough to bother.

Given that the former maintainer asked OpenBSD to pull the plug on the
port already 37 months ago (see here
) after
findings from fuzzing, and now to see security updates to a defunct
upstream port, I don't think we should keep the port around for much
longer. The expiration I was proposing isn't "axe it out now", we would
not normally do that, and it's at the maintainer's (i. e. sunpoet@'s)
discretion what expiration date, if any, will be set.

But the question if we as downstream packagers/providers want to step in
for a package abolished by the upstream almost a generation ago, is one
that needs serious consideration. I wouldn't endorse that the project
waste time on decrepit ports for which decent alternatives exist.


Best,
Matthias



Matthias,

My response wasn't meant to disprove your argument.  There is a valid case 
behind dropping support for procmail and you are welcome to make that 
argument.


From my point of view (and I bet quite a few others) I've been using a 
software product provided by the port maintainers for quite a long time. 
During that time I've kept my software up to date and patched.  As far as 
I am concerned I've done my due dilligence.


If you want to make an argument against maintaining procmail I completely 
understand that.  I just don't think that denigrating others while making 
your argument is the way to go about it.



Ted Hatfield
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Matthias Andree]

Am 19.12.2017 um 01:30 schrieb Ted Hatfield:
>
>
> On Mon, 18 Dec 2017, Matthias Andree wrote:
>
>> Am 18.12.2017 um 00:17 schrieb Dave Horsfall:
>>> Doing my regular update, and...
>>>
>>>     Upgrading procmail from 3.22_9 to 3.22_10...
>>>
>>> Good grief; who's the masochist who volunteered to support this
>>> obscure insecure and hitherto-unsupported scripting language?
>>>
>> https://svnweb.freebsd.org/ports?view=revision=455800
>>
>> I'd agree we should pull the plug on the package. We'll be in for the
>> usual "but it works for me" screaming of the irresponsible people who
>> don't care (and most of them won't know that they need to write the
>> exception/error handling themselves in their .procmailrc recipes).
>>
>> Sunpoet, can we mark the port as deprecated given that even the upstream
>> once said it should best be abolished? I can't find the reference now,
>> the procmail.org website displays "Site hosting in transit, information
>> will be back up shortly."
>>
>
> Dear Matthias,
>
> As one of the "irresponsible" people who is still using procmail on
> our systems and has built an number of scripts and customer
> infrastructure around it I take exception to the term irresponsible. 
> Perhaps the better word is overworked.  If I had the time to move to
> dovecot/sieve or maildrop as a local delivery agent I would have done
> so by now.
>
> Ted Hatfield

Dear Ted, Eugene,

I think if the procmail language were a bit more "regular", someone
would have written converter scripts long ago by now.

Other than that, I find it hard to believe that people don't have time
for over x in [3; 17] years to migrate, which in many cases would in my
book be more a situation of "I don't want to..." rather than "I am
unable to...". I don't mean to judge your situation, just that to me it
looks a matter that you have not yet found it important enough to bother.

Given that the former maintainer asked OpenBSD to pull the plug on the
port already 37 months ago (see here
) after
findings from fuzzing, and now to see security updates to a defunct
upstream port, I don't think we should keep the port around for much
longer. The expiration I was proposing isn't "axe it out now", we would
not normally do that, and it's at the maintainer's (i. e. sunpoet@'s)
discretion what expiration date, if any, will be set.

But the question if we as downstream packagers/providers want to step in
for a package abolished by the upstream almost a generation ago, is one
that needs serious consideration. I wouldn't endorse that the project
waste time on decrepit ports for which decent alternatives exist.


Best,
Matthias



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: pkg flavors breaks "make run-depends-list"

[L.Bartoletti]

Thanks Stefan,

I will try it!

Regards

Loïc


On 19.12.2017 07:23, Stefan Esser wrote:

Am 18.12.17 um 23:34 schrieb lb:

Hi,

Is it possible to add the flavors into the name returned by build-depends-list?

An example:

Loic@FreeBSD:/usr/ports|⇒  make -C x11-toolkits/py-qt5-gui build-depends-list
FLAVOR=py36
/usr/ports/ports-mgmt/pkg
/usr/ports/lang/python36
/usr/ports/devel/py-sip
...

Should be /usr/ports/devel/py-sip@py36

I have already proposed the same (with patch), see

https://reviews.freebsd.org/D13535

You can download the patch for testing from:

https://reviews.freebsd.org/D13535?download=true

Regards, STefan
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Roger Marquis]

Can certainly sympathize depending on the threat model, but how is that
any different from Equifax' not having time to patch Struts or not
having time to change the oil in your car or to brush your teeth ...


That's a non-sequitur if I understand the response correctly.  Procmail IS
patched and I assume applied.  So yes mom, teeth are brushed.


Correct from a 'known risk only' perspective but isn't code that is a)
largely unauditable and b) hasn't been maintained for a long time
considered vulnerable regardless of published vulnerabilities?

Perhaps not unlike brushing your teeth only when the dentist finds a
cavity, it doesn't fundamentally change the risk model.

Roger

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Adam Vande More]

On Tue, Dec 19, 2017 at 10:47 AM, Roger Marquis  wrote:

> As one of the "irresponsible" people who is still using procmail on our
>> systems and has built an number of scripts and customer infrastructure
>> around it I take exception to the term irresponsible. Perhaps the better
>> word is overworked. If I had the time to move to dovecot/sieve or maildrop
>> as a local delivery agent I would have done so by now.
>>
>
> Can certainly sympathize depending on the threat model, but how is that
> any different from Equifax' not having time to patch Struts or not
> having time to change the oil in your car or to brush your teeth ...
>

That's a non-sequitur if I understand the response correctly.  Procmail IS
patched and I assume applied.  So yes mom, teeth are brushed.

https://svnweb.freebsd.org/ports/head/mail/procmail/files/patch-src-formisc.c?view=log

-- 
Adam
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Roger Marquis]

As one of the "irresponsible" people who is still using procmail on our
systems and has built an number of scripts and customer infrastructure
around it I take exception to the term irresponsible. Perhaps the better
word is overworked. If I had the time to move to dovecot/sieve or maildrop
as a local delivery agent I would have done so by now.


Can certainly sympathize depending on the threat model, but how is that
any different from Equifax' not having time to patch Struts or not
having time to change the oil in your car or to brush your teeth ...

Roger
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
astro/py-pyfits | 3.4 | 3.5
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail got updated!

[Christoph Moench-Tegeder]

## Matthias Andree (matthias.and...@gmx.de):

> Sunpoet, can we mark the port as deprecated given that even the upstream
> once said it should best be abolished? I can't find the reference now,

Here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769938#11
https://marc.info/?l=openbsd-ports=141634350915839=2

Regards,
Christoph

-- 
Spare Space
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: devel/R-cran-gsubfn: broken because of missing dependency

[Rainer Hurling]

Am 19.12.2017 um 08:21 schrieb Walter Schwarzenfeld:

Is in math/R the option tcl/tk=on?


Hi Walter,

I think, you are right.

pkg-fallout[1] seems to have problems with building devel/R-cran-gsubfn, 
because default setting for math/R option 'TCLTK' is disabled. This have 
to be enabled by default, if the build of devel/R-cran-gsubfn should 
work automatically.


Thanks for the pointer.

[1] http://svnweb.freebsd.org/changeset/ports/456684
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: OSS Audio

[Alexander Leidinger]

Quoting blubee blubeeme  (from Tue, 19 Dec 2017  
00:28:23 +0800):



there's the alsa-lib from audio/alsa-lib
there's https://sourceforge.net/p/opensound/git/ci/master/tree/lib/libsalsa/
from oss that wraps alsa code, would there be issues with any of that in
the kernel?


Yes there would be an issue. It doesn't belong into the kernel. It's  
an userland library. It belongs into the userland (where it is right  
now) = /usr/local/lib or /usr/lib.


And to answer the question which may come if it makes sense to include  
it into the FreeBSD basesystem (userland) instead of having it in the  
ports collection: right now (without any program in the FreeBSD base  
system) it doesn't make sense. If there is a program which makes use  
of alsa-lib which shall be imported into the FreeBSD basesystem (not  
discussing right now if such a program makes sense in the FreeBSD  
basesystem as we don't have an explicit example to look at), then it  
makes sense.


Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpA2fF9M8flf.pgp
Description: Digitale PGP-Signatur