www/checkbot needs default setting to home directory

[Sid]

When running www/checkbot, it must be run from the home directory, because 
that's the directory it writes in.

This is the error, when running this program from a non-writable directory
 /usr/local/bin/checkbot: Unable to open checkbot.html.new for writing:

It works when from the home or other writable directory.

Can the default setting be set to use the user's home directory.

Thank you
___
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: propose games-text category

[Sid]

We need another category, for interpreters, game engines, maybe game servers, 
game server queries, and other utilities that aren't the whole game, or that 
require the original game. Perhaps, games-utils. dMagetic requires an original 
game, as does scummvm for many popular games. 

The games category is crowded, and it makes sense to have a full category for 
games-text. Let games-text be a secondary category for game components that are 
also mainly game utilities. Eventually games-utils will need a full category of 
its own.

These directly below are for starting on games-utils, not games-text.

% psearch -c games interpreter
dMagnetic   Magnetic Scrolls Interpreter
easyrpg-player  RPG Maker 2000/2003 and EasyRPG games interpreter
frotz   Infocom Z-machine games interpreter
instead Simple Text Adventure, The Interpreter
jzipText-mode Infocom game interpreter
ponscripter-sekai   NScripter-like novel-game interpreter with Unicode support
sarien  Sierra AGI games interpreter
scare   ADRIFT-compatible interactive games interpreter
scummvm Interpreter for several adventure games
tadsTADS compiler/interpreter for interactive fiction
xinfocomInfocom game interpreter for X11
xzipInfocom game interpreter that runs under X11
zoomZ-Interpreter for X with full V6 support

games/freera requires the original cd. But alternatively openra is an 
opensource version of this that doesn't require a original cd.

% psearch -c games server
bzflag-server   Multiplayer 3D tank battle game (server only)
cgoban  Internet Go Server client and game editor
cockatrice  Virtual tabletop client and server for multiplayer card 
games
doomDOOM: the game and the sound server
hedgewars-serverServer part of free Worms-like turn based strategy game
ioquake3-server Ioquake3 dedicated server
jin Graphical client for chess servers
linux-etqw-demo-server Enemy Territory: QUAKE Wars Demo Server for Linux
linux-etqw-server   Enemy Territory: QUAKE Wars Server for Linux
maitretarot Server side of MaitreTarot, a Tarot card game
manaplusFree open source 2D MMORPG client for athena and evol 
servers
masterserverMasterserver for IdSoftware games (D3, EF, H2, Q2, Q3, QW)
minecraft-serverDedicated server for the game Minecraft
mtaserver   Multi Theft Auto: Vice City and GTA3 dedicated server
mvdsv   Enhanced QuakeWorld server with multi-view demos capability
netwalk Game where the object is to connect every terminal to the 
main server
odamex  Client/server multiplayer engine for Doom
openarena-serverQuake3 total conversion based on the ioquake3 engine
qstat   Command-line program to query game servers on the net
quaqut  Queries information from Unreal Tournament 2004 game servers
r1q2
sampsvr 
wmqstat 
xboard  
xboard-devel
xpilot  
xpilot-ng-server
games/xqf 
net/hlmaster  
net/nyancat   

% psearch -c games engine
devel/flatzebra   Generic game engine for 2D double-buffering animation
devel/godot   Game runtime engine
devel/godot2  
devel/loveOpen-source 2D game engine
devel/love07  
devel/love08  
devel/love10  Open-source 2D game engine (legacy version 0.10)
devel/love5   
emulators/cannonball  Enhanced OutRun Engine
games/OpenTombOpen-source Tomb Raider 1-5 engine remake
games/abuse_sdl   SDL port of the Abuse game engine
games/adonthell   Role playing game engine

games/ags Adventure Game Studio Engine
games/alephone-scenarios  Free scenarios for the Aleph One engine
games/aquaria Underwater 2D fantasy action-adventure (game engine)
games/cakeQuake3 map viewer (and powerful 3D game engine)
games/chocolate-doom  Doom/Heretic/Hexen/Strife engine port compatible with 
the originals
games/darkplaces  Quake engine modification
games/devilutionX Diablo I engine for modern operating systems
games/doom-hacx   Full TC using the Doom II engine
games/edgeDOOM style engine aimed at the Total Conversion 
developer
games/egl Enhanced OpenGL-only Quake II engine
games/exult   Ultima VII engine
games/fairymaxChess engine for shatranj, courier chess, and others
games/flare-engineFree Libre Action Roleplaying Engine
games/flare-game  Free Libre Action Roleplaying Engine: game data
games/freedinkMetaport for FreeDink engine and data
games/freedink-engine Dink Smallwood RPG and RPG Construction Set
games/freedroidrpgModification of the classical 

propose games-text category

[Sid]

Propose to split games category to an additional category for games that can be 
played on the command line console without a window manager. Perhaps, it can be 
named games-text, games-terminal or games-cli. It would include curses games, 
ascii games and basic command line games.


These below are in the current games category. The headers are the search term.

2048

ascii:
0verkill
ascii-invaders (also a curses games)
asciiquarium
cowsay
cursive
linux-dwarffortress
tractorgen

curses:
yahtzee
tornado
tbclock
ski
npush
cryptoslam
seabattle

ncurses:
alienware
aop
bastet
cavezofphear
ninvaders
nsnake
xtgyoretsu
ztrack

console:
ctris
tetrinet

text:
block
bsdtris
dungeon
eif
eights
enygma
freesweep
greed
lexter
nonsense
oldrunner
rfksay
sex
textmaze

bsd:
bsdgames
coffeebreak

terminal:
freesweep
lexter
textmaze
tt
tty-solitaire
vitetris
py-cbeams

japanese:
today

tty:
slashem-tty

type:
sl

determine:
evilfinder

rubygem:
rubygem-vimgolf
rubygem-lolcat
rubygem-fortune_gem

p5:
p5-Games-AlphaBeta
p5-Games-Bingo
p5-Games-Dice

Cross posted in freebsd-games.

Thank you.
___
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: www/weblint error message

[Sid]

This solution works well. Thank you.

> > The port is an absolute mess. Not the least of its problems is the
> > fact that it's a perl script that doesn't depend on perl. newgetopt.pl
> > hasn't been distributed with perl for more than 7 years. It also uses
> > find.pl which also hasn't been included in many years. Upstream for it
> > has disappeared, and it should really just be removed.
>
> I removed it. It's too busted to even fix. I'd suggest using
> p5-HTML-Lint instead. Thanks for reporting this, Sid.
>
> # 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: www/weblint error message

[Sid]

Thanks,

Here's the line:
  ($., 'expected-attribute', $id) unless defined %args;

After removing "defined" or "unless defined %args", this is the error message 
when running weblint:
  Can't locate newgetopt.pl in @INC (@INC contains: 
/usr/local/lib/perl5/site_perl/mach/5.28 /usr/local/lib/perl5/site_perl 
/usr/local/lib/perl5/5.28/mach /usr/local/lib/perl5/5.28) at 
/usr/local/bin/weblint line 510.

