2015-09-16 13:22 GMT+02:00 IOhannes m zmölnig <[email protected]>: > On 09/16/2015 10:41 AM, Jaromír Mikeš wrote: >> Ok ... if we thinking packaging these files what about licensing? >> There is already one bug opened ... >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773246 >> >> IOhannes can you suggest complete list of packages we could provide >> and containing drumkits?
> - first of all, upstream doesn't "release" (in a formal release-process) > drumkits at all. > i don't think that attaching the hydrogen version number to the drumkits > is a very good idea in the first place (sticking with the date of the > snapshot is saner) Make sense to me. > - upstream doesn't even provide a tarball for the drumkits. > instead we (Debian) create a fake tarball by aggregating all downloads > published via their drumkit feed (DKF). > > that's a slightly awkward situation. > > > - the DKF provides some extra information (author, description, > license,...). > since the upstream tarball is synthesized anyhow, this information could > be used to synthesize debian (binary) packages as well: just provide a > single drumkit per package¹. Ok > the biggest problem i see here, is that this makes the number of Debian > packages variable. > otoh, if we are not doing too many snapshots and keep old drumkits (not > published by upstream any more), then the work should be reasonable. > > i *think* this should be done semi-automatically, using a script > downloading the drumkits and providing a debian/control stub that has > all the information updated. That would be great if doable. > - licensing is a *complete* mess. > the DKF is kind enough to provide licensing information provided by the > authors (in a free form; so not really machine parsable) > cool. > the bad news is, that many drumkit package creators did not care about > licenses, and just left the license field empty :-( That's what i was afraid :( > worse, some drumkits have a license text like: > "Do not redistribute or publish the inluded samples." > here's a list: > - GSCW Kit 1 (Flac edition) > - GSCW Kit 2 (Flac edition) > - Roland_MC-307_CR78&Cheaps > - Roland_MC-307_TR-606 > - Roland_MC-307_TR-808_ > - Roland_MC-307_TR-909 > - Roland_MC-307_Techno1 :( > which leaves only these drumkits that have a free license (mostly some > CC; and 'Lightning1024' says "Free!" whatever this means) > - DeathMetal (sf) > - circAfrique v4 > - BJA_Pacific > - The Black Pearl 1.0 > - Gimme A Hand 1.0 > - rumpf_kit_z01_gm > - belofilms.com - AC-Guitar-Strums (flac) > - Audiophob > - Drumkit excepcional > - Lightning1024 > - Denon CRB-90 These are also probably problematic as Fabian mentioned :( > that's still 194MB, but having a closer look reveals, that 136MB of > those are consumed by "belofilms.com - AC-Guitar-Strums (flac)". > which is not a proper drumkit at all, so i guess it could be factored > out into a separate binary package. > i haven't checked the rest, but if they are all "drum" kits, then we > might want to put them into a single package (~58MB). > or split them into something like: > - hydrogen-drumkits-classical > - hydrogen-drumkits-ethno (or hydrogen-drumkits-percussion) > - hydrogen-drumkits-electro > - hydrogen-drumkits-effects I like these categories mira _______________________________________________ pkg-multimedia-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
