Date: Sun, 18 Sep 2011 17:21:01 +0200 From: Juergen Lock <nox@jelal.kn-bremen.de> To: bf1783@gmail.com Cc: freebsd-multimedia@FreeBSD.org, gerald@FreeBSD.org, Juergen Lock <nox@jelal.kn-bremen.de> Subject: Re: Has anyone tested the jack update - am I ok to commit it? Message-ID: <20110918152101.GA88715@triton8.kn-bremen.de> In-Reply-To: <CAGFTUwNMqpOcYLZCzbZ7tj5qqZF6UXm6zv-%2BH3ZxYNa9U9VQCA@mail.gmail.com> References: <CAGFTUwNMqpOcYLZCzbZ7tj5qqZF6UXm6zv-%2BH3ZxYNa9U9VQCA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 17, 2011 at 10:19:27PM -0400, b. f. wrote: > > This port is maintained by this list (multimedia@) so I thought > > I better ask once more before committing... :) The update is > > here: > > > > http://people.freebsd.org/~nox/tmp/jack-0.120.1.patch > > > > and I first mentioned it in this thread: > > > > http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-September/012432.html > > > > (Using a midi keyboard with FreeBSD (jack update, ardour3 alpha...)) > > While I understand you have already invested some time in testing > this, I don't think it would be wise to update only to 0.120.1 -- the > latest release is 0.121.2, and the release notes for 0.120.2 and > subsequent releases mention not only significant enhancements, but > some important bug-fixes, e.g.: > Ooops! I guess that's what I get for only checking the latest version number on the project homepage... I'll prepare an updated update. :) > "Fix issues with stack initialization in client threads that stole > large chunks of the stack from applications", > > "Fix memory overrun when calling jack_get_ports() with arguments that > lead it to return all existing ports", > > "Remove client->control->nframes data element and use > control->engine->buffer_size. This fixes erroneous behaviour when > trying to get the buffer size associated with JACK port type", > > ... > > Also, please consider merging the following changes in yours: > > -- clean up ugly flag handling > Can you elaborate? > -- make the building of the HTML documentation an OPTION, > off-by-default -- the doxygen dependency, which by default drags in > many Python, graphviz, TeX, and Qt4 dependencies, is too heavy a > burden for package builders and testers, and it was never a good idea > to require it in order to build a small audio server. (These changes > could be replaced by packaging the documents in a separate, > locally-mirrored tarball, or, provided that the port is kept > up-to-date, by downloading them from the master site.) Ok, making docs an OPTION should be easy. Thanx! Juergen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110918152101.GA88715>