Adding "SITECUSTOMIZE" to the perl5.28 (make config) configuration option 
didn't make a difference. www/weblint's file(s) will have to be updated.

> Saturday, July 20, 2019 at 3:35 PM:
>
> On Sat, Jul 20, 2019 at 1:35 PM:
> >
> > On trying to run www/weblint, I got this error message:
> >
> >  Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at 
> > /usr/local/bin/weblint line 846.
> >
> > It's worked on a previous compile. I'm not sure if this is a bug or if I 
> > need to configure something. Thank you.
>
> Perl no longer supports defined(%hash). Instead of
>   if defined(%hash)
> it should be
>   if (%hash)
>
> # Adam
>
>
> --
> Adam Weinberger
> ad...@adamw.org
> https://www.adamw.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"

www/weblint error message

[Sid]

On trying to run www/weblint, I got this error message:

 Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at 
/usr/local/bin/weblint line 846.

It's worked on a previous compile. I'm not sure if this is a bug or if I need 
to configure something. Thank you.
___
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: Electrum connection error

[Sid]

It works now. Thank you so much.

> > Unfortunately the most recent update of devel/py-aiorpcX to 0.18.0
> > broke finance/electrum. It's even listed in the requirements:
> >
> > $ grep aiorpcx \
> > work-py36/Electrum-3.3.5/contrib/requirements/requirements.txt
> > aiorpcx>=0.17,<0.18
> >
> > A diff between aiorpcx 0.17.0 and 0.18.0 shows that there was quite a
> > churn that can't be easily fixed.
> >
> > For now I've downgraded devel/py-aiorpcX to 0.17.0,1 and bumped the
> > electrum port.
> >
> > Updating the ports tree and updating the two ports manually will solve
> > the issue until the package builders have caught up.
>
> Thank you.
>
> Now I have this error after updating and completely reinstalling electrum:
>
> Traceback (most recent call last):
>   File "/usr/local/bin/electrum", line 321, in 
> config_options['cwd'] = os.getcwd()
> FileNotFoundError: [Errno 2] No such file or directory
___
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: Electrum connection error

[Sid]

> Unfortunately the most recent update of devel/py-aiorpcX to 0.18.0
> broke finance/electrum. It's even listed in the requirements:
>
> $ grep aiorpcx \
>   work-py36/Electrum-3.3.5/contrib/requirements/requirements.txt
> aiorpcx>=0.17,<0.18
>
> A diff between aiorpcx 0.17.0 and 0.18.0 shows that there was quite a
> churn that can't be easily fixed.
>
> For now I've downgraded devel/py-aiorpcX to 0.17.0,1 and bumped the
> electrum port.
>
> Updating the ports tree and updating the two ports manually will solve
> the issue until the package builders have caught up.

Thank you.

Now I have this error after updating and completely reinstalling electrum:

Traceback (most recent call last):
  File "/usr/local/bin/electrum", line 321, in 
config_options['cwd'] = os.getcwd()
FileNotFoundError: [Errno 2] No such file or directory

[1]Exit 1electrum


___
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"

Electrum connection error

[Sid]

Hi,

I get the following error when running finance/electrum from the command line,

 E/i | interface.[this Internet address changes:50004] | Exception in 
wrapper_func: AttributeError("module 'aiorpcx' has no attribute 'Connector'",)
 Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/electrum/util.py", line 908, in 
