<quote from="http://solfege.sourceforge.net"> GNU Solfege is a computer program written to help you practice ear training. It can be useful when practicing the simple and mechanical exercises. These are the exercises written so far: * Recognise melodic and harmonic intervals * Compare interval sizes * Sing the intervals the computer asks for * Identify chords * Sing chords * Scales * Dictation * Remembering rhythmic patterns </quote> Here is an ebuild for the devel version. It is based on pygtk-1.99 and libgtkhtml-2, and optionaly gnome-python-1.99 (and also swig at building time). The stable version was still gtk-1.2 based, and since this one works okay for me, I've prefered this one. It can use hardware midi output or a software sequencer (like timidity). I've successfully compiled and tested it on a ~x86 gcc-2.95-3 box, with alsa-0.9 and SBlive sound-card. Here are a few choices I've made: - There were two availables tarballs for the install. I've choosen the one with prebuilt documentation files, because for the other one you need to explicitly give the path to some docbook xsl files, and this paths depends on the version you have installed, etc. There are less dependencies with this one, and there will probably be less issues. - I've modified the path to install the .desktop file to "/usr/share/applications". Is that okay? (I was not sure about "the right place"(tm) to put this.) - I've choosen to install only .py files, not .pyc and .pyo, because the "performance" tradeoff is not critical on this kind of application. Okay, that's all, let's go back to ear training :) Reproducible: Always Steps to Reproduce:
Created attachment 14887 [details] solfege-1.9.11.ebuild
Created attachment 17138 [details] solfege-2.0.0.ebuild Update to version 2.0.0. Some improvements were inspired by bug #27974. Now also depends on app-text/docbook-xsl-stylesheets-1.62.0, available on bug #27970.
Your ebuild works fine for me! One possible problem non-GNOME users: the gtkhtml functionality will not work without the gnome functionality, so you want something like this in the runtime dependencies: ##### gnome? ( >=dev-python/gnome-python-1.99.15 gtkhtml? ( >=gnome-extra/libgtkhtml-1.99.6 ) )" ##### and something like this in src_compile(): ##### use gtkhtml || myconf="$myconf --without-gtkhtml" use gnome || myconf="$myconf --without-gnome --without-gtkhtml" ####
Created attachment 17157 [details] solfege-2.0.0.ebuild Thanks for your comment. I don't fully agree tho: Technicaly, it is possible to configure with only the "--without-gnome" option, and to still have a working gtkhtml2 support. What lacks in my previous ebuild was only a gtkhtml? dependency on gnome-python. But what is important when gtkhtml flag is enable is to ensure that gnome-python has also be compiled with this flag enabled. I've added such a test in this ebuild. Not sure how clean it is tho.
*** Bug 27974 has been marked as a duplicate of this bug. ***
If you could update your ebuild to work with the latest version (2.0.4 I believe) or simply let me know that this one works with the new version, it would really expedite getting it into portage. Thanks
Thanks for your interest for this ebuild. I've reworked it a bit while updating to 2.0.4. The hacks for checking gtkhtml in gnome-python is still there because there is still no way in portage to verify this cleanly. I've put it in pkg_setup thinking "the sooner, the better", but am not sure what is the best (src_compile also makes sense since it is more or less a ./configure like check). I could not test this version with hardware midi because i don't currently have a working machine with a real soundcard (hmmm... me dreams of computing without the hardware...), so all i've tried was timidity.
Created attachment 25310 [details] solfege-2.0.4.ebuild
Created attachment 25313 [details] solfege-2.0.4.ebuild Removed trailing whitespaces. Just for pleasure to have a repoman-compliant submission.
Doh! there a trailing IUSE flag, alsa, which is not used. Can i let you remove it? I had it at some point but then choosed to removed the alsa dep i had introduced. Thanks.
Very nice and clean ebuild. Me likey. A few comments though... For SRC_URI's on sf, you can just use: mirror://sourceforge/${PN}/${P}.tar.bz2 (or similar) rather than a "real" http://some.actual.mirror/... Also, when using sourceforge or another mirror system, it's prefered that you place RESTRICT="nomirror" in the ebuild so it's fetched directly from sf rather than from gentoo. And instead of 'einstall' try 'make DESTDIR=${D} install' first. If that fails, fall back on einstall, but the DESTDIR way is prefered. I'm testing it out now. Thanks. --Jeremy
Bah! i forgot in some ebuilds what i think to do in others, i mean, i knew about this third party mirrors... grrr... and here is also another thing i've forgot to update, half of makefile sed command is obsolete: mv Makefile.in Makefile.in.orig - sed -e 's:links:#links: ; s:gnome/apps/Applications:applications:' \ + sed -e 's:gnome/apps/Applications:applications:' \ < Makefile.in.orig > Makefile.in For the install command, the makefile doesn't seem to know about "DESTDIR", only "prefix" and his friends, so i think you'll have to keep the einstall call. Thanks for your review and test.
In portage. Thanks.
Also forgot a sys-apps/sed in DEPEND... don't forget if you use it in the ebuild, you need to DEPEND on it... that's something I always have to double check myself... that and libtool/automake/autoconf stuff... you're a pretty good ebuild writer. If you have time and desire, you might want to see about becomming a gentoo developer. We could use the help ;) Just create a new "bug" in the 'New Gentoo Developers' "product" if you're interestead.
> Also forgot a sys-apps/sed in DEPEND... Ah, ok, I was thinking this was not needed for pkg already in system profile. > you're a pretty good ebuild writer. Thanks :) > Just create a new "bug" in the 'New Gentoo Developers' "product" if you're interestead. In fact i've already entered the queue, Seemant opened a bug for me maybe one week ago, so wait and see...
