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