wrapper
return await func(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/electrum/interface.py", line 
306, in wrapper_func
return await func(self, *args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/electrum/interface.py", line 
321, in run
ssl_context = await self._get_ssl_context()
  File "/usr/local/lib/python3.6/site-packages/electrum/interface.py", line 
289, in _get_ssl_context
await self._try_saving_ssl_cert_for_first_time(ca_sslc)
  File "/usr/local/lib/python3.6/site-packages/electrum/interface.py", line 
246, in _try_saving_ssl_cert_for_first_time
ca_signed = await self.is_server_ca_signed(ca_ssl_context)
  File "/usr/local/lib/python3.6/site-packages/electrum/interface.py", line 
236, in is_server_ca_signed
await self.open_session(ca_ssl_context, exit_early=True)
  File "/usr/local/lib/python3.6/site-packages/electrum/interface.py", line 
412, in open_session
async with aiorpcx.Connector(NotificationSession,
 AttributeError: module 'aiorpcx' has no attribute 'Connector'


In the Makefile, this may possibly be related:

 # Supports 3.4+ but aiorpcX is 3.6+
 USES=   python:3.6+

This package is py36-electrum-3.3.5 on FreeBSD12.0 RELENG. Electrum runs, but 
it won't connect to a server. I got this error after building Electrum from 
ports. Later, I installed everything fresh from packages and got this same 
error, and still after rebuilding ports.

I sent this to freebsd-ports and to the maintainer. Thank you.
___
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: Suggestion to split games category into games-console, games-engine and games

[Sid]

> Sent: Monday, April 22, 2019 at 11:05 PM
> Subject: Re: Suggestion to split games category into games-console, 
> games-engine and games
>
> Apr 21, 2019:
> > Something like:
> > REFUSE x11 irc games cad finance
> 
> Thank you! I’ve been asking for this for literally YEARS. Probably since 
> FreeBSD 4 days...
>

You're welcome.
___
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: Suggestion to split games category into games-console, games-engine and games

[Sid]

Hi,
You can remove categories by using the REFUSE argument in /etc/portsnap.conf . 
See the manpage for portsnap.conf. Then obviously, run portsnap.
For other ports or package management tools, I don't remember clearly if or how 
you can do this.

Something like:
REFUSE x11 irc games cad finance

You can extract a fresh ports tree, but it's not required. Also consider, that 
some ports may be missing to build ports you've set, but that's likely to be a 
rare or an insignificant problem.

> Sent: Saturday, April 20, 2019 at 3:49 PM
> From: "@lbutlr" 
> To: FreeBSD 
> Subject: Re: Suggestion to split games category into games-console, 
> games-engine and games

> > /usr/ports/games is already very large.
> > What about splitting up games in the ports tree into games, games-console 
> > and games-engine?
>
> What about a configure file or option to exclude certain branches of the 
> ports tree os I don't have to keep downloading updates to packages I will 
> never run?
>
> For example, I have no need of any of the languages, X11-*, irc, games, cad, 
> or finance on my mail server.
___
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"

Suggestion to split games category into games-console, games-engine and games

[Sid]

/usr/ports/games is already very large.
What about splitting up games in the ports tree into games, games-console and 
games-engine?

This way, games will be categorized by those that can be used without an 
x-window system, through CLI, ncurses or similar.
2d graphical games don't need to be separated from 3d games, because there is 
much overlap.
Game engines aren't out of the box games, and there are game engines spread out 
in devel, games, misc, net and net-p2p that can go in the same category. Maybe 
splitting in games-engine would require more discussion, because there are more 
type of graphics engines.

(I cross-posted this in games and ports)

Thank you
___
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: License and adopting software

[Sid]

I think we should consider gradually using the Clear BSD license whenever 
someone decides to make an alternate, where a GPL licensed code was inserted on 
top of less restrictive licenses.
___
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: License and adopting software

[Sid]

> 'someone else said something to the effect of  "If I looked at the code 
> already, the license is already contaminated"'
That makes no sense to me. That advice seems counterproductive. In the source 
code, I'm sure you saw this, but there are different licenses in the files.
 
Usually, when someone adds on top of FreeBSD's license, that part belongs (or 
is at least dual/multi-licensed) in FreeBSD.
 
The only separator I understand is, the files, to have their distinctive 
licenses, to differentiate it from the rest of the packaged source code, but 
first distinguish it as your creation, copyright and license. I don't know if a 
line within a file can have a different license, unless that line was already 
established as MIT, or the creator releasing that line to GPL.
 
The odd part is, if a code goes into GPL, they get to license it. But if those 
lines are already MIT, that code is multi-licensed under both MIT and GPL. If 
code goes into a GPL code first, and the author didn't claim it as their own 
first, it's odd, (that code will be for GPL, but) I don't know if you can use 
that code for outside of GPL, even if you wrote it. I don't know about that, 
but it's safer to claim that code as your own, your project's or your 
pseudonym, before writing it into a GPL code to fix it. I wish there was 
someone who can clarify that.

I guess you're trying to find out or audit if everything within a code is GPL? 
That may be hard. I would start a new file, with your own license, informally 
copyright your creation with simple copyright text and license (not through the 
office: use the copyright office for your best or proprietary work), then maybe 
merge it afterwards. There is better advice on protecting your contribution's 
license, and how they interact. Some of that can be found by looking around, 
but it would be nice if someone who is really familiar with that would tell 
what they can.
___
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]

That Makefile becomes simple. It put pulseaudio options and gstreamer1 options 
from audio/libcanberra-gtk3 into libcanberra. All gtk references from 
audio/libcanberra were removed, only after references to gtk3 in 
libcanberra-gtk3 were removed.

That being said. I haven't tried using both original libcanberra and 
libcanberra-gtk3 with removing all gtk references from both. I haven't tested 
this yet, but gtk3 from libcanberra can only be disabled, if gtk references 
from libcanberra-gtk3 are removed. (This was accomplished in the Makefile I 
sent, but that was in one file, instead of two.)

"
do-build:
cd ${WRKSRC} && ${GMAKE} libcanberra-gtk3.pc
cd ${WRKSRC}/src && ${GMAKE} libcanberra-gtk3.la
cd ${WRKSRC}/src && ${GMAKE} libcanberra-gtk3-module.la

do-install:
${INSTALL_DATA} ${WRKSRC}/libcanberra-gtk3.pc \
${STAGEDIR}${PREFIX}/libdata/pkgconfig/
.for i in .so .so.0 .so.0.1.9
${INSTALL_LIB} ${WRKSRC}/src/.libs/libcanberra-gtk3${i} \
${STAGEDIR}${PREFIX}/lib/
.endfor
cd ${WRKSRC}/src && env DESTDIR=${STAGEDIR} ${GMAKE} 
install-gtk3moduleLTLIBRARIES
${LN} -sf libcanberra-gtk3-module.so \

${STAGEDIR}${PREFIX}/lib/gtk-3.0/modules/libcanberra-gtk-module.so
"
This part in libcanberra-gtk3 forces libcanberra to conditionally enable gtk3. 
As you can see, the Makefiles enable various libraries from the source code. 
pulseaudio and gstreamer can build without gtk3.

>> On Mon, Dec 25, 2017 at 5:45 AM, Sid  wrote:

>> > blubee blubeeme; Sun Dec 24 06:31:00 UTC 2017
>>
>> > If you wrote that makefile that removes all the gtk stuff, you can either
>> > try to get it to Marcus and see if he's
>> > willing to use that.
>>
>> > If you'd like me to work on the OSS audio portion, drop me that Makefile
>> > and I'll look at it in a bit.
>>
>> This one just uses libcaberra/Makefile, and removes the inclusion of
>> libcanberra-gtk3/Makefile, which requires gtk3. It takes the options for
>> gstreamer1 and pulseaudio and includes them from this file. gtk2 and gtk3
>> references were removed.
>>
>> Now more ports that ask for libcanberra-gtk3 require it. I haven't tested
>> removing references to pkg and sourcecode of libcanberra-gtk from those
>> ports' source code. It would be better to have a drop in replacement.
>>
>> It depends on what the Makefile is instructed to build to get basic
>> libcanberra.so. Optionally, gstreamer1 and pulseaudio can be split into its
>> own port as libcanberra-plugins.
>>
>> Here's my Makefile -->
>> ..

>Thanks for the makefile, I'll set it up in a jail and work on it.
You're welcome. Thanks for testing it out.
>I'll ping you here when I have something interesting to share.
___
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]

> blubee blubeeme; Sun Dec 24 06:31:00 UTC 2017

> If you wrote that makefile that removes all the gtk stuff, you can either
> try to get it to Marcus and see if he's
> willing to use that.

> If you'd like me to work on the OSS audio portion, drop me that Makefile
> and I'll look at it in a bit.

This one just uses libcaberra/Makefile, and removes the inclusion of 
libcanberra-gtk3/Makefile, which requires gtk3. It takes the options for 
gstreamer1 and pulseaudio and includes them from this file. gtk2 and gtk3 
references were removed.

Now more ports that ask for libcanberra-gtk3 require it. I haven't tested 
removing references to pkg and sourcecode of libcanberra-gtk from those ports' 
source code. It would be better to have a drop in replacement.

It depends on what the Makefile is instructed to build to get basic 
libcanberra.so. Optionally, gstreamer1 and pulseaudio can be split into its own 
port as libcanberra-plugins.
 
Here's my Makefile -->

# Created by: Joe Marcus Clarke 
# $FreeBSD: head/audio/libcanberra/Makefile 428129 2016-12-08 15:38:24Z tijl $
#   $MCom: ports/trunk/audio/libcanberra/Makefile 20031 2014-11-02 21:47:55Z 
kwm $

PORTNAME=   libcanberra
PKGNAMESUFFIX=  -lite
PORTVERSION=0.30
PORTREVISION=   4
CATEGORIES= audio devel
MASTER_SITES=   http://0pointer.de/lennart/projects/libcanberra/ \

http://pkgs.fedoraproject.org/repo/pkgs/libcanberra/libcanberra-0.30.tar.xz/34cb7e4430afaf6f447c4ebdb9b42072/

MAINTAINER= gn...@freebsd.org
COMMENT=Implementation of the Freedesktop sound theme spec

CONFLICTS=  libcanberra

LICENSE=LGPL21
LICENSE_FILE=   ${WRKSRC}/LGPL

LIB_DEPENDS=libvorbisfile.so:audio/libvorbis \
libltdl.so:devel/libltdl

USES=   gmake libtool pathfix pkgconfig tar:xz
USE_GNOME=  gnomeprefix
USE_LDCONFIG=   yes
GNU_CONFIGURE=  yes
CONFIGURE_ARGS= --disable-lynx --disable-tdb --disable-alsa --disable-gtk3 
--disable-gtk2
CPPFLAGS+=  -I${LOCALBASE}/include
LDFLAGS+=   -L${LOCALBASE}/lib
INSTALL_TARGET= install-strip

