https://bugzilla.redhat.com/show_bug.cgi?id=1822971 Nick Black <dank@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(dank@xxxxxxxxx) | --- Comment #15 from Nick Black <dank@xxxxxxxxx> --- Regarding clarification of the multimedia in data/ (I just did this for the Debian package): In the upstream tarball, there's a lot of material which doesn't belong in a Linux distribution. There are sprites borrowed from NES games, etc. I do not intend to include these in either the SRPM or RPMs. I thus need to change the specfile to reference the DFSG tarball. For those unaware, this stands for Debian Free Software Guidelines, and I believe the set of files excluded for DFSG-compatibility to be the same set of files that ought be excluded on Fedora. I will change the specfile to reflect this. Thanks for the catch! Regarding the few files that will remain, the README.source from our Debian package explains things best: ----------------------------------------------------------------------- The upstream tarball, as automatically put together by GitHub upon a tagging event, is unsuitable for distribution in Debian due to several DFSG-unfree multimedia, and one DFSG-unfree source file (src/demo/jungle.c includes an unfree image as a blob). Generating the DFSG-compliant source file can be performed via e.g.: uscan --repack --compression xz -v uscan gets its list of excluded files from debian/copyright. The multimedia which *does* remain is all Free media created for this project by the project authors, and is licensed under Apache 2.0 like the rest of the project. "Source" for these multimedia is included in the source tarball's data/ directory as .xcf (GIMP) and .osp (OpenShot) files. The former were made using GIMP 2.10 as packaged by Debian, the latter using OpenShot 2.50 as built from upstream source, and Blender 2.82 as packaged by Debian. These are the preferred forms for editing the included media. The final media remains included, and installed in the binary packages, because building/rendering is computationally intensive and somewhat brittle. ----------------------------------------------------------------------- So I'd like to do the same thing for Fedora. The SRPM will contain both the rendered media, and the source necessary to generate them using Free tools. The binary RPMs will only install the rendered versions. Rendering the media will not be part of a typical build, and indeed is not currently automated. Fedora doesn't, so far as I know, *require* "preferred editable form" for multimedia, just that it can be redistributed (please correct me if I'm wrong). We could thus leave the "sources" out of the SRPM entirely. I'd rather not because they're (a) less than 10MB total and (b) I've already got this automated this way. Hopefully that answers your question about data/. I'll update the specfile, which ought be sufficient, since I can just change the upstream tarball location. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
