Bug 72975 – dev-python/pyflac-0.0.4 (new package)

• Product: Gentoo Linux
• Status: VERIFIED WONTFIX

[Description Michael Owen 2004-11-30 15:32:08 UTC]

New ebuild for dev-python/pyflac. This is a simple python wrapper to interface with libflac. 

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




pyflac was created by David Collett, and posted to flac-dev here:
http://lists.xiph.org/pipermail/flac-dev/2004-August/001571.html

Very simple and trivial ebuild, tested only on x86.

[Comment 1 Michael Owen 2004-11-30 15:32:46 UTC]

Created attachment 45025 [details]
Proposed ebuild for pyflac-0.0.1

[Comment 2 Michael Owen 2004-11-30 15:39:53 UTC]

Comment on attachment 45025 [details]
Proposed ebuild for pyflac-0.0.1

changed attachment type to text/plain

[Comment 3 Carsten Lohrke (RETIRED) 2004-11-30 15:58:24 UTC]

invalid header ->
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3

proper eclass usage? if you like to dig into it :)

[Comment 4 Michael Owen 2004-11-30 16:24:45 UTC]

Created attachment 45027 [details]
Fixed (hopefully) ebuild

Wasn't paying attention when I created the first one, and left out the Header,
as well as had the package version hardcoded into the SRC_URI field. Corrected
those two oversights, and changed src_make to the proper src_compile. The
src_install section requires the manual process, as the Makefile doesn't
include a install directive.

[Comment 5 Chris Mayo 2004-12-19 10:10:30 UTC]

Created attachment 46355 [details]
Modified ebuild

Some suggested modifications to the ebuild:

1) The original SRC_URI doesn't seem to exist any more, the only one I (Google)
could find was a personal Debian page.

2) Dependencies: pyao is not required by pyflac (although it is used in some of
the examples). swig is not required at runtime.

3) Had strange compile failures involving distcc, so add -j1 to MAKEOPTS. (This
seems to do the trick - does it really?)

4) Remove the hardcoding of Python 2.3 to allow the ebuild to work with 2.4
etc. without modification.

5) Install the examples in the doc directory as well.

[Comment 6 d_m 2005-03-05 19:32:09 UTC]

It seems that someone else has taken over maintaining pyflac. I found this 0.0.2 version (which uses setup.py to install--a lot nicer!)

Here is an ebuild I had prepared for it, which I tried to merge with this current one. AFAIK this should do the trick (although header is still empty--not sure what should go there).

[Comment 7 d_m 2005-03-05 19:33:49 UTC]

Created attachment 52759 [details]
Modified ebuild for newer version of pyflac (improved install)

This was an ebuild I had prepared before finding this bug in bugzilla, and
which I modified to (potentially) fix some of the (potential) problems people
had with this one.

[Comment 8 Marcin Janczyk 2005-05-16 08:09:40 UTC]

Created attachment 59020 [details]
pyflac-0.0.3.ebuild

This is new version 0.0.3. Works for me.

[Comment 9 Marcin Janczyk 2005-05-16 08:43:14 UTC]

Sorry, I've checked once again and it has some problem with newest media-libs/flac-1.1.2-r1. With 1.1.1 it works.

[Comment 10 Jakub Moc (RETIRED) 2005-05-28 08:12:32 UTC]

*** Bug 94291 has been marked as a duplicate of this bug. ***

[Comment 11 Peter Hyman 2005-10-13 08:26:05 UTC]

http://sacredchao.net/~piman/software/pyflac-0.0.4.tar.gz contains a new
release. Even though the website has not been updated and still shows
pyflac-0.0.2 as current. HTH

[Comment 12 Chris Mayo 2005-10-13 10:09:38 UTC]

Created attachment 70577 [details]
pyflac-0.0.4.ebuild

N.B. needs flac 1.1.2 and tested with swig-1.3.21

[Comment 13 Peter Hyman 2005-10-13 10:26:33 UTC]

thx, will shake it out.

[Comment 14 Lukasz Strzygowski (RETIRED) 2006-01-29 04:12:59 UTC]

Reassigned to maintainer-wanted.

[Comment 15 Marcin Janczyk 2006-01-29 07:08:51 UTC]

It seems pyflac is unmaintained and nothing depends on it. The only app I know, Quodlibet, in newer versions (bug #101619) doesn't need it, too. So I think it could be closed?

[Comment 16 Jakub Moc (RETIRED) 2006-01-29 07:28:22 UTC]

Closing.

[Comment 17 Peter Hyman 2006-01-29 10:01:19 UTC]

(In reply to comment #15)
> It seems pyflac is unmaintained and nothing depends on it. The only app I know,
> Quodlibet, in newer versions (bug #101619) doesn't need it, too. So I think it
> could be closed?
> 

Actually, this is incorrect. MusicBox, a Rox application uses pyflac when available to play flac files. This is the problem. It is not a dependency. It's an option. So, any python-based music player may use pyflac, but does not require it to be built or run. I think this project has value, takes little space, and is worth injecting into the tree. As for unmaintained, that is not quite accurate. pyflac was last updated in September. Before that, April, then January 2005. That hardly constitutes as not maintained.

The problem here is depend. If you do equery, nothing will show up depending on it. But any python music app will most likely use it if it's there.

[Comment 18 Marcin Janczyk 2006-01-29 11:02:23 UTC]

(In reply to comment #17)
> Actually, this is incorrect. MusicBox, a Rox application uses pyflac when
> available to play flac files. This is the problem. It is not a dependency. It's
> an option. So, any python-based music player may use pyflac, but does not
> require it to be built or run. I think this project has value, takes little
> space, and is worth injecting into the tree. As for unmaintained, that is not
> quite accurate. pyflac was last updated in September. Before that, April, then
> January 2005. That hardly constitutes as not maintained.
> 
> The problem here is depend. If you do equery, nothing will show up depending on
> it. But any python music app will most likely use it if it's there.
If anything uses it, then sorry, I simply grepped through whole /usr/portage. But it really seems unmaintained - last change in svn was "Move unused code out of trunk." - into "Trash" dir... but maybe I'm wrong.

[Comment 19 Jakub Moc (RETIRED) 2006-01-29 11:19:11 UTC]

(In reply to comment #18)
> If anything uses it, then sorry, I simply grepped through whole /usr/portage.
> But it really seems unmaintained - last change in svn was "Move unused code out
> of trunk." - into "Trash" dir... but maybe I'm wrong.

No, nothing in portage uses it, since it's not in portage at all (that's the whole point of this bug). Closing, too bad for musix-box, putting things dead upstream into portage is not an option.

[Comment 20 Peter Hyman 2006-01-29 11:27:28 UTC]

(In reply to comment #19)
> (In reply to comment #18)
> > If anything uses it, then sorry, I simply grepped through whole /usr/portage.
> > But it really seems unmaintained - last change in svn was "Move unused code out
> > of trunk." - into "Trash" dir... but maybe I'm wrong.
> 
> No, nothing in portage uses it, since it's not in portage at all (that's the
> whole point of this bug). Closing, too bad for musix-box, putting things dead
> upstream into portage is not an option.
> 

Sigh. It's not dead upstream. And, isn't the point of satisfying music-box. It's offering additional choice for users. This guy doesn't appear "dead" to me.

http://sacredchao.net/~piman/