OPTIONS_DEFINE= PULSEAUDIO GSTREAMER

PLIST_SUB=  VERSION=${PORTVERSION}

.include 

.if ${PORT_OPTIONS:MPULSEAUDIO}
LIB_DEPENDS+=   libpulse.so:audio/pulseaudio
PLIST_SUB+= PULSE=""
.else
CONFIGURE_ARGS+=--disable-pulse
PLIST_SUB+= PULSE="@comment "
.endif

.if ${PORT_OPTIONS:MGSTREAMER}
USE_GSTREAMER1= yes
PLIST_SUB+= GSTREAMER=""
.else
CONFIGURE_ARGS+=--disable-gstreamer
PLIST_SUB+= GSTREAMER="@comment "
.endif


post-patch:
@${REINPLACE_CMD} -e 's|-Wmissing-include-dirs||g' \
${WRKSRC}/configure

.include 
___
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: License and adopting software

[Sid]

If the author doesn't respond, it's best to move on. Either use their GPL, or 
completely rewrite it, to avoid infringing on their work. It should be in it's 
own separate files, so it doesn't get absorbed into that other work's more 
restrictive license, before it is its own work. You'll need to look more into 
that.

Their copyright of the work is what you have to avoid, which is allowed for use 
by its respective license variant: GPL, LGPL, BSD, ISC, Apache, MIT, etc.

These publications help with what constitutes general and software copyright, 
to avoid infringing on developers' licensed copyrights.
https://www.copyright.gov/circs/circ01.pdf - Copyright Basics
https://www.copyright.gov/circs/circ33.pdf - Works not Protected by Copyright
https://www.copyright.gov/circs/circ61.pdf - Copyright Registration of Computer 
Programs
There are other organizing bodies on copyright, that will convey useful 
information too.

"The copyright law does not protect the func-
tional aspects of a computer program, such as the program’s 
algorithms, formatting, functions, logic, or system design."

An "ad minima" such as adding obvious words and minimum content like "an" or 
"the" also don't account for copyright protection. Lists and facts don't 
account for copyright.
I don't really understand, if the section "Derivative Computer Programs" in 
circ61 is referring to an author's own work, or others' works. This is worth 
investigating.

The core FreeBSD was rewritten from scratch, as in completely different code 
that accomplished the objective of removed code. It's like the difference 
between a car, shoes, a motorcycle, a bicycle, a scooter, a train, and a dolly 
for function of transport, that most have the inclusion of the common public 
domain wheel.

I'm not familiar with code. But when there's a story, set of facts, other 
ideas, or other information, there are many ways to write about it, without 
infringing on a copyright. There are many summaries, or book reports that don't 
infringe on the author's work, but they all accomplish the task of depicting 
that work. Drawings are a little different: freehand drawing still violates a 
copyright of the original work, even if the end result looks fundamentally 
different than the photo it is from.

I hope this clears up some ideas about licenses, and their relation to what is 
covered by softwares' respective copyrights.
___
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

[Sid]

OSS soundcard.h for FreeBSD stable and current
https://svn.freebsd.org/base/stable/11/sys/sys/
https://svn.freebsd.org/base/head/sys/sys/

blubee blubeeme; Mon Dec 11 17:03:10 UTC 2017
> I'm taking a look at soundcard.h in /usr/include/sys/soundcard.h in FreeBSD
> vs the soundcard.h in the offical OSS 4.01
> https://sourceforge.net/p/opensound/git/ci/master/tree/include/soundcard.h

> It seems like there's been a lot of changes between FreeBSD 3.8ish version
> and the 4.0 version.

> I was grepping around to see if any other files included this soundcard.h
> header and if updating to the latest would break any other programs.
___
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]

> Blubee Blubeeme;
> Who thought that was a good idea, now layer a few more audio layers and u 
> have Linux[ism] to the max.
> Well, I think that it's not really worth it to go untangle that mess.
> It's okay if you're using a Gnome DE since it's all in there already but just 
> to play
a sound file you have to bring in all of this nonsense.
> If you want to keep going down the Gnome hole, go ahead let me know when you 
> get
to the OSS specific issues, if any.
> There's a lot more pressing issues that affect a larger surface area than a 
> DE.
> Best

You're right, it's a rabbit hole. Whenever something starts to get untangled, 
it changes and becomes more tangled again.

I made a personal Makefile for a light install of libcanberra that doesn't use 
gtk at all. It worked, but more ports now require gtk3 for graphics for some 
reason. libcanberra-gtk libraries and its package are now called specifically 
from the sourcecode.

An elegant short term solution is to set make.conf to not install pulseaudio 
and gstreamer1 for audio/libcanberra-gtk3:  
audio_libcanberra-gtk3_UNSET=PULSEAUDIO GSTREAMER. This accomplishes the same 
outcome, without the extra Makefile, and tedious extra work.

This made me wonder, that I can create a Makefile for distfile/sourcecode of 
gstreamer1 and audio/pulseaudio to extract the most used libraries, to avoid 
more compilation of those dependencies. The full port and the partial port may 
not necessarily conflict, because the extracted library should be similar 
enough to the one in the full install, but if it does, then CONFLICTS= only 
allows 1 of those ports. I can then file a bug report of this, if it works.


Back to a drop in replacement:

libcanberra uses audio/libvorbis which has its own API. libvorbis will do for 
.oga files. Wav files may need more work, or simply the .wav files will have to 
be filed as bugs to be converted into .oga files.

An important thing to know about libcanberra is, where the program calls it, 
and where it calls OSS and libvorbis. Calls to gstreamer1 and pulseaudio, 
perhaps via their library files, should go to the OSS API. Other than that, 
API's are another language to me.

Also, there has to be a way (perhaps like from make.conf) to make full 
substitutions of packages and libraries. As long as the program that calls it 
doesn't make drastic changes that affect it.

>> Sid;
>> Sooner or later, a drop in replacement for libcanberra needs to be made for 
>> all BSD's. It should use ogg files from audio/freedesktop-sound-theme.
>> Canberra is meant only for sound (.oga, .wav), but graphical code is tied in 
>> heavily into it for XDG icons and graphics standards, so the problem is not 
>> just around gtk.
___
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]

> Blubee blubeeme
> I'll look at the libcanberra OSS backend and see if I get get the changes 
> upstream then the libcanberra maintainer can update the port.

>> Sid
>> Sooner or later, a drop in replacement for libcanberra needs to be made for 
>> all BSD's. It should use ogg files from audio/freedesktop-sound-theme. 
>> Perhaps it can include simple pipe to play ogg and other audio files as 
>> well. After investigating, libcanberra is suitable for the short term, and 
>> anything that fails without libcanberra-gtk3 is an issue with the upstream 
>> ports themselves.


I looked into it more. Canberra is meant only for sound (.oga, .wav), but 
graphical code is tied in heavily into it for XDG icons and graphics standards, 
so the problem is not just around gtk.

