https://bugzilla.redhat.com/show_bug.cgi?id=1282893 --- Comment #11 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- Thanks for tackling this. It seems to be a really complicated package and I can see that a lot of work has gone into putting it in a decent shape. Some issues: openblas is ExclusiveArch x86_64 %{ix86} armv7hl ppc64le, you should probably match that. License tag is wrong. The License tag specifies the *effective* license of the *binary* package [1, 2]. So anything that is not part of the binary rpm (like install/install-sh) doesn't matter at all. If you combine GPLv2+ with BSD or LGPL or MIT, the effective license is GPLv2+. So, if a file in the binary rpm has at least one GPL licensed file, that file is GPL. If a file only had sources with more permissive licenses, than that file would have some other license. So you need to determine the effective license of all files in the binary rpm and put the result in License. I'd guess that the result is going to be License:GPLv2+. [1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License:_field [2] https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F Requires:openmpi and Requires:mpich in the q-e-openmpi and q-e-mpich look wrong to me. Normally the automatically generated dependency would be enough. E.g. q-e-mpich.i686 requires libmpi.so.12(mpich-i386) libmpifort.so.12(mpich-i386) and this should be enough. OTOH, q-e-mpich-devel should probably R: mpich-devel, and q-e-openmpi-devel should probably R: openmpi-devel. Actually, I'd suggest moving all the BuildRequires to the top. Right now it is hard to get an overview of what will be installed in the build root, and some BR are repeated. Why export OMP_NUM_THREADS=1 in %check? Maybe you could use '%{lua: for i=20,41 do print("%{SOURCE" .. i .. "} ") end}' instead of listing all the SOURCExx explicitly in cp? The comments from Dave are also all relevant: (In reply to Dave Love from comment #10) > Created attachment 1107142 [details] > fix requires This looks correct. > * It won't install because it requires an arch-specific -common package; > patch attached. Right. > * I'd have thought iotk should be unbundled, but I don't know if it's of > more general use. Hm, good question. Is it used anywhere else? > * Shouldn't this build against atlas or lapack/blas on non-x86? (ppc64le > seems a plausible architecture to run it on.) I know that makes it > particularly suffer the BLAS mess in Fedora, but scalapack links against > reference blas anyhow. openblas is available on ppc64le. So maybe building everywhere that openblas-devel is avaialable would be enough... > * It's not using the default compilation and linking flags (not that I agree > with that requirement for computational programs). > > * Will smp make not work? There's no comment, and the build takes a while. Yeah, the build takes forever. More threads would be great. > * Why not use elpa? (I haven't tried with this version and the Fedora elpa.) > > * Shouldn't the doc be installed? > > * Would the GUI be useful? (I don't know.) -- 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