https://bugzilla.redhat.com/show_bug.cgi?id=1308985 --- Comment #9 from Jonathan Underwood <jonathan.underwood@xxxxxxxxx> --- (In reply to Igor Gnatenko from comment #8) > > - Package installs properly. > > Note: Installation errors (see attachment) > > See: https://fedoraproject.org/wiki/Packaging:Guidelines > You didn't attach anything and in fact it is installable, you have problems > with mock or we have broken rawhide. > > > - Development (unversioned) .so files in -devel subpackage, if present. > > Note: Unversioned so-files directly in %_libdir. > > See: http://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages > See below. > > > - All build dependencies are listed in BuildRequires, except for any that > > are listed in the exceptions section of Packaging Guidelines. > > Note: These BR are not needed: gcc gcc-c++ > > See: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 > This guidelines changed recently. Now we need to require explicitly. > > > - Forcing the scripts to use python 2.7 should be conditionalised for > > RHEL - no need to do that for Fedora. > It is compile-time only. But I agree that this could be fixed. > > > [!]: License field in the package spec file matches the actual license. > > Note: Checking patched sources after %prep for licenses. Licenses > > found: "Apache (v2.0)", "GPL", "GPL (v2 or later)", "GPL (v3 or > > later)", "Unknown or generated", "MIT/X11 (BSD like)", "BSD (3 > > clause)". 50 files have unknown license. Detailed output of > > licensecheck in /home/jgu/Fedora/1308985-vulkan/licensecheck.txt > Code which goes to install (linking and whatever) only MIT. > > > I'm pretty sure the .so's aren't actually devel libs so shouldn't be > moved to the devel package, but they do need to be versioned. > Not yet. Why not? This needs at the very least an explicit comment in the spec file, and an FPC exception - right now, you're breaking guidelines. "Not yet" just doesn't cut it. > > > [!]: Uses parallel make %{?_smp_mflags} macro. > It is using %make_build which effectively does smp_mflags > > > Is Ajax technically upstream? If not, those patches do need pushing > upstream and an appropriate comment added to spec for each patch. > > Most of all patches made only for compatibility with our guidelines and > never will be accepted in upstream as it stays now. (Read as buildsystem > changes). Some of patches we are going to send to upstream, but not right > now. > OK, so comments need adding to the spec file indicating this, in order to comply with guidelines. > > > > So after all only python2/python3 question still exists which could be > easily fixed and versioning of so-files but I don't think that we need to do > it because if understood correctly it is not going via public API so it is > okay. The libraries are currently installed in the linker path and so are public at the moment. They either need versioning, or moving to a non-public location. > > I am still insisting that package is totally compatible with guidelines > except few points which I mentioned above. "Except a few points" doesn't cut it. Your approach to this review is worryingly sloppy. -- 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 https://admin.fedoraproject.org/mailman/listinfo/package-review