MuseScore (and soundfonts) backporting plans
Thorsten Glaser
t.glaser at tarent.de
Wed Apr 4 21:37:55 BST 2018
Hi everyone (especially Fabian and Toddy),
now that MuseScore 2.2.1 has entered unstable, I would like to
share my plans for how to deal with backports.
musescore-sftools (needed to compile soundfonts) is currently
in backports-NEW for stretch-backports.
fluidr3mono-gm-soundfont is in good and usable shape in testing,
but not currently in backports; stretch-backports *unfortunately*
ships a version in where it is built by src:musescore.
musescore-general-soundfont is currently in NEW.
My plans for stretch-backports are as follows:
once musescore-sftools is in stretch-backports and musescore-general-soundfont
in testing, I’d like to backport musescore-general-soundfont and musescore.
I had not planned to backport fluidr3mono-gm-soundfont also, but given that
it already entered stretch-backports by means of src:musescore there might
be demand for the binary package to not vanish. Perhaps I should just upload
it right now so it can enter backports-NEW already…
… benefit of that is: the new musescore backport would not need backports-NEW
but the soundfonts would; fluidr3mono-gm-soundfont could be uploaded already.
For jessie-backports-sloppy, things are *much* more tricky due to the
too-old Qt5 it has. I am still pondering and seeing whether it will
be possible at all.
JFYI,
//mirabilos
--
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel
More information about the pkg-multimedia-maintainers
mailing list