[arch-proaudio] Solfege Completely Unusable
Does anyone have the solfege ear-training package up and running (and actually producing sound)? I've noticed a few issues that I'd like to confirm before filing a bug report. Missing optional dependencies are the easy ones https://nosuckdotorg.files.wordpress.com/2018/05/solfege-csound-mma-lilypond...: · csound https://www.archlinux.org/packages/community/x86_64/csound/ · mma https://aur.archlinux.org/packages/mma/ · lilypond https://www.archlinux.org/packages/community/x86_64/lilypond/ Then, there's the bigger issue of pyalsa https://nosuckdotorg.files.wordpress.com/2018/05/solfege-pyalsa.png, which is required for ALSA playback (and apparently completely different from the AUR's python2-pyalsaaudio and python-pyalsaaudio packages). The solfege package includes a Python script, however, for downloading and setting up pyalsa. Perhaps this script should be mentioned by pacman, when solfege is installed?
■ python2 /usr/share/solfege/solfege/download_pyalsa.py Traceback (most recent call last): File "/usr/share/solfege/solfege/download_pyalsa.py", line 25, in <module> import solfege ImportError: No module named solfege
... That is, once the script stops failing miserably. I will be reporting this issue upstream, if nobody tells me I'm missing something obvious. Thanks!
Hi! On 2018-05-17 05:28:49 (-0400), Grady Martin wrote:
Does anyone have the solfege ear-training package up and running (and actually producing sound)? I've noticed a few issues that I'd like to confirm before filing a bug report. Missing optional dependencies are the easy ones https://nosuckdotorg.files.wordpress.com/2018/05/solfege-csound-mma-lilypond...:
· csound https://www.archlinux.org/packages/community/x86_64/csound/ This just recently became available (because I moved it to community). Thanks for mentioning! I can add it to optdepends soonish. Should become available once you install csound then.
· mma https://aur.archlinux.org/packages/mma/ This I could probably move to [community], although I really don't like moving python2 only stuff.
· lilypond https://www.archlinux.org/packages/community/x86_64/lilypond/ That is already in optdepends and if installed, /usr/bin/lilypond-book is available.
Then, there's the bigger issue of pyalsa https://nosuckdotorg.files.wordpress.com/2018/05/solfege-pyalsa.png, which is required for ALSA playback (and apparently completely different from the AUR's python2-pyalsaaudio and python-pyalsaaudio packages). The solfege package includes a Python script, however, for downloading and setting up pyalsa. Perhaps this script should be mentioned by pacman, when solfege is installed? Hmm, this should probably be python2-pyalsa though (which is not packaged). Could you check, whether `pip2 install --user pyalsa` fixes this for you? This might just be another hidden depends, that is just not very clear, as upstream doesn't use setuptools.
■ python2 /usr/share/solfege/solfege/download_pyalsa.py Traceback (most recent call last): File "/usr/share/solfege/solfege/download_pyalsa.py", line 25, in <module> import solfege ImportError: No module named solfege
... That is, once the script stops failing miserably. I will be reporting this issue upstream, if nobody tells me I'm missing something obvious. Please do so and tell them to also finally release a new version. The current "stable" is super ancient. ;-) However, I never got a reply on that request from the maintainer.
I guess the newer versions of solfege might mitigate these issues or might even be python3... Best, David -- https://sleepmap.de
Am 17.05.2018 um 12:11 schrieb David Runge:
Please do so and tell them to also finally release a new version. The current "stable" is super ancient. ;-)
There are newer releases either in git http://git.savannah.gnu.org/cgit/solfege.git/ or in a download location that is only linked from the last announcement on sourceforge: https://sourceforge.net/p/solfege/mailman/message/35181262/ ftp://alpha.gnu.org/gnu/solfege Regards Uwe
Those are all marked as devel and not stable releases, hence my comment about releasing a new version. So I'm aware of those versions, but it's no reason to flag the package. However, switching might be worth it eventually, as those versions are python3 based and now also two years old... (not a good project health indication). I just wish the project maintainer would do that and mark them stable. There simply is no way of knowing for me, if I open a can of worms with them... -- https://sleepmap.de
participants (3)
-
David Runge
-
Grady Martin
-
Uwe Koloska