The source code of libcanberra has many graphical files and lines, and its only 
binary /usr/local/bin/canberra-gtk-play (--file) requires the window display 
(which shouldn't be needed for sound, and no graphical interface), so it can't 
run from a root console (onto a non-root desktop).

Icons and programs that need Canberra should just call it. Canberra has the 
ability to output a command, if for instance, the sound application fails. This 
should be output back to another program.

libcanberra needs to fork, to have only audio components (to not rely on any 
graphical toolkit), but it is required for it to keep the same GPL license. 
I'll keep looking at it, and take notes on that. Then see if I can compile it, 
leaving out graphical components (I'm C code illiterate). Later on, it can be 
replaced completely by an OSS API of original code.

While no FreeBSD ports currently use pulseaudio and gstreamer for libcanberra, 
that compatibility should stay in (as opposed to what I suggested previously).
___
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

[Sid]

blubee blubeeme; Mon Dec 11 17:03:10 UTC 2017
> I'm taking a look at soundcard.h in /usr/include/sys/soundcard.h in FreeBSD
> vs the soundcard.h in the offical OSS 4.01
> https://sourceforge.net/p/opensound/git/ci/master/tree/include/soundcard.h

> It seems like there's been a lot of changes between FreeBSD 3.8ish version
> and the 4.0 version.

> I was grepping around to see if any other files included this soundcard.h
> header and if updating to the latest would break any other programs.

Can you find OSS version 4.1 or 4.2 in https://svn.freebsd.org/base/ for head/ 
or stable/?

___
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: Vote: making wayland=on default

[Sid]

Wayland should not be mixed in with other code like gtk3, gtk2, gnome related 
programs. This will immediately create bloat.

Wayland does remove a lot of unneeded obsolete code that is in Xorg, that is 
put in there by principle, and not much else. If gtk creeps into Wayland, those 
benefits will be lost.

The current eagerness about wanting Wayland is centered around gtk. This will 
quickly harm the project.

Wayland should work on top of xlibs that are not obsolete.

Wayland shouldn't be made the default until small window managers like antiwm, 
blackbox, bspwm, ctwm, cwm, i3, jwm, qtile, vtwm and others like this work on 
it. It should also work on fluxbox and enlightenment first. Wayland on FreeBSD 
shouldn't be centered around GNU, gtk or Gnome.

I would say make a Wayland-gtk package offshoot, but this will also quickly 
ruin things. Wayland should stay clean, and allow modular components on top of 
it, that don't spread out bloat dependencies out. Wayland should keep the same 
habit as Xorg, with the exception of keeping obsolete hardware code.
___
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]

> Blubee blubeeme
> I'll work on it but let me get the port in the tree first, then I can refine 
> it.
> Just as i've done with my previous ports.

> Sid
> a simple program that plays simple sounds like "Ding!"
> The problem with libcanberra is around pulseaudio and gstreamer. It is also 
> with how gtk, a Visual Graphical toolkit, is mixed in with an Audio 
> application.

I was inspecting libcanberra and libcanberra-gtk3.

audio/libcanberra-gtk3 takes care of canberra plugins for pulseaudio and 
gstreamer. It also takes care of two gtk3 library files, one of which is a 
module. Ports that really need gtk3 are tangled mostly upstream, and require 
--enable-gtk3. Others ports require libcanberra-gtk3 for either gtk3, 
pulseaudio or gstreamer. Some ports have audio/libcanberra-gtk3 as a 
dependency, but don't need it.

audio/libcanberra itself is not so bad. audio/libcanberra also works without 
gtk20 in the test Makefile, which shouldn't be needed at all. So, plain 
libcanberra without libcanberra-gtk3 is not complicated, because it doesn't 
involve gtk3, pulseaudio, and gstreamer; it has gtk2 as a dependency, which it 
doesn't need.


Sooner or later, a drop in replacement for libcanberra needs to be made for all 
BSD's. It should use ogg files from audio/freedesktop-sound-theme. Perhaps it 
can include simple pipe to play ogg and other audio files as well. After 
investigating, libcanberra is suitable for the short term, and anything that 
fails without libcanberra-gtk3 is an issue with the upstream ports themselves.
___
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: Vote: making wayland=on default

[Sid]

I would rather see smaller window managers work with Wayland first.
If gtk2 and gtk3 want to enable it fine. But gtk2 and gtk3 shouldn't be mixed 
in with Wayland by default, which is what will happen if it is enabled before 
it gets a foothold with other window managers.
___
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]

The problem with libcanberra is around pulseaudio and gstreamer. It is also 
with how gtk, a Visual Graphical toolkit, is mixed in with an Audio application.

I didn't say you didn't know about it, I was just putting it out there. They've 
done a good job of cleaning up and fixing ALSA to work on top of OSS: the most 
obvious problems with that are fixed. Pulseaudio hasn't been cleaned up, which 
it is better for applications to avoid it all together, and I don't know if 
Pulseaudio is worth fixing.

It is really a travesty that a simple program that plays simple sounds like 
"Ding!" has to be this complicated, when OSS, and sndio work, and even when 
something as complicated as ALSA was simplified enough to work efficiently on 
top of OSS.

"When devs take the easiest path..." This is the Linuxism route, to pile on. I 
don't even consider that the easiest path, a lazy path instead, considering its 
usual outcome, of requiring hours to compile something which should compile in 
5 minutes. FreeBSD and other BSD's have largely simplified many of these 
issues, recently.

> blubee blubeeme; Wed Dec 20 07:26:43 UTC 2017
> 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.

Sid; Wed Dec 20 07:04:08 UTC 2017

>> According to 
>> http://0pointer.de/lennart/projects/libcanberra/#status[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: 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: Canberra

[Sid]

> blubee blubeeme
> I am porting py-canberra which isn't required but an
> optional dependency for another port that I am working on.

> I wonder should I leave it as is or make a dependency from this thing
you're working on instead?

> blubee blubeeme
> py-canberra is just a python wrapper for libcanberra

Perhaps audio/libcanberra should be a dependency of devel/pycanberra. 
audio/libcanberra-gtk3 looks like it has options and requests for unnecessary 
dependencies.

> Sid
> Canberra is an audio application for playing simple sounds like "DING!".
> For playing sound, I am convinced that graphical dependencies for 
> audio/libcanberra and audio/libcanberra-gtk3 aren't needed: 
> x11-toolkits/gtk30, x11-toolkits/gtk20, accessibility/atk.
> According to Freshports, both libcanberra and libcanberra-gtk3 refer to the 
> file libcanberra-0.30.tar.xz of the same SHA256 and size.
> The difference between these two is one pulls in gtk3 as well.

libcanberra-gtk3 also has options for pulseaudio, and gstreamer. 

> Pango is for left to right text, perhaps for displaying audio information to 
> the user.
> Its description is its "code is platform- and toolkit-independent."
> For it to display a simple banner or visual it shouldn't require heavy 
> graphical dependencies.
> Also, Pango should be made into an option for Canberra, so it can definitely 
> be compiled without atk, gtk30 or gtk20.
> Pango doesn't require these three graphical dependencies, so Canberra 
> especially shouldn't.

