Bug 222534 - Review Request: libsnack - Snack Sound Toolkit provides audio handling to tlc/tk or python
Review Request: libsnack - Snack Sound Toolkit provides audio handling to tlc...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Deji Akingunola
Fedora Package Reviews List
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2007-01-13 09:16 EST by Sander Hoentjen
Modified: 2008-01-19 20:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-19 20:11:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Sander Hoentjen 2007-01-13 09:16:28 EST
Spec URL: http://fedora.hoentjen.eu/libsnack/libsnack.spec
SRPM URL: http://fedora.hoentjen.eu/libsnack/libsnack-2.2.10-1.src.rpm
Description: The Snack Sound Toolkit is designed to be used with a scripting
language such as Tcl/Tk or Python. Using Snack you can create
powerful multi-platform audio applications with just a few lines
of code. Snack has commands for basic sound handling, e.g. sound
card and disk I/O. Snack also has primitives for sound
visualization, e.g. waveforms and spectrograms. It was developed
mainly to handle digital recordings of speech, but is just as
useful for general audio. Snack has also successfully been
applied to other one-dimensional signals.

This packages includes Ogg library.
Comment 1 Deji Akingunola 2007-01-13 09:48:09 EST
Package builds fine, but have minor issue;

- The Release field should have .%{?dist} tag  
Comment 2 Sander Hoentjen 2007-01-13 10:57:43 EST
added dist tag

Spec URL: http://fedora.hoentjen.eu/libsnack/libsnack.spec
SRPM URL: http://fedora.hoentjen.eu/libsnack/libsnack-2.2.10-2.src.rpm
Comment 3 Michael Schwendt 2007-01-13 11:54:23 EST
* doesn't build with RPM %optflags

* Python docs are included, python module is NOT. Package description
also mentions Python support.

* snacksphere docs are included, snacksphere is NOT. Trying to load it
fails. pkgIndex also lists snacksphere, although it's missing.

* licence is not included

* the "make test" suite fails here

* Tcl SIG - What are the usual naming guidelines for this?
The "snack" -> "libsnack" name is questionable.
Comment 4 Wart 2007-01-13 13:15:37 EST
(In reply to comment #3)
> * Tcl SIG - What are the usual naming guidelines for this?
> The "snack" -> "libsnack" name is questionable.

I don't think there is a Tcl SIG, but it might be nice to have one.  'snack'
would be a more appropriate name, since that's what upstream uses, and that's
what Tcl developers would likely expect it to be called.

I had considered packaging snack a few months ago, but noticed that it comes
with a mp3 decoder (generic/mkFormatMP3.c), which is unacceptible for Fedora. 
You'll have to regenerate the tarball to omit the mp3 decoding bits before it
can be accepted.
Comment 5 Michael Schwendt 2007-01-13 13:28:17 EST
Yes, browsing the rather large tarball is another thing to do.
I only had a first brief look because the package description as
quoted at the top of the ticket says

  This packages includes Ogg library.

which is confusing enough to suggest that possibly it ships an
included libogg or something like that. That made it worth taking
a look. The description (s/packages/package/) refers to libsnackogg.so
which wasn't obvious. ;)
Comment 6 Wart 2007-01-13 13:36:33 EST
This also doesn't build on x86_64.  The included patch to configure fixes the
search path for tclConfig.sh on 64-bit systems, but doesn't do the for tkConfig.sh.

(In reply to comment #5)
> which is confusing enough to suggest that possibly it ships an
> included libogg or something like that. That made it worth taking
> a look. The description (s/packages/package/) refers to libsnackogg.so
> which wasn't obvious. ;)

It does include 'SnackOgg.c', which has a suspicious header that reads:

 * THIS FILE IS PART OF THE OggVorbis SOFTWARE CODEC SOURCE CODE.   *

...and 2000 lines of Ogg manipulation code.  You might want to see if you can
omit this source file (rm it during %prep) and build against libogg/libvorbis
instead.
Comment 7 Wart 2007-01-13 13:42:40 EST
(In reply to comment #6)
> This also doesn't build on x86_64.  The included patch to configure fixes the
> search path for tclConfig.sh on 64-bit systems, but doesn't do the for
tkConfig.sh.

...it also needs 'BuildRequires: tk-devel'.
Comment 8 Sander Hoentjen 2007-01-13 13:59:02 EST
hmm, sorry for the bad shape.. i actually took this from somewhere else some
time ago, built it for my own use and *thought* i had checked it back then for
fedora like quality. Let me work on it a bit and you will hear from me again.
Comment 9 Michael Schwendt 2007-01-13 16:25:12 EST
> SnackOgg.c

*urks*  Additionally, it links against libogg.so.0, libvorbis.so.0,
and libvorbisenc.so.2,...

> generic/

Included are several files licenced by Microsoft with the terms
in the "BSD.txt" file. It requires that the file is included and
that a licence change (e.g. to the GPL) is indicated at the top
of each file to which the new licence applies. That is not the
case, hence the BSD.txt licence applies to the whole product. In
the README they write that the GPL is only for the included mp3
decoder, however that one may not be sold without prior written
consent by its author. Plus, other files, such as jkSynthesis.c
and sound.c, have a GPL header, so the entire release must be GPL.
Licence mess.
Comment 10 Jason Tibbitts 2007-06-25 16:11:55 EDT
Anything happening here?  It's been over five months since the last comment.
Comment 11 Sander Hoentjen 2007-06-25 16:35:25 EDT
after my last comment I tried to contact the author. I never got any response.
If upstream is dead, I think I can't package this, I don't have the required
knowledge to fix everything.
Comment 12 Jason Tibbitts 2008-01-19 20:11:33 EST
I guess we should just close this.  If upstream has come back to life, feel free
to reopen.

Note You need to log in before you can comment on or make changes to this bug.