i did a really rough port of xmms-jack to compile against beep-media-player. works for me. someone else go ahead and clean it up / ebuild-ize it. source code @ http://unit-e.cc/~shadow/gentoo/bmp-jack-0.11.tar.bz2
Created attachment 56862 [details] bmp-jack-0.14.ebuild This ebuild installs a jack hook for beep media player. The ebuild runs fine, just the installation tells me something about text relocations, which I did not understand. Using dolib, doins, dobin etc. produce the same. Maybe someone can fix this. Nonetheless the ebuild itself works.
Created attachment 59668 [details] bmp-jack-0.14.ebuild with some modifications I made a few modification in order to make this ebuild work for me: - SRC_URI is now hardcoded (because the bmp-jack package doesn't exist on sourceforge) - it seems that we are using some precompiled binaries if we just do "make -f Makefile.BMP clean && make -f Makefile.BMP", so instead I went for the full make distclean ./configure make make -f Makefile.BMP clean make -f Makefile.BMP It's my first ebuild, so please help me to correct my errors
What's the econf and emake for?? The readme says clearly that we only need to "make -f Makefile.BMP" unless you are going to build for xmms, too, and this is not the intention of this ebuild! Also there are no binaries in the source-distribution, so why this procedure??
here, you take this :)
reassigned to B. Roggeri
(In reply to comment #3) > What's the econf and emake for?? The readme says clearly that we only need to > "make -f Makefile.BMP" unless you are going to build for xmms, too, and this is > not the intention of this ebuild! well, from the INSTALL : __________ Installing xmms-jack ---------------------- To install xmms-jack, simply run the following commands: ./autogen.sh make make install (as a root user if you aren't already) if this doesn't work, try 'make distclean' and repeat ;-) Installing for BMP(Beep Media Player) ------------------------------------- make -f Makefile.BMP clean make -f Makefile.BMP make -f Makefile.BMP install ____________ For me, this doesn't clearly states whether or not you need to do the first steps if you want to install the bmp plugin only. But then I'm not a native english speaker... > > Also there are no binaries in the source-distribution, so why this procedure?? well, there ARE .o files in the source tarball, and even .so in the .libs directory... That's why I think it's better to first do a make distclean, then ./configure, then make -f Makefile.BMP . But you are right about the fact that doing "emake" between "econf" and "emake -f Makefile.BMP" is not necessary (i've just tried and it works without), so i'm going to change that. I should probably also add DEPEND="media-sound/beep-media-player" as "make -f Makefile.BMP" uses beep-config. I'm afraid this leaves us with problem : running econf on a box where gtk+1 isn't there might result in errors. Maybe running econf with --disable-gtktest and/or --disable-glibtest would solve the problem, but I can't test...
Created attachment 59740 [details] modifications described in comment #6 For now, I didn't used --disable-[gtk,glib]test , as I couldn't confirm there is a real problem. Does anybody could test this on a box which only has gtk2 ?
Nonono, no monsieur, c'est pas juste! LA documentatio dit: ---- Installing for BMP(Beep Media Player) ------------------------------------- make -f Makefile.BMP clean make -f Makefile.BMP make -f Makefile.BMP install ---- These steps are exclusively for for BMP. The previous autogen-procedure does not affect this separate makefile. I've tried about 10 scenarios when providing my ebuild and every worked fine with these. And sorry, the objects seem to be accidently there, but it's only prebuilt objectcode that does not matter anyway. Just clean them. No econf && no gtk1 = no problem.
> > These steps are exclusively for for BMP. The previous autogen-procedure does not > affect this separate makefile. Well this indeed seems clear enough! But where do you quote that from ? The only piece of information could find was the INSTALL file in the tarball, and that's not in there... Anyway, I assume you're right (because I like "No econf && no gtk1 = no problem" :) ). > I've tried about 10 scenarios when providing my ebuild and every worked fine > with these. And sorry, the objects seem to be accidently there, but it's only > prebuilt objectcode that does not matter anyway. Just clean them. Ok, so I suppose I should : rm -r .libs .deps emake -f Makefile.BMP clean emake -f Makefile.BMP and that should do it (it does on my x86 box), even on non-x86 archs I hope... Anyway, as this is sort of a new ebuild, maybe it would be better to have only KEYWORDS="~x86", no?
This information is in the INSTALL-file, and you already quoted this passage yourself. It's just to read XOR-style, not OR-style. BMP means BMP and not xmms and BMP. "Clean" is sufficient for this. The BMP support is only two minor-versions old, so we may consider it experimental and therefore ~x86. I'm currently using it actively and it is stable for me. For me it is x86, but I don't think the portage-maintainers will agree with me. This ebuild should get into portage as soon as possible as bmp lacks jack-support and many people really desire jack. There should also be a USE flag for jack in bmp, that installs this ebuild, which can be done easily.
Created attachment 59747 [details] bmp-jack-0.14.ebuild - reverted to Qui Gon's src_compile - src_compile is back to what it was - ~x86 only - slight modifications to DEPEND (because Makefile.BMP mentions "pkg-config --libs gtk+-2.0" and "pkg-config --libs jack") I hope this can get into portage... How do we do this ? Should I just say "Please, put this into portage" ? Should I close the bug ? Hey it's the second time I use this bugzilla, and the first time I'm assigned a bug (just because I posted my first ebuild), I'm not sure what I'm supposed to do :) !!
Assign this bug to sound@gentoo.org so the right people note this.
Please add this ebuild to portage, thank you.
Just so you know guys, I got beep-media-player humming along in jack quite happily thanks to the alsa-jack plugin. Quite pretty much every alsa enabled applications for that matter.
Created attachment 60020 [details] bmp-jack-0.14.ebuild I have removed an unnecessary depend from the ebuild. Also, the tarball itself should be clean enough to run a normal make, without a clean cycle. I'll be on an x86 box later tonight, where I will give this a go. (No sound devs that I know use jack, which explains why this bug is not being picked up.)
Did you really test your "change"? Running make without clean gave me version-conflicts for the resulting shared object, which could be resolved by doing a clean previously. We want working ebuilds, not artful ebuild-style...
Incorrectly packaged tarball, make clean should not be necessary. I do not use jack, and with such comments, I no longer feel like dusting off my x86 to get this working.
Well, thanks to portage we have versioning and therefore it does not matter if the tarball is incorrectly packaged. We have a workaround that does everything right, is marked as v0.14 and will probably be fixed in 0.15 or maybe never. And? Does the make clean hurt you anyhow? Look at the thousand other ebuilds that consist of many more perverted syntax, just to fit the tarballs... The ebuild is tested and works, which cannot be said of 10% of all other ebuilds. *grmpfh*
(In reply to comment #14) > Just so you know guys, I got beep-media-player humming along in jack quite > happily thanks to the alsa-jack plugin. Quite pretty much every alsa enabled > applications for that matter. Thank you for your advice, but using the alsa-jack plugin tends to give me problem: music doesn't start when using xmms (although the client appears in qjackctl connect bay), or causes an xrun after 10 seconds when using bmp. I don't have this problem if I use the native jack plugin, so this ebuild is useful. (In reply to comment #17) > Incorrectly packaged tarball, make clean should not be necessary. > I do not use jack, and with such comments, I no longer feel like dusting off my > x86 to get this working. Then should we ask upstream for a new nice tarball ? I'm afraid that would be too little a change for him to make a new release...
The plugin still works fine for me. Therefore I'd like to know what your woes are. Which information are required for submitting it into portage? It does not melt your system, so... *confused*
Created attachment 73042 [details] Ebuild for xmms-jack-0.15 for Beep Media Player, with amd64 support Update to version 0.15. A little patch used to make it compile (and work) on amd64 will follow.
Created attachment 73043 [details, diff] Makefile.BMP patch to compile with -fPIC There you go. Works flawlessly for me !
Beep-media-player has been masked pending removal from the tree on 04/03/2006, because it has been abandoned by it's upstream developers. The recommended upgrade path is media-sound/audacious, which already has JACK support in release 0.2 (available in portage).
@Tony There are xmms, xmms2, bmp, bmpx, audacious etc. and you consider another tool instead of its direct successor (bmpx) which also supports jack by its backend (e.g. gstreamer)? Thanks for this valuable hint...
