I got these installed, and neon was installed before building bad. net-misc/neon-0.25.5 media-libs/gst-plugins-bad-0.10.1 unaffiliated media-plugins # gst-inspect-0.10 neonhttpsrc No such element or plugin 'neonhttpsrc' And I couldn't find a separate build for it. I need this for shoutcast, and icecast.. Am I missing something, or is this really a bug?
23:56 < __tim/#gstreamer> neonhttpsrc is in -bad
sorry, version is 0.10.1 not .4 like I said in subject.
Created attachment 81997 [details] Compile log of -bad
Since it has an external dep (neon) this doesn't get built by default. You should be able to create a local ebuild for it easily for now (look for examples in media-plugins/gst-plugin-*).
i will add asap
Great. Got my needs replaced with gnomevfs -plugin but still.. yeah. :)
It should still go in ASAP, as I will not be installing any gnome junk on my system (nor will many other users who want shoutcast/icecast functionality).
Actually, gnomevfssrc is buggy and crashes my player when HTTP stream is opened. Need neonhttpsrc asap :-)
Created attachment 82518 [details] gst-plugins-neon-0.10.1.ebuild I think I ran over zaheerman the other day with my car, so I doubt he'll look at this, in any case.. here's the ebuild. Somebody add this to portage, just double-check and make sure that I put the right minimal version for neon, because I really have no idea what the minimal is.
(In reply to comment #8) > Actually, gnomevfssrc is buggy and crashes my player when HTTP stream is > opened. This is totally useless saying 'X crashes for me' without any evidence, pointing at something that might not even be the source of your problem. Haven't you read my comment #4 at all, does the word 'local' ring a bell ? Joe, if you really care to get this in anytime soon I suggest you keep your clueless mouth shut, we don't need your trolls and misplaced attempts at jokes here.
> > Actually, gnomevfssrc is buggy and crashes my player when HTTP stream is > > opened. > This is totally useless saying 'X crashes for me' without any evidence, > pointing at something that might not even be the source of your problem. > Haven't you read my comment #4 at all, does the word 'local' ring a bell ? Sorry, this report is only about missing neon and not about my problems with gnomevfs.. didn't think thru what I stated about gnomevfs, and don't know if I'm going to debug it futher.. My error, apologies. > Joe, if you really care to get this in anytime soon I suggest you keep your > clueless mouth shut, we don't need your trolls and misplaced attempts at jokes > here. Me, myself, written, has nothing to do with joecool's comments. Making that clear. But the ebuild joecool posted actually works, simple as it is.. the gstreamer eclasses are cool, and streaming works with neonhttpsrc.
>Joe, if you really care to get this in anytime soon I suggest you keep your >clueless mouth shut, we don't need your trolls and misplaced attempts at jokes >here. Clueless? I just posted a working ebuild and as it is, the last two major bugs I posted were major eclass fixes, and both maintainers went AWOL. In order to get projects I was working on functioning with portage, it took days up to weeks in order reach a dev who would commit them. To say I'm irritated is an understatement. I learned the hard way, whenever I just sit back and shut my mouth, nothing ever gets done if the maintainer goes missing. I attempted to contact zaheerman and have recieved not one reply for over a week. There is a major project that depends on this package being in portage. Can I at least get the status, or anything useful out of someone, all I hear is "I will add asap", and its been a week now. I wasn't rushing it too much, but now that a final release is out, somebody had better commit this.
(In reply to comment #12) > Clueless? I just posted a working ebuild and as it is, 'working ebuild', I made the eclass so easy so that any guy picked from the street could create the ebuilds for the plug-ins they needed. Don't take too much pride in copying the gnomevfs plugin ebuild and adding a dep to it. Neon is in bad, gnomevfs is in base, upstream those designations indicate quality. There is no intention to add all available plugins to the tree, just the best and necessary ones. > the last two major bugs > I posted were major eclass fixes, and both maintainers went AWOL. In order to > get projects I was working on functioning with portage, it took days up to > weeks in order reach a dev who would commit them. To say I'm irritated is an > understatement. I'm talking about your attitude here or in general -from what I've picked up all over the place-, to say I'm irritated is an understatement. It is clueless to assume your attitude will get things moving any faster here, but I think you are learning that the 'hard' way. > I learned the hard way, whenever I just sit back and shut my mouth, nothing > ever gets done if the maintainer goes missing. I attempted to contact > zaheerman and have recieved not one reply for over a week. There is a major > project that depends on this package being in portage. Maybe if you learned to copy his nick correctly your contact attempts might have reached someone.
>There is no intention to add all available plugins to the tree, just the best >and necessary ones. BMPX requires it, and to make matters worse, there is no longer a maintainer for that ebuild. Whether or not you think it is very stable is not my concern, add it and mask it if you have a problem. In any case, I'm not the only one expecting it in, but I do know that in this use it has proven to be more reliable then gnomevfs. >It is clueless to assume your attitude will get things moving any faster here, >but I think you are learning that the 'hard' way. You misunderstand me, my attitude is purely in the spirit of necessity, in the past it has been quite effective. >Maybe if you learned to copy his nick correctly your contact attempts might >have reached someone. Got me there. My apologies zaheerm.
(In reply to comment #14) > >There is no intention to add all available plugins to the tree, just the best > >and necessary ones. > > BMPX requires it, so .. it's masked, why should it be a concern to us ? Crappy maintenance upstream from what I get from the p.mask comment. > and to make matters worse, there is no longer a maintainer > for that ebuild. I read the comment, I know who wrote it and trust his judgement. BMP (or whatever incarnation of it) should probably be ditched from the tree, given it's unstable nature. > Whether or not you think it is very stable is not my concern, There is the attitude again. It is actually your concern, judging from your comments here. > add it and mask it if you have a problem. Why should I add it masked if I we do not intend to add it at all (hypothetical question) ? > In any case, I'm not the only one > expecting it in, What is your point ? The only reason this bug is still open is that it didn't come from you alone. > but I do know that in this use it has proven to be more > reliable then gnomevfs. Proven by whom, when and where? This is the first time one of your comments comes close to actually have some real-bug value. > You misunderstand me, my attitude is purely in the spirit of necessity, in the > past it has been quite effective. In my experience OSS devs do this for their 'fun', if you take that away, there is no reason to do anything. But by now, I've learned to go in ignore mode for certain type of bugs and deal with them my own way at my own time. Let's close this 'discussion' here, this is bugzilla, not your average forums.
Well guys, ou can stop arguing now...it is now in portage
(In reply to comment #16) > Well guys, ou can stop arguing now...it is now in portage > Thank you.
