https://bugzilla.redhat.com/show_bug.cgi?id=1822971 David Cantrell <dcantrell@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(dcantrell@redhat. | |com) | --- Comment #20 from David Cantrell <dcantrell@xxxxxxxxxx> --- (In reply to Nick Black from comment #15) > 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. That is correct for these files types. > 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. Yeah, this should be fine. The Fedora package using the DFSG tarball as the source will comply with Fedora guidelines too. That should keep things a little easier on your end. I am currently running a new review now on the latest SRPM. -- 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
