https://bugzilla.redhat.com/show_bug.cgi?id=1403417 --- Comment #8 from Michael Schwendt <bugs.michael@xxxxxxx> --- > - Sources used to build the package match the upstream source, > as provided in the spec URL. > Note: Upstream MD5sum check error, diff is in > /home/jkraehemann/1403417-gsequencer/diff.txt > See: http://fedoraproject.org/wiki/Packaging/SourceURL This means the source tarball included in your src.rpm does not match the tarball as offered on your upstream download page. > [?]: Development (unversioned) .so files in -devel subpackage, if present. > Note: Unversioned so-files in private %_libdir subdirectory (see > attachment). Verify they are not in ld path. This refers to %{_libdir}/gsequencer/libgsequencer.so* and if it's truely a private path not visible to the runtime linker by default, there can't be any conflict with a system library using the same name. > [?]: License file installed when any subpackage combination is installed. This means: If you install any subpackage, does it depend on other packages that include the %license text? For example, gsequencer-devel with its explicit base "Requires" would pull in the gsequencer package. > [?]: Package must own all directories that it creates. > Note: Directories without known owners: /usr/share/gtk-doc, > /usr/share/xml https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership > [?]: Package does not own files or directories owned by other packages. > Note: Dirs in package are owned also by: /usr/share/doc/libags-doc > (gsequencer-devel-doc, gsequencer-devel-docs), /usr/share/doc/libags- > audio-doc(gsequencer-devel-doc, gsequencer-devel-docs), /usr/share/doc > /libags-audio-doc/api(gsequencer-devel-doc, gsequencer-devel-docs), > /usr/share/doc/libags-gui-doc/api(gsequencer-devel-doc, gsequencer- > devel-docs), /usr/share/doc/libags-doc/api(gsequencer-devel-doc, > gsequencer-devel-docs), /usr/share/doc/libags-gui-doc(gsequencer- > devel-doc, gsequencer-devel-docs), /usr/share/gtk-doc/html(harfbuzz- > devel, gtk-doc) Same as above. And you may have to remove old build results from your Mock buildroot. > [?]: %build honors applicable compiler flags or justifies otherwise. https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags If reading build.log (or compiler output during build stage), does the build pick up the global compiler flags: see "rpm -E %optflags" > [?]: Package contains no bundled libraries without FPC exception. https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries > [?]: Package consistently uses macros (instead of hard-coded directory > names). https://fedoraproject.org/wiki/Packaging:Guidelines#Macros > [?]: Package is named according to the Package Naming Guidelines. https://fedoraproject.org/wiki/Packaging:Guidelines#Naming > [?]: Package does not generate any conflict. A tough one to check. If not installing files with too generic file names into common paths, such as %_bindir or %_libdir, the risk of causing conflicts is low. In case of doubt, one may query the remote repos with "dnf" or "repoquery" to see whether any other packages provide files with the same path. > [?]: Package obeys FHS, except libexecdir and /usr/target. https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout > [?]: Useful -debuginfo package or justification otherwise. https://fedoraproject.org/wiki/Packaging:Guidelines#Debuginfo_packages > [?]: Package is not known to require an ExcludeArch tag. https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Build_Failures > [?]: Large documentation must go in a -doc subpackage. Large could be size > (~1MB) or number of files. > Note: Documentation size is 153600 bytes in 3 files. This guideline is about splitting off "large or huge documentation". See Review Guidelines and https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#PackageDocumentation > [?]: Package complies to the Packaging Guidelines The tough catch-all. > [?]: If the source package does not include license text(s) as a separate > file from upstream, the packager SHOULD query upstream to include it. No issue. License terms are included. It refers to: https://fedoraproject.org/wiki/Packaging:Guidelines#Licensing > [?]: Final provides and requires are sane (see attachments). This about the RPM Requires and Provides in the built packages. One can query them, examine them and/or test them. > [?]: Fully versioned dependency in subpackages if applicable. > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in > gsequencer-debuginfo , gsequencer-devel-doc The -debuginfo package is generated automatically by rpmbuild. The -doc subpackages usually don't need to depend on the base package if the documentation can be viewed with an arbitrary file viewer. It would be a different case, if they could only be displayed within the "gsequencer" program. > [?]: Scriptlets must be sane, if used. https://fedoraproject.org/wiki/Packaging:Guidelines#Scriptlets > [?]: Package should compile and build into binary rpms on all supported > architectures. https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support > [?]: Packages should try to preserve timestamps of original installed > files. https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps > [?]: Large data in /usr/share should live in a noarch subpackage if package > is arched. > Note: Arch-ed rpms have a total of 9093120 bytes in /usr/share If the data files are not arch-specific, one may split off huge data files into a subpackage that sets "BuildArch: noarch" and can copy the same noarch.rpm for all target repos. 9 MB isn't so large IMO. There are much larger data packages in the distribution. -- 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