A new version of streamtuner is available, and also..the currently unmasked version of streamtuner is very old. Reproducible: Always Steps to Reproduce:
I would also like to see new version of streamtuner, 0.11.1 is now out. Also all streamtuner plugins are still masked (for at least 2 monts now). Unmasking and update is also in order there.
Created attachment 25661 [details] streamtuner-0.11.1.ebuild Here's an updated ebuild that should work for you, with one exception. For some reason, emerge refuses to see the new ebuild in my overlay directory. It's a confusing problem since I have many other packages in there that work fine. This is what happens. If I run 'emerge -p streamtuner' I get: [ebuild UD] net-misc/streamtuner-0.10.1 [0.11.1] And by calling the full path, 'emerge -p /usr/local/portage/net-misc/steamtuner/streamtuner-0.11.1.ebuild', I get: Calculating dependencies \!!! aux_get(): ebuild for 'net-misc/streamtuner-0.11.1' does not exist at: !!! /usr/portage/net-misc/streamtuner/streamtuner-0.11.1.ebuild emerge: create(): aux_get() error on net-misc/streamtuner-0.11.1; aborting... Copying the ebuild into the main portage directory allows me to use it, but of course it gets wiped on the next rsync. I don't see how it could be a problem with the ebuild, but any suggestions will be appreciated. Also, I have made ebuilds for the latest streamtuner-local and streamtuner-live365 plugins. They don't have the 'invisibility' problem that streamtuner does, but they do depend on 0.11.0 or higher. So you will have to work around the above problem before they will build or run properly. They live in media-plugins.
Created attachment 25662 [details] streamtuner-local-0.3.0.ebuild First of all, please ignore all the 'invisibility' stuff above. I was asleep at the wheel and see that I had my overlay directory named 'steamtuner' (missing an 'r'). It works, once I spelled it correctly :) Sorry people. Okay, so here's the streamtuner-local plugin.
Created attachment 25663 [details] streamtuner-live365-0.3.3.ebuild And the latest streamtuner-live365.
Created attachment 26150 [details] streamtuner-xiph-0.0.1.ebuild this plugin adds support for xiph.org's icecast directory
Created attachment 26164 [details] streamtuner-xiph-0.0.1.ebuild Hi, rojaro. I see you have copied the streamtuner-local-0.3.0.ebuild, which, unfortunately, contains a couple errors. May I offer some suggestions? First, you need an IUSE="" line even if the values are left empty. Next, the license is actually BSD. Just compare COPYING from the source and /usr/portage/licenses/BSD and you will see what I mean. The About page of their web site calls it "Revised", but all they did was fill in the blanks. Also, streamtuner is actually a runtime dependency. Look here: http://dev.gentoo.org/~liquidx/ebuildmistakes.html for some good tips. I find it to be a lot of help, and use it as a general guideline and checklist. BTW, the plugin works great! Got some AltRock playing now and it's eating less than 10K of bandwidth with excellent sound.
Created attachment 26165 [details] streamtuner-python-0.0.3.ebuild And an ebuild for the python plugin. This seems to work as well, but I won't swear to it.
can we get this into portage ?
Agreed, this is very overdue, all masked packages work perfectly.
*** Bug 45349 has been marked as a duplicate of this bug. ***
Also works fine for me (-march=athlon, -march=athlon-xp, -march=pentium4 and mcpu=i686) --> i think it is portage-ready :)
Created attachment 28281 [details] streamtuner-0.11.1.ebuild It looks like curl got moved from net-ftp to net-misc. This fixes the dependency in the streamtuner ebuild.
Created attachment 28406 [details] streamtuner-0.12.1.ebuild Slightly different UI layout (better, IMHO) and some bug fixes in this version. I lost my bookmarks during the upgrade, just a few so no big deal, but be warned.
Created attachment 28407 [details] streamtuner-live365-0.3.4.ebuild Version bump, works fine.
Created attachment 28408 [details] streamtuner-local-0.4.0.ebuild Version bump, ditto.
Created attachment 28409 [details] streamtuner-python-0.1.0.ebuild Version bump and another ditto.
Created attachment 28410 [details] streamtuner-xiph-0.1.0.ebuild Get the pattern yet? :)
Created attachment 28411 [details] streamtuner-plugins-0.12.1.ebuild And, finally, a meta-package for the plugins. If I had realized how easy these were I'd have made one sooner.
Oh yeah. For those impatient ones, like me, who want to install these from an overlay, go to http://ronmon.shacknet.nu/ebuilds/ . You'll find tarballs that unpack from the top level of your overlay directory. They include sub-directories, digests and such. Grab them both, and an 'emerge streamtuner-plugins' will update everything in one fell swoop.
I've been getting sandbox errors with the 0.12.1 ebuild listed below. Everything works perfectly with .11.1. Here's some output: mkdir /var/tmp/portage/streamtuner-0.12.1/image/usr/share/omf mkdir /var/tmp/portage/streamtuner-0.12.1/image/usr/share/omf/streamtuner for file in streamtuner-C.omf; do \ /bin/install -c -m 644 ./$file.out /var/tmp/portage/streamtuner-0.12.1/image//usr/share/omf/streamtuner/$file; \ done scrollkeeper-update -p /var/lib/scrollkeeper -o /var/tmp/portage/streamtuner-0.12.1/image//usr/share/omf/streamtuner ACCESS DENIED open_wr: /var/lib/scrollkeeper/scrollkeeper_docs ACCESS DENIED open_wr: /var/lib/scrollkeeper/scrollkeeper_docs /var/lib/scrollkeeper/scrollkeeper_docs: Permission denied make[4]: [install-data-hook-omf] Error 1 (ignored) make[4]: Leaving directory `/var/tmp/portage/streamtuner-0.12.1/work/streamtuner-0.12.1/help/C' <-------SNIP-------> >>> Completed installing into /var/tmp/portage/streamtuner-0.12.1/image/ --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-net-misc_-_streamtuner-0.12.1-24595.log" open_wr: /var/lib/scrollkeeper/scrollkeeper_docs open_wr: /var/lib/scrollkeeper/scrollkeeper_docs --------------------------------------------------------------------------------
Hi Aaron, Hmm, I can't get mine to do that. The directory /var/lib/scrollkeeper/scrollkeeper_docs doesn't exist on my machine, don't know whether that has anything do to with it or not. I've searched for an answer and haven't found anything definitive. Anybody have an idea why he's getting this? Cheers, Ron
I have an idea that may work. Try changing make to emake in this line: From: make DESTDIR=${D} install || die To: emake DESTDIR=${D} install || die If that does it, I'll post the change.
Could bug wranglers re-assign this to someone more knowledgable about this package? I really don't know what it is. Thanks.
I am also getting sandbox violations with streamtuner-0.12.1, also my error message is a little different: make[1]: Leaving directory `/var/tmp/portage/streamtuner-0.12.1/work/streamtuner-0.12.1' /usr/lib/portage/bin/dodoc: LICENCE does not exist. man: prepallstrip: strip: strip: usr/bin/streamtuner usr/lib/streamtuner/plugins/shoutcast.so >>> Completed installing into /var/tmp/portage/streamtuner-0.12.1/image/ --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-net-misc_-_streamtuner-0.12.1-22324.log" open_wr: /var/lib/scrollkeeper/scrollkeeper_docs open_wr: /var/lib/scrollkeeper/scrollkeeper_docs -------------------------------------------------------------------------------- I have tried changing make to emake, but that does not make a difference.
Created attachment 28750 [details] streamtuner-0.12.1.ebuild Could all this be because LICENSE was mis-spelled?
No, LICENSE mispelling has nothing to do with it, I edited ebuild but it di not help. But I have noticed an error message appering before access violation summary: ACCESS DENIED open_wr: /var/lib/scrollkeeper/scrollkeeper_docs ACCESS DENIED open_wr: /var/lib/scrollkeeper/scrollkeeper_docs I am emerging as root and have rw permissions for /var/lib/scrollkeeper/scrollkeeper_docs: -rw-r--r-- 1 root root 31862 Feb 9 17:29 /var/lib/scrollkeeper/scrollkeeper_docs An ebuild should probably work if emerged with FEATURES="-sandbox", but that is only a workaround and I do not want to do it unless there is no other way.
Created attachment 28770 [details] Updated streamtuner-0.12.1 ebuild I fixed the sandbox problem. I did some searching and found that rhythmbox was suffering from similar problem some time ago, so I looked at rhythmbox ebuilds they contain workaround - gnome2_omf_fix, whatever that is. I changed the ebuild accordingly and tested it on my system. Please test it to conform that it indeed fixes the problem. Also, look at ebuild itself, it works, but I am no ebuild expert. I have also tested plugins, they all work fine, except local which gives an error message saying that "Plugin /usr/lib/streamtuner/plugins/local.so couldn't be oaded: /usr/lib/streamtuner/plugins/local.so: undefined symbol: ogg_stream_pagein". I have tried emerging with or without oggvorbis USE flag, but that did not help. Anybody knows what is the problem with local plugin? All other plugins seem to work fine.
Created attachment 28804 [details] streamtuner-0.12.1.ebuild Well, streamtuner is not a gnome app, so I'm not sure that inheriting the gnome2 eclass is a real good idea. But it made me think about this some more and I read the gnome2_omf_fix section of the eclass. The access violation is happening in the localstatedir, so I searched around in /usr/lib/portage/bin for a way to deal with it. What I found was 'einstall', in ebuild.sh, which specifically sets 'localstatedir=${D}/var/lib'. That should prevent the attempted write outside of the sandbox. Since the earlier builds didn't break for me I can't be 100% sure, but I think this will fix it. The build went cleanly, and /var/lib/scrollkeeper now contains a bunch of stuff that wasn't there before. There are some dependency updates too.
ronmon, I can conform that your new ebuild works fine now. Now does local plugin work for you (or anybody, who tried it out)?
What's your version of libvorbis? I rushed these ebuilds out when they showed up on freshmeat, before they were posted on the streamtuner web site. Consequently, I missed some dependency updates and streamtuner-local requires >=libvorbis-1.0. Sorry. Also, the new plugins all require >=streamtuner-0.12.0, so maybe just rebuilding the plugin(s) after streamtuner-0.12.1 is properly installed will fix it. All the plugins work for me, and if I start streamtuner in the foreground from an xterm I get exactly zero errors of any kind.
My libvorbis version is 1.0.1-r2, so I do not think that is the problem. I have rebuilt all plugins several times after installing streamtuner 0.12.1, but that did not help, still problems with local plugins. Otherwise it runs fine. Running streamtuner from xterm I get some Glib errors: "GLib-CRITICAL **: file gtree.c: line 209 (g_tree_lookup): assertion `tree != NULL' failed", but I do not think it has anything to do with local plugin problem. I posted the actual error in my previous post.
Then I really don't know what the problem is, but I wouldn't necessarily assume that the glib errors are unrelated. Some input from others could help, of course. Would you mind running 'revdep-rebuild' and see what happens? BTW, I lived near Raleigh (Clayton) for a bit in the mid 1980's. The Wolpack was in it's heyday with Jim Valvano at the helm. Go Pack!
All the ebuilds are in. local is masked pending the resolution to: Plugin /usr/lib/streamtuner/plugins/local.so couldn't be loaded: /usr/lib/streamtuner/plugins/local.so: undefined symbol: ogg_stream_pagein.
ok that is fixed now too... libogg-1.0 didn't install a pkg-config ogg.pc file which caused the plugin to not link to libogg and libvorbis.