> The port audio/freedesktop-sound-theme just has sound files, and no libraries.

pango and freedesktop-sound-themes should be options for libcanberra.

I'm convinced that gtk30, gtk20, atk, pulseaudio, and gstreamer shouldn't be 
options or required in libcanberra or libcanberra-gtk3. (pango and atk are not 
in the Makefiles, but Freshports shows them.)
libcanberra-gtk3 should be merged back into libcanberra. I've only tested 
removing all of these options for one port that asked for both canberra 
libraries, and it compiled and played sound.


Thank you.
___
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]

The port audio/freedesktop-sound-theme just has sound files, and no libraries.
___
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]

devel/pycanberra

audio/freedesktop-sound-theme hasn't been tested for most ports that ask for 
libcanberra, and I haven't tried it on any port yet either. The source for 
pycanberra may need patches to work with freedesktop-sound-theme. You could 
include both as options. If they conflict, you'll have to use OPTIONS_RADIO 
(single choice). In any case, libcanberra should drop gtk requirements, but 
they may be reluctant to do so. pycanberra's name implies it's for libcanberra.

IMO, it's better to clean up as many ports before flavors comes along, because 
then, there will be more excuses to not remove bloat.

blubee blubeeme; Tue Dec 19 03:01:07 UTC 2017
> quick question, I am porting py-canberra which isn't required but an optional 
> dependency for another port that I am working on.
> ibus-cangjie.
 
> The ibus-cangjie port needs py-gobject anyways; so a whole lot of gtk stuff 
> gets pulled in.
> I wonder should I leave it as is or make a dependency from this thing you're 
> working on instead?
 
> I was waiting for @flavors to calm down before I started working on the port 
> again.

>> Canberra is an audio application for playing simple sounds like "DING!".
>> For playing sound, I am convinced that graphical dependencies for 
>> audio/libcanberra and audio/libcanberra-gtk3 aren't needed: 
>> x11-toolkits/gtk30, x11-toolkits/gtk20, accessibility/atk.
>> According to Freshports, both libcanberra and libcanberra-gtk3 refer to the 
>> file libcanberra-0.30.tar.xz of the same SHA256 and size.
>> The difference between these two is one pulls in gtk3 as well.

>> Pango is for left to right text, perhaps for displaying audio information to 
>> the user.
>> Its description is its "code is platform- and toolkit-independent."
>> For it to display a simple banner or visual it shouldn't require heavy 
>> graphical dependencies.
>> Also, Pango should be made into an option for Canberra, so it can definitely 
>> be compiled without atk, gtk30 or gtk20.
>> Pango doesn't require these three graphical dependencies, so Canberra 
>> especially shouldn't.
>> USE_GNOME should also be a Makefile option in ports that are only about 
>> sound (libraries, applications, audio server components) and not graphics.

>> libcanberra and libcanberra-gtk3 should be replaced with 
>> audio/freedesktop-sound-theme.
>> Pango appears to be a different implementation of Bango, which is not in 
>> ports, but here: 
>> https://www.freedesktop.org/wiki/Bango/[https://www.freedesktop.org/wiki/Bango/].
___
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]

>Sid; Mon Dec 18 22:09:36 UTC 2017
> Canberra is an audio application for playing simple sounds like "DING!".
> For playing sound, I am convinced that graphical dependencies for 
> audio/libcanberra and audio/libcanberra-gtk3 aren't needed: 
> x11-toolkits/gtk30, x11-toolkits/gtk20, accessibility/atk.
> According to Freshports, both libcanberra and libcanberra-gtk3 refer to the 
> file libcanberra-0.30.tar.xz of the same SHA256 and size.
> The difference between these two is one pulls in gtk3 as well.

> Pango is for left to right text, perhaps for displaying audio information to 
> the user.
> Its description is its "code is platform- and toolkit-independent."
> For it to display a simple banner or visual it shouldn't require heavy 
> graphical dependencies.
> Also, Pango should be made into an option for Canberra, so it can definitely 
> be compiled without atk, gtk30 or gtk20.
> Pango doesn't require these three graphical dependencies, so Canberra 
> especially shouldn't.
> USE_GNOME should also be a Makefile option in ports that are only about sound 
> (libraries, applications, audio server components) and not graphics.

libcanberra and libcanberra-gtk3 should be replaced with 
audio/freedesktop-sound-theme.
Pango appears to be a different implementation of Bango, which is not in ports, 
but here: https://www.freedesktop.org/wiki/Bango/.
___
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"

Canberra

[Sid]

Canberra is an audio application for playing simple sounds like "DING!". For 
playing sound, I am convinced that graphical dependencies for audio/libcanberra 
and audio/libcanberra-gtk3 aren't needed: x11-toolkits/gtk30, 
x11-toolkits/gtk20, accessibility/atk. According to Freshports, both 
libcanberra and libcanberra-gtk3 refer to the file libcanberra-0.30.tar.xz of 
the same SHA256 and size. The difference between these two is one pulls in gtk3 
as well.

Pango is for left to right text, perhaps for displaying audio information to 
the user. Its description is its "code is platform- and toolkit-independent." 
For it to display a simple banner or visual it shouldn't require heavy 
graphical dependencies. Also, Pango should be made into an option for Canberra, 
so it can definitely be compiled without atk, gtk30 or gtk20. Pango doesn't 
require these three graphical dependencies, so Canberra especially shouldn't. 
USE_GNOME should also be a Makefile option in ports that are only about sound 
(libraries, applications, audio server components) and not graphics.
___
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

[Sid]

>> Stefan Esser; Sun Dec 17 13:11:22 UTC 2017
>> Do you propose to just update the code to what 4Front provides?

>> This may work for you as individual user, but the 4Front license makes
>> it impossible to commit that version to FreeBSD. (That was the reason
>> to stay at a reasonably licensed version, very long ago.)

>> Or do you propose a clean-room implementation that in the end is fully
>> compatible with 4Front OSS 4.x, but does not violate their license and
>> intellectual property rights?

>> You are welcome to start with such a clean-room implementation and it
>> may even be accepted into FreeBSD, once you are ready (provided there
>> really is no risk of legal problems in any part of the world).

> blubee blubeeme; Sun Dec 17 13:57:40 UTC 2017
> This is not true. The source code is distributed under different license
> based on the OS.
> Look at audio/oss src build process.

> If the code is compiled on Linux it has some Linux type gpl license, if
> it's on a *BSD it has BSD license, there's also license that suits other
> platforms as well.

> There were some closed sourced parts because Hannu was trying different
> license models to pay the bills but instead of supporting him, everyone
> forked his code and left so he went on to do something else.

http://developer.opensound.com/opensource_oss/licensing.html
It says most of it is available under a FreeBSD license, but there are parts of 
it, that are closed sourced.
I'm not sure if any of the closed sourced code is in that download.
If any closed sourced or GPL code is it in, it would have to be forked it to 
github, sourceforge or other repository, to include only FreeBSD licensed code.

