https://bugzilla.redhat.com/show_bug.cgi?id=1282893 --- Comment #20 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- warning: bogus date in %changelog: Wed Dec 19 2015 Marcin Dulak <Marcin.Dulak@xxxxxxxxx> 5.1.2-3 quantum-espresso.x86_64: W: incoherent-version-in-changelog 5.1.2-3 ['5.2.1-3.fc24', '5.2.1-3'] > > > * 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. > make %{?_smp_mflags} failed for me Please al least add a comment in the spec file. It would be great to work with upstream to fix parallel compilation, and to be able to run the tests in parallel. > > > * Shouldn't the doc be installed? > I believe nobody reads the docs installed on the system nowadays. I could dispute that. Packaged docs have advantages: they work offline, they don't get out of sync with the package, they are still there if the upstream goes away. But they are not mandatory, so if you don't want to package them that's OK. > + cp -p '%{SOURCE20}' pseudo > cp: cannot stat `%{SOURCE20}': No such file or directory It needs one more expansion level: cp -p %{expand: %{lua: for i=20,41 do print("%{SOURCE"..i.."} ") end}} pseudo/ When running the build, a number of errors appear like this: Checking uspp...[warn] Epoll ADD(4) on fd 1 failed. Old events were 0; read change was 0 (none); write change was 1 (add): Operation not permitted This might be caused by trying to add /dev/null. Cf. the following python transcript: >>> import select >>> p = select.epoll() >>> f = open('/dev/null', 'r') >>> p.register(f.fileno()) Traceback (most recent call last): File "<stdin>", line 1, in <module> PermissionError: [Errno 1] Operation not permitted It fails with the same error code. Maybe the warning in tests is harmless, maybe not, please investigate that. rpmlint: quantum-espresso.x86_64: W: spelling-error %description -l en_US nanoscale -> nanosecond quantum-espresso.x86_64: W: spelling-error %description -l en_US pseudopotentials -> pseudo potentials, pseudo-potentials, potentials False positives. quantum-espresso.x86_64: W: no-documentation quantum-espresso.x86_64: W: no-manual-page-for-binary ... OK. quantum-espresso-debuginfo.x86_64: E: script-without-shebang /usr/src/debug/espresso-5.2.1/TDDFPT/src/... Since this is only in the debug package, it's OK. You created the q-e-common subpackage. It has only one file, which is a few kilobytes. I think it would be totally fine to package this file in the main package, the savings are not worth the overhead of having another subpackage. >> > * 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? > >iotk is required by http://www.yambo-code.org/ >Unbundling iotk would require some work, and I'm not willing to do this >without the support from quantum-espresso developers. >Yambo is currently hosted on qe-forge >http://qe-forge.org/gf/project/yambo/frs/?action=FrsReleaseBrowse&frs_package_id=40 >which means that it's probably related to quantum-espresso and when packaging yambo one could just BuildRequires: >quantum-espresso-{openmpi,static}-devel and quantum-espresso-{openmpi,static}-static You should build iotk as a shared library. This is very strongly encouraged [https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries]. IS there a good reason to build iotk as a static lib? -- 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