https://bugzilla.redhat.com/show_bug.cgi?id=1450679 --- Comment #11 from Sandro Bonazzola <sandro.bonazzola@xxxxxxxxx> --- (In reply to Richard W.M. Jones from comment #10) > [x]: License field in the package spec file matches the actual license. > Note: Checking patched sources after %prep for licenses. Licenses > found: "GPL", "LGPL (v2 or later)", "GPL (v3 or later)", "Unknown or > generated". 97 files have unknown license. Detailed output of > licensecheck in /home/rjones/1450679-laby/licensecheck.txt > > I checked the licenses and is does appear that the author intends > GPLv3+. > > I guess you could ask upstream to use proper per-file GPL headers > instead of ones they appear to have made up, but it's not urgent. Reported upstream: https://github.com/sgimenez/laby/issues/46 > [!]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the > beginning of %install. > Note: rm -rf %{buildroot} present but not required > > Please remove rm -rf %{buildroot} at the beginning of the %install section. Done > [!]: Requires correct, justified where necessary. > > The Requires lines should be removed. The final binary will > contain statically-linked copies of ocaml-lablgtk and gtksourceview2. > It dynamically links to the C libs gtk etc. There is no need to pull in > those packages at runtime at all. Done > Generic: > [!]: Uses parallel make %{?_smp_mflags} macro. > > Did you try enabling this? If it works it should be used. If the > build system is broken for parallel builds (not uncommon, unfortunately) > it may be worth adding a comment in the spec file. Added, seems to work fine. > [!]: Final provides and requires are sane (see attachments). > > See above about Requires. The other (generated) requires / provides > of the package are correct. Done > [?]: Fully versioned dependency in subpackages if applicable. > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in laby- > debuginfo > > I don't know what fedora-review means by this, but as far as I know > this is not necessary. Agreed > [?]: Package functions as described. Verified working > [?]: Package should compile and build into binary rpms on all supported > architectures. > > We will find out when you build this in Rawhide. ok > The following seem to be real problems. The files in the RPMs > are really zero length, which seems like it is wrong: > > laby.x86_64: E: zero-length /usr/share/laby/sound/carry-exit.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/drop-no-space.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/drop-nothing.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/exit-in.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/no-exit.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/rock-in.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/rock-take.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/start.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/take-no-space.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/take-nothing.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/wall-in.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/web-in.wav > laby.x86_64: E: zero-length /usr/share/laby/sound/web-out.wav They are zero-length in the upstream source tree. I opened https://github.com/sgimenez/laby/issues/47 to track it. Looking at the code looks like they are installed to avoid file not found errors while playing sounds in src/sounds.ml. I think best solution for this is getting upstream to add real sound files or add error handling, instead of just adding placeholders for avoiding file not found errors. In the meanwhile, in order to keep the game working, they're needed even if empty. Spec URL: https://raw.githubusercontent.com/sandrobonazzola/laby/17eb8daef0d416b8122f22f4e69de03ba709d36f/packaging/laby.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/sbonazzo/Laby/fedora-rawhide-x86_64/00554778-laby/laby-0.6.4-4.fc27.src.rpm -- 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