> blubee blubeeme; Sun Dec 17 13:57:40 UTC 2017
> I propose properly implementing 4Font OSS 4.x in the FreeBSD kernel,
> properly using the API as documented on 4Front website.
> Have 4Front OSS the default audio system in FreeBSD

> Having proper Audio programming guide in the FreeBSD handbook
> ditch sndio and all that other stuff and move forward with a clean start
> and proper documentation for new audio programs.

If 4Font OSS 4.x comes along, sndio's and portaudio's servers should be 
stripped down, to work on top of, and not duplicate OSS's server 
implementation, so the API of many programs that already use it, readily will. 
I also wish there were a FreeBSD patch for ALSA and other Linuxism API's to 
just connect directly to OSS or Sndio's server. Canberra's (computer sounds 
output) API especially needs to drop directly to OSS's sound server. The reason 
parts of sndio and portaudio should stay available, is that they've done a lot 
of work this year to fix most ports to work with sndio, and keeping 
compatibility with these two, will make porting easier from other BSDs, 
including GNU programs that already got ported to other BSDs.
___
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

[Sid]

I've had a few misconceptions.

Bluebee Blubeeme said, 4Front has a modern OSS implementation that is under a 
FreeBSD license.

The model of Sound on FreeBSD is, three layers:
1. The API, where programs use libraries (of respective sound architecture) to 
access the sound server.
2. The sound server: OSS, Sndio, Portaudio, JACK, ALSA, native, etc
3. FreeBSD's base is always OSS (OpenBSD's driver is sndio); sound servers 
connect to and use this.

To use 4Front's OSS, FreeBSD's kernel will have to be recompiled without OSS, 
"snd" and "sound" references, and then that version of OSS installed.

The part of OSS in name, that is a mess, is the API structure, and various 
implementations. In FreeBSD for instance, when a program uses an OSS API, I 
hear that developers, need to write so many patches, because different OSS 
frontends are not standardized. Most applications in ports use Sndio, because 
across BSD's the API to it is standard. Bluebee claims that 4Front's OSS is 
standard as well. As for API on programs/ports, just use the FreeBSD API that 
is available for it, OSS, Sndio, Portaudio, to connect to that sound server.

As long as OSS covers the wide range of implementations of it, OSS In Name, 
without clarifiers, will carry this burden of being complex and having a 
nonstandard API, even when certain implementations don't or may not have this 
issue.

Bluebee says, to my understanding, that 4Front's OSS doesn't have certain 
coding inefficiencies that certain sound architectures have. That is something 
for the developers to be informed about, and to consider in FreeBSD current.
___
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

[Sid]

>> Sid; Fri Dec 15 23:05:47 UTC 2017
>> It's not that FreeBSD is limiting features, it is more that, OSS is a 
>> cluster of complexities,
>> when it is brought to FreeBSD, it is cleaned up, trimmed, and made efficient 
>> for this OS.

> blubee blubeeme; Sat Dec 16 01:40:13 UTC 2017
> This is where the issue lies, FreeBSD's oss "compatible" implementation did 
> some things that went against the design of oss4 and re-introduced and will 
> see that bad audio > programming habits are carried forward into the future.
> This makes it hard to find and fix the root cause of the problems but instead 
> of doing that, people just keep on creating new audio infrastructure.
 
> Why?

"there are so many different OSS implementations, not all of them compatible. 
Even Linux before 2.4 had an OSS implementation until it got replaced with 
ALSA. Sndio is standardized, it's the same on all BSDs. Because it's the same 
for all BSDs it's easier for an application programmer to use it and not have 
to make dozens of exceptions in the code." 
https://forums.freebsd.org/threads/60852/

This is an answer, but I supposed that OSS being an unstandardized tangled 
cluster of code is not the answer you're looking for.

If http://opensound.com/ is the 4Front you're talking about, it is simply their 
oss license agreement, 
https://sourceforge.net/p/opensound/git/ci/master/tree/EULA, which is not 
compatible with a BSD or any opensource license, which is enough for FreeBSD 
not to include it in the base. Aside from it not being incompatible, FreeBSD 
would get sued for using it in their base, because that license says it can 
only be used by each person on one computer at a time, and can't be 
redistributed. As I've mentioned before, many projects took OSS, made it into 
their own, forked it and the licenses. They can take those forks, but once they 
change to a restrictive license, it can't come back here. Again, OSS has many 
implementations which are a cluster of tangled sourcecode and licenses.

If you need details on why developers made decisions on how they programmed it, 
or what they got from it, then they'll have to chime in.

Use sndio or portaudio for MIDI whenever available instead. In most cases, 
developers will have to install that frontend into music programs.
___
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

[Sid]

> Yuri; Fri Dec 15 20:22:24 UTC 2017
> Jack isn't needed in theory, but OSS drivers for many popular sound 
> devices don't support midi. PCI audio devices generally don't support 
> midi, only USB ones do. So if you want midi, you have to go with 
> soft-midi (ex. Jack+fluidsynth).

> Jack is a very powerful audio server, though a bit buggy.

sndiod covers MIDI hardware, which is installed by audio/sndio
Now I get it, I think she is looking for MIDI, and driver capabilities for 
physical hardware.

> Freddie Cash; Fri Dec 15 16:22:36 UTC 2017
​> FreeBSD has had the ability to play sounds from multiple programs
> simultaneously since the 4.x days.  Back then, the kernel developed a
> "virtual channels" layer to accommodate this (program X uses /dev/dsp0,
> program Y uses /dev/dsp1, program Z uses /dev/dsp2, audio is mixed and
> played out the speakers together).  Later this was done automatically by
> multiple programs simply accessing /dev/dsp.

This was my misconception. I think what happened is, the frontend/API for many 
programs from the
portstree got improved this year, when sndio was brought over allowing 
different programs
to access these drivers at once. It was easier for them to bring make those 
adjustments,
when it was fixed for that other operating system.

This is a description of sndio on FreeBSD.
https://forums.freebsd.org/threads/62892/#post-363265
https://forums.freebsd.org/threads/43417/#post-368500

From what I understand is, that OSS and Sndio have their drivers in the /dev/ 
directory,
and separately have a frontend or API to connect to user programs.
OSS hardware drivers are compiled into the kernel or started as modules.
Sndiod hardware drivers can also be turned on, to be seen in /dev/.

> blubee blubeeme;
> If you want to test for yourself, install audio/oss then run osstest and
> report back.

The program audio/oss is a frontend. FreeBSD by default uses OSS hardware 
drivers,
as that's what most sound devices in /dev/ are. To use a newer OSS 
backend/hardware driver,
you'd have to get updated source if available, and recompile your kernel.

It's not that FreeBSD is limiting features, it is more that, OSS is a cluster 
of complexities,
when it is brought to FreeBSD, it is cleaned up, trimmed, and made efficient 
for this OS.

Different frontends/API's (ALSA, JACK, PULSEAUDIO, OSS, SNDIO, native APIs) 
just work together
on top of FreeBSD's native OSS hardware driver.
___
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: Re: OSS Audio

[Sid]

That's good that Jack isn't needed.
It appears, as of the last few months or year, OSS is able to play sounds from 
different programs simultaneously.

What about physical input jacks for mic and line in?
  # cat /dev/sndstat
  installed devices
  pcm0:  (play/rec) default
  pcm1:  (play/rec)
  pcm2:  (play)
  pcm3:  (play)
  pcm4:  (play)
One cluster of physical inputs/outputs can be chosen, but using more than one 
set of inputs isn't always necessary.

There are different implementations of OSS, because it has been often forked or 
added into various projects, including under less permissive licenses, still 
under the OSS name, to many times become cluttered. This is common for a 
project of a permissive license to be taken in by various projects, such as 
ALSA, that use GPL or even proprietary licenses. Most forked OSS versions are 
made to suit or work under other sound architectures, applications or an OS's 
purposes, not necessarily making them better. I realize that FreeBSD's version 
of OSS is not depreciated, is fairly efficient, and is functional as it is what 
FreeBSD uses as /dev/sndstat. For the sound frontend, it depends on what the 
port/program has available from OSS, SNDIO or portaudio, to play on FreeBSD's 
OSS backend.

 
> blubee blubeeme gurenchan at gmail.com - Fri Dec 15 07:49:28 UTC 2017

>> If I can provide OSS audio/midi input and output for the tools that I use,
>> then I can do all the routing natively with OSS.

> There's nothing in FreeBSD that makes the sound architecture only support 1 
> audio device.
> These were issues with earlier versions of OSS implementation; please 
> remember the days of rebooting your system to get new devices to show up.
 
> All those issues have been sorted out in OSS 4.0 and above.
 
> OSS API is like working with file descriptors;

> The open() system call
> The close() system call
> The read() system call
> The write() system call
> The ioctl() system call
> The select() and poll() system calls
> The mmap() system call
 
 
> Jack audio is NOT necessary, I already ported amsynth over to FreeBSD, they 
> had a very old implementation of OSS backend for midi that just worked with 
> my midi keyboard.
> I spoke to the developer and he also updated his code to the newest version 
> of OSS, here's some code: 
> https://github.com/amsynth/amsynth/commit/7171bd4d945c5938442b80f4276b7e096f06a3a0#diff-0b31b8315cadf5e7556f54a245817f90[https://github.com/amsynth/amsynth/commit/7171bd4d945c5938442b80f4276b7e096f06a3a0#diff-0b31b8315cadf5e7556f54a245817f90]
 
> There's a lot of misinfo out there about OSS being depreciated or dead, 
> that's not the case.
> From looking at what's available OSS is one of the most straight forward and 
> stable Audio API's out there.
 
> If you want to test for yourself, install audio/oss then run osstest and 
> report back.
 
> There's ALSA plugins for OSS that would provide better audio vs the way 
> things are implemented right now.
___
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: Re: OSS Audio

[Sid]

> blubee blubeeme - Tue Dec 5 00:48:05 UTC 2017

> If I can provide OSS audio/midi input and output for the tools that I use,
> then I can do all the routing natively with OSS.

A problem with this is FreeBSD's backend sound architecture allows one device 
input or output at a time.
cat /dev/sndstat shows this, which I believe is OSS. There is sndio's backend 
sndiod (from OpenBSD) that can alternatively be enabled, but I hear the volume 
on it is too low, and I'm not sure if it allows multiple devices. sndiod's 
backend can be enabled by service sndiod start: it is in /usr/local/etc/rc.d/.
___
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

[Sid]

> blubee blubeeme - Tue Dec 5 00:48:05 UTC 2017

> If I can provide OSS audio/midi input and output for the tools that I use,
> then I can do all the routing natively with OSS.

I glossed over this in my response.
___
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

[Sid]

> I prefer simplicity over complexity,
All ports and packages should be built with audio/sndio and audio/portaudio 
(not pulseaudio) as default for the front end to the FreeBSD's native OSS 
backend.

> I want the best possible audio for my system. I work with synthesizers and
> audio programs a lot and on Linux for pro audio everyone recommended using
> Jack sound server, which was always a pain to maintain, keep connections
> between sessions, etc...

> After learning more about audio, I realized that Jack only complicated
> things and OSS can do what jack without needing the additional complexity
> of Jack server.

> If I can provide OSS audio/midi input and output for the tools that I use,
> then I can do all the routing natively with OSS.

I thought Jack was a necessity for MIDI instruments and professional music 
production. If you say OSS can do it, then that's great.
sndio, and sometimes portaudio, is often required as a frontend, in order to 
replace ALSA and other complicated sound architectures.

> I ran osstest on my system and I was shocked how great my
> sound system is
This is what they commonly say about SNDIO and PORTAUDIO over FreeBSD's native 
version (/driver) of OSS.
___
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"

Tendra compiler

[Sid]

Hi,
I'm not sure if this is the right place to post this. I realize that the Tendra 
compiler is depreciated.

On FreshPorts, it says the website is no longer, but at least now it's now at 
http://www.tendra.org/ with a BSD style license.

Thank you
___
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: gentoo's package.provided equivalent?

[Sid --]

The FreeBSD Forums will be the place to search and ask for additional help to 
do that.

>> Sometimes i need to build specific version of some library from source,
>> not from ports. How can I tell port system about it. There was no problem
>> with old pkg_, because I was able just to put dummy directory into
>> /var/db/pkg and port system knows it is installed (although maybe that was
>> ugly hack). But what I can do with pkgng now? For example, Gentoo linux
>> has /etc/portage/profile/package.provided file for such a situation. Is
>> there some equivalent?

FreeBSD does have pkgng, but I'm not sure if it's the same thing.
Some versions of packages can be chosen, but I believe that ports versions can 
be chosen too.
The "Porter's Handbook", and "FreeBSD Handbook" may also provide assistance.
___
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"

net-im/libpurple grouping protocols in make config

[Sid --]

Hi.

Can someone adjust this for net-im/libpurple 's Makefile, the maintainers 
haven't responded yet.

44,46c44,45
< OPTIONS_DEFINE=   BONJOUR DBUS GNUTLS NSS SASL GSTREAMER VV IDN PERL 
TCLTK \
<   SAMETIME SILC GG IRC JABBER MSN MYSPACE NOVELL OSCAR QQ \
<   SIMPLE YAHOO ZEPHYR
---
> OPTIONS_DEFINE=   DBUS GNUTLS NSS SASL GSTREAMER VV IDN PERL TCLTK
> 
68a68,71
> OPTIONS_GROUP=PROTOCOLS
> OPTIONS_GROUP_PROTOCOLS= BONJOUR GG SAMETIME SILC IRC JABBER MSN MYSPACE \
>   NOVELL OSCAR QQ SIMPLE YAHOO ZEPHYR

The descriptions are already listed, and didn't need to be changed for this to 
work. It works the same, but the protocol options are moved into their own 
group, that can be seen when running make config. Bonjour acts like a protocol 
so I grouped it with the others. Thank you.
___
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"

conditional circular dependency found, curl, poppler, gvolwheel

[Sid --]

___
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