Spec URL: http://copr-dist-git.fedorainfracloud.org/cgit/talcite/qcint/qcint.git/tree/qcint.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/talcite/qcint/fedora-rawhide-x86_64/00391206-qcint/qcint-1.8.6-1.fc25.src.rpm Description: Qcint is a branch of libcint library. It provides exactly the same APIs as libcint. However, the code is optimized against SSE3 instructions. On x86_64 platform, qcint can be 5 ~ 50% faster than libcint. Please refer to libcint for more details of the features and installation instructions. Fedora Account System Username: talcite
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated ===== MUST items ===== C/C++: [-]: Provides: bundled(gnulib) in place as required. Note: Sources not installed [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: Header files in -devel subpackage, if present. [x]: ldconfig called in %post and %postun if required. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. [x]: Development (unversioned) .so files in -devel subpackage, if present. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. [x]: License file installed when any subpackage combination is installed. [x]: %build honors applicable compiler flags or justifies otherwise. - There is an extra "-O2 -g -DNDEBUG -fPIC" in the build flags. See if you can remove the unnecessary part. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [x]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [-]: Package is not known to require an ExcludeArch tag. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 20480 bytes in 2 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [x]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in libcint- debuginfo [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Scriptlets must be sane, if used. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [?]: Package should compile and build into binary rpms on all supported architectures. [!]: %check is present and all tests pass. - There are a few failing tests, please have a look. 1: * FAIL: cint2e_sph . err: 5.255133146420121e-07 / 56243.8832877 1: * FAIL: cint2e_ig1_sph . err: 3.765482688322663e-06 / 8101.0873344 1: * FAIL: cint2e_ip1_sph . err: 1.087461714632809e-05 / 115489.864387 1: * FAIL: cint2e_p1vxp1_sph . err: 6.967771332710981e-05 / 89014.8816974 1: * FAIL: 3 3 5.64582721316e-13 1: * FAIL: 7 7 7.53562844163e-14 2: * FAIL: cint3c2e_sph . err: 1.300577423535287e-10 / 1586.35079743 2: * FAIL: cint3c2e_ip1_sph . err: 6.803020369261503e-10 / 2242.05224927 2: * FAIL: cint3c2e_ip2_sph . err: 5.302354111336172e-10 / 1970.98248386 The latter ones are probably fine, but the first four look a bit too big. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Uses parallel make %{?_smp_mflags} macro. [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: libcint-2.8.6-1.fc24.x86_64.rpm libcint-devel-2.8.6-1.fc24.x86_64.rpm libcint-debuginfo-2.8.6-1.fc24.x86_64.rpm libcint-2.8.6-1.fc24.src.rpm libcint.x86_64: W: spelling-error %description -l en_US analytical -> analytically, analytic, catalytic libcint.x86_64: W: spelling-error %description -l en_US spheric -> spherical, hemispheric libcint.x86_64: W: spelling-error %description -l en_US spinor -> spin or, spin-or, Spinoza The proper spelling is, indeed, real-spherical, not real-spheric. libcint.x86_64: W: incoherent-version-in-changelog 2.8.6 ['2.8.6-1.fc24', '2.8.6-1'] libcint.x86_64: W: shared-lib-calls-exit /usr/lib64/libcint.so.2.8 exit.5 libcint-devel.x86_64: W: only-non-binary-in-usr-lib libcint-devel.x86_64: W: no-documentation libcint.src: W: spelling-error %description -l en_US analytical -> analytically, analytic, catalytic libcint.src: W: spelling-error %description -l en_US spheric -> spherical, hemispheric libcint.src: W: spelling-error %description -l en_US spinor -> spin or, spin-or, Spinoza libcint.src:12: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 12) 4 packages and 0 specfiles checked; 0 errors, 11 warnings. And the same thing here. You must also fix the spaces-vs-tabs issue. Rpmlint (debuginfo) ------------------- Checking: libcint-debuginfo-2.8.6-1.fc24.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. Rpmlint (installed packages) ---------------------------- sh: /usr/bin/python: No such file or directory libcint.x86_64: W: spelling-error %description -l en_US analytical -> analytically, analytic, catalytic libcint.x86_64: W: spelling-error %description -l en_US spheric -> spherical, hemispheric libcint.x86_64: W: spelling-error %description -l en_US spinor -> spin or, spin-or, Spinoza libcint.x86_64: W: incoherent-version-in-changelog 2.8.6 ['2.8.6-1.fc24', '2.8.6-1'] libcint.x86_64: W: shared-lib-calls-exit /usr/lib64/libcint.so.2.8 exit.5 libcint-devel.x86_64: W: only-non-binary-in-usr-lib libcint-devel.x86_64: W: no-documentation 3 packages and 0 specfiles checked; 0 errors, 7 warnings. Requires -------- libcint (rpmlib, GLIBC filtered): /sbin/ldconfig libc.so.6()(64bit) libtatlas.so.3()(64bit) rtld(GNU_HASH) libcint-debuginfo (rpmlib, GLIBC filtered): libcint-devel (rpmlib, GLIBC filtered): libcint(x86-64) libcint.so.2.8()(64bit) Provides -------- libcint: libcint libcint(x86-64) libcint.so.2.8()(64bit) libcint-debuginfo: libcint-debuginfo libcint-debuginfo(x86-64) libcint-devel: libcint-devel libcint-devel(x86-64) Source checksums ---------------- https://github.com/sunqm/libcint/archive/v2.8.6.tar.gz : CHECKSUM(SHA256) this package : 48b681a2b758cf5c3ffd5c69e3a33feb3a57f5f15342f971354c7d746948eeeb CHECKSUM(SHA256) upstream package : 48b681a2b758cf5c3ffd5c69e3a33feb3a57f5f15342f971354c7d746948eeeb
Whoops, wrong bug. qcint review still to follow. Note that your version of qcint is wrong in the specfile. It should be 2.8.6, not 1.8.6. Then you can also get rid of the -n qcint-2.8.6 in %setup.
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated ===== MUST items ===== C/C++: [-]: Provides: bundled(gnulib) in place as required. Note: Sources not installed [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: Header files in -devel subpackage, if present. [x]: ldconfig called in %post and %postun if required. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. [x]: Development (unversioned) .so files in -devel subpackage, if present. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [!]: License field in the package spec file matches the actual license. - License is not GPLv3, but GPLv3+. [x]: License file installed when any subpackage combination is installed. [x]: %build honors applicable compiler flags or justifies otherwise. - There are some extra flags here as well: "-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -msse3 -O2 -funroll-loops -ftree-vectorize -ffast-math -O2 -g" but the optimization level -O2 isn't overridden so that's OK. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Macros in Summary, %description expandable at SRPM build time. [-]: Package contains desktop file if it is a GUI application. [x]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 10240 bytes in 2 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [x]: Fully versioned dependency in subpackages if applicable. [?]: Package functions as described. [-]: %check is present and all tests pass. - No tests are included. Please query upstream if the tests from libcint could be included in qcint as well, since the packages are supposed to be API compatible. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Scriptlets must be sane, if used. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Uses parallel make %{?_smp_mflags} macro. [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Package should compile and build into binary rpms on all supported architectures. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: qcint-1.8.6-1.fc24.x86_64.rpm qcint-devel-1.8.6-1.fc24.x86_64.rpm qcint-debuginfo-1.8.6-1.fc24.x86_64.rpm qcint-1.8.6-1.fc24.src.rpm qcint.x86_64: W: shared-lib-calls-exit /usr/lib64/libcint.so.1.8 exit.5 qcint-devel.x86_64: W: only-non-binary-in-usr-lib qcint-devel.x86_64: W: no-documentation qcint.src: W: spelling-error Summary(en_US) libcint -> Clint qcint.src: W: spelling-error %description -l en_US libcint -> Clint qcint.src:13: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 13) 4 packages and 0 specfiles checked; 0 errors, 6 warnings. Rpmlint (debuginfo) ------------------- Checking: qcint-debuginfo-1.8.6-1.fc24.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. Rpmlint (installed packages) ---------------------------- sh: /usr/bin/python: No such file or directory qcint-devel.x86_64: W: only-non-binary-in-usr-lib qcint-devel.x86_64: W: no-documentation qcint.x86_64: W: shared-lib-calls-exit /usr/lib64/libcint.so.1.8 exit.5 3 packages and 0 specfiles checked; 0 errors, 3 warnings. Requires -------- qcint-debuginfo (rpmlib, GLIBC filtered): qcint-devel (rpmlib, GLIBC filtered): libcint.so.1.8()(64bit) qcint(x86-64) qcint (rpmlib, GLIBC filtered): /sbin/ldconfig libc.so.6()(64bit) libtatlas.so.3()(64bit) rtld(GNU_HASH) Provides -------- qcint-debuginfo: qcint-debuginfo qcint-debuginfo(x86-64) qcint-devel: qcint-devel qcint-devel(x86-64) qcint: libcint.so.1.8()(64bit) qcint qcint(x86-64) Source checksums ---------------- https://github.com/sunqm/qcint/archive/v2.8.6.tar.gz : CHECKSUM(SHA256) this package : 7fd421a2b1c5f6198edac490372947be760d936ee53adabe02441dafcda0899e CHECKSUM(SHA256) upstream package : 7fd421a2b1c5f6198edac490372947be760d936ee53adabe02441dafcda0899e
Ping Matt
Sorry, I just got back from vacation. Still working through a backlog. I'll get the corrected specfiles to you on Monday? The version number on Qcint is correct according to Qiming. Right now qcint and libcint have differing version numbers, but he's planning on synchronizing them in a future major release. I have a question related to PySCF (which depends on qcint/libcint) though. Given that qcint is on x86_64 and libcint is i686/arm, and there's only 1 release of PySCF for x86_64, i686, and arm, what do I put in the BuildRequires for PySCF? Or do I build two versions of PySCF, one linked to qcint, the other to libcint? Thanks! Matt
(In reply to Matt Chan from comment #5) > Sorry, I just got back from vacation. Still working through a backlog. I'll > get the corrected specfiles to you on Monday? > > The version number on Qcint is correct according to Qiming. Right now qcint > and libcint have differing version numbers, but he's planning on > synchronizing them in a future major release. > > I have a question related to PySCF (which depends on qcint/libcint) though. > Given that qcint is on x86_64 and libcint is i686/arm, and there's only 1 > release of PySCF for x86_64, i686, and arm, what do I put in the > BuildRequires for PySCF? Or do I build two versions of PySCF, one linked to > qcint, the other to libcint? %ifarch %{ix86} %{arm} BuildRequires: libcint-devel %else BuildRequires: qcint-devel %endif Though I'm not sure about other arches like MIPS, PPC, AArch64, etc. > > Thanks! > Matt
(In reply to Matt Chan from comment #5) > The version number on Qcint is correct according to Qiming. Right now qcint > and libcint have differing version numbers, but he's planning on > synchronizing them in a future major release. But that's not possible: you're using a version 2.8.6 tarball, while you specify version 1.8.6 in the specfile (and work around the discrepancy between your numbering and the tarball by specifying version 2.8.6 in the %setup). > I have a question related to PySCF (which depends on qcint/libcint) though. > Given that qcint is on x86_64 and libcint is i686/arm, and there's only 1 > release of PySCF for x86_64, i686, and arm, what do I put in the > BuildRequires for PySCF? Or do I build two versions of PySCF, one linked to > qcint, the other to libcint? Ideally, you should be able to build everything against libcint, which is cross-platform. Installing pyscf would then pull the necessary integrals library through the soname requires. Because both qcint and libcint provide libcint.so(), either of them can satisfy the library requires from pyscf, and you can switch from one to the other just by installing the package you want: qcint or libcint. Libcint should, however, be the default package to be installed, because qcint doesn't work on all x86_64 machines. I'm not sure how dnf does its dependency resolvement, but if it's the same as with yum then the package with the shortest name will be picked, and that'd be qcint.
(In reply to Susi Lehtola from comment #7) > But that's not possible: you're using a version 2.8.6 tarball, while you > specify version 1.8.6 in the specfile (and work around the discrepancy > between your numbering and the tarball by specifying version 2.8.6 in the > %setup). The github tag is for 2.8.6, which is why the tarball shows up as that. The version in the documentation etc is 1.8.6. I can ask Qiming to retag it? The the tag/version should be fixed in a future release though. > > Ideally, you should be able to build everything against libcint, which is > cross-platform. Installing pyscf would then pull the necessary integrals > library through the soname requires. > > Because both qcint and libcint provide libcint.so(), either of them can > satisfy the library requires from pyscf, and you can switch from one to the > other just by installing the package you want: qcint or libcint. > > Libcint should, however, be the default package to be installed, because > qcint doesn't work on all x86_64 machines. I'm not sure how dnf does its > dependency resolvement, but if it's the same as with yum then the package > with the shortest name will be picked, and that'd be qcint. Hmm so you're saying I should change libcint to build on x86_64 as well, then list it in the pyscf BuildRequires? Alternatively I could do something similar to what Igor suggested? But those few users without SSE3 would have segfaults I think. %ifarch x86_64 BuildRequires: qcint-devel %else BuildRequires: libcint-devel %endif
(In reply to Matt Chan from comment #8) > (In reply to Susi Lehtola from comment #7) > > But that's not possible: you're using a version 2.8.6 tarball, while you > > specify version 1.8.6 in the specfile (and work around the discrepancy > > between your numbering and the tarball by specifying version 2.8.6 in the > > %setup). > > The github tag is for 2.8.6, which is why the tarball shows up as that. The > version in the documentation etc is 1.8.6. I can ask Qiming to retag it? The > the tag/version should be fixed in a future release though. Then I think the version is 2.8.6, not 1.8.6. > > Libcint should, however, be the default package to be installed, because > > qcint doesn't work on all x86_64 machines. I'm not sure how dnf does its > > dependency resolvement, but if it's the same as with yum then the package > > with the shortest name will be picked, and that'd be qcint. > > Hmm so you're saying I should change libcint to build on x86_64 as well, > then list it in the pyscf BuildRequires? AFAIK libcint shouldn't have ExclusiveArch, only ExcludeArch for those architectures it doesn't build on... Namely those that are lacking some of the buildrequirements. > Alternatively I could do something similar to what Igor suggested? But those > few users without SSE3 would have segfaults I think. > > %ifarch x86_64 > BuildRequires: qcint-devel > %else > BuildRequires: libcint-devel > %endif This won't do anything, since the library soname is the same in both. The package would get built against qcint, but when a user installs the package they might already have libcint installed and so the package would use that. The only two possible solutions to this are: - qcint and libcint ship libraries with different sonames, e.g. libqcint.so and libcint.so => choice of library must be done at compile time - qcint and libcint share the same API and ship with the same soname => user may pick which package to install Actually, there IS a way to circumvent the excludes. Namely, install the libraries in a directory outside the usual library path, and use e.g. the alternatives system to pick which implementation should be used. Another choice would be the environment modules system, which is currently used for MPI software. But here I think the benefit is rather limited, since a user will prefer qcint over libcint if it just runs on your hardware.
Ping Matt, any progress? PS. How're you coming along with pyscf? I'd like to see it in the distro.
A precedent for something SSE3-specific is ATLAS. I'd have thought this should be treated the same way (and probably there should be policy defined for this sort of thing in the sad absence of hardware capabilities defined for x86 SIMD).
(In reply to Dave Love from comment #11) > A precedent for something SSE3-specific is ATLAS. I'd have thought this > should > be treated the same way (and probably there should be policy defined for this > sort of thing in the sad absence of hardware capabilities defined for x86 > SIMD). What do you mean? Is ATLAS compiled as SSE3-only on x86_64?
(In reply to Susi Lehtola from comment #12) > What do you mean? Is ATLAS compiled as SSE3-only on x86_64? # repoquery atlas-\* atlas-0:3.8.4-2.el6.i686 atlas-0:3.8.4-2.el6.x86_64 atlas-3dnow-0:3.8.4-2.el6.i686 atlas-3dnow-devel-0:3.8.4-2.el6.i686 atlas-debuginfo-0:3.8.4-2.el6.i686 atlas-debuginfo-0:3.8.4-2.el6.x86_64 atlas-devel-0:3.8.4-2.el6.i686 atlas-devel-0:3.8.4-2.el6.x86_64 atlas-sse-0:3.8.4-2.el6.i686 atlas-sse-devel-0:3.8.4-2.el6.i686 atlas-sse2-0:3.8.4-2.el6.i686 atlas-sse2-devel-0:3.8.4-2.el6.i686 atlas-sse3-0:3.8.4-2.el6.i686 atlas-sse3-0:3.8.4-2.el6.x86_64 atlas-sse3-devel-0:3.8.4-2.el6.i686 atlas-sse3-devel-0:3.8.4-2.el6.x86_64 Libraries from two different sources would have to provide the same ABI to treat them like that, of course. It seems best to me to bundle them in one srpm to ensure they're kept in sync anyway.
Yeah, so the default ATLAS package on x86_64 is non-SSE3, but there's a SSE3 variant available, as well. Packaging both within the same srpm is not allowed per the packaging guidelines, as there needs to be a spec per tarball. I believe the ABIs are shared, though.
(In reply to Susi Lehtola from comment #14) > Yeah, so the default ATLAS package on x86_64 is non-SSE3, but there's a SSE3 > variant available, as well. Yes, and it's the ld.so.conf mechanism I think is relevant. > Packaging both within the same srpm is not allowed per the packaging > guidelines, as there needs to be a spec per tarball. I don't see where it says that, though you can only have one URL. > I believe the ABIs are shared, though. Apologies, I was confusing libcint and libint, which already has two versions. [If they're from the same place, I'd have thought it would be more of an argument for bundling source with libcint, but I'm not reviewing it.] Obviously I should stick to pointing out the way hardware-specific versions have been handled. That's relevant for those of us who have to support such things. The way ATLAS does it at least can support heterogeneous HPC systems using a single image on stateless nodes, where the image system can make node-dependent mods to the configuration files. [Not that you should use ATLAS on x86, given OpenBLAS, and you could perhaps handle that HPC case differently.]
(In reply to Dave Love from comment #15) > (In reply to Susi Lehtola from comment #14) > > Yeah, so the default ATLAS package on x86_64 is non-SSE3, but there's a SSE3 > > variant available, as well. > > Yes, and it's the ld.so.conf mechanism I think is relevant. Yeah, I'd just rather avoid the confusion of being able to install both simultaneously and then have to hack the alternatives configuration to figure out which one is actually in use. > > Packaging both within the same srpm is not allowed per the packaging > > guidelines, as there needs to be a spec per tarball. > > I don't see where it says that, though you can only have one URL. I am 99.9% certain this is a rule, i.e., that you can't bundle different projects together into one spec file. And this is exactly the case here: we have the original version and a fork of it, that's SSE3-only. > > I believe the ABIs are shared, though. > > Apologies, I was confusing libcint and libint, which already has two > versions. > [If they're from the same place, I'd have thought it would be more of an > argument for bundling source with libcint, but I'm not reviewing it.] No, libcint and libint are totally different projects. They have similar purpose, though. > Obviously I should stick to pointing out the way hardware-specific versions > have been handled. That's relevant for those of us who have to support > such things. The way ATLAS does it at least can support heterogeneous HPC > systems using a single image on stateless nodes, where the image system > can make node-dependent mods to the configuration files. [Not that you > should use ATLAS on x86, given OpenBLAS, and you could perhaps handle that HPC case > differently.] Well, that's true. But most compute clusters have local operating systems, and it's trivial to pick qcint or libcint on a node basis.
Okay, so between all the delays from my end and Qiming's end, I finally have an updated build. Spec URL: http://copr-dist-git.fedorainfracloud.org/cgit/talcite/qcint/qcint.git/tree/qcint.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/talcite/qcint/fedora-24-x86_64/00453941-qcint/qcint-1.8.6-1.fc24.src.rpm - Qiming changed the version to 1.8.6. I think there was some dependency within PySCF that necessitated it. The two will be in sync eventually. - So if I understand it correctly, the BuildRequires line is only used during initial dependency resolution and builds. If after installing PySCF (which depends on libcint/qcint), I issue "dnf remove libcint; dnf install qcint", it won't remove PySCF? - PySCF is going to take longer to package. It needs somewhat significant changes to become compliant with packaging guidelines. I don't have a lot of downtime left (HORTON's development is picking up) but I'll try to get it done after libcint/qcint get pushed to updates?
Looks good. The review of qcint has been APPROVED
(In reply to Susi Lehtola from comment #18) > Looks good. The review of qcint has been > > APPROVED ... on the condition you fix the License tag as was mentioned in Comment #3.
(In reply to Matt Chan from comment #17) > - Qiming changed the version to 1.8.6. I think there was some dependency > within PySCF that necessitated it. The two will be in sync eventually. Aha. Well, that's fine as long as the soname and soversion is the same between both libraries. > - So if I understand it correctly, the BuildRequires line is only used > during initial dependency resolution and builds. If after installing PySCF > (which depends on libcint/qcint), I issue "dnf remove libcint; dnf install > qcint", it won't remove PySCF? Well, you should just run "dnf install qcint" which should replace libcint; this won't remove PySCF. If you run "dnf remove libcint" then it will remove PySCF. > - PySCF is going to take longer to package. It needs somewhat significant > changes to become compliant with packaging guidelines. I don't have a lot of > downtime left (HORTON's development is picking up) but I'll try to get it > done after libcint/qcint get pushed to updates? OK!
(In reply to Susi Lehtola from comment #19) > (In reply to Susi Lehtola from comment #18) > > Looks good. The review of qcint has been > > > > APPROVED > > ... on the condition you fix the License tag as was mentioned in Comment #3. Hmm? I already changed it to GPLv3+? Just making sure before I push it to updates-testing!
(In reply to Matt Chan from comment #21) > (In reply to Susi Lehtola from comment #19) > > (In reply to Susi Lehtola from comment #18) > > > Looks good. The review of qcint has been > > > > > > APPROVED > > > > ... on the condition you fix the License tag as was mentioned in Comment #3. > > Hmm? I already changed it to GPLv3+? > > Just making sure before I push it to updates-testing! ... You're right - I blame it on the jet lag. Go ahead!
Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/qcint
qcint-1.8.6-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-1fe321e1eb
qcint-1.8.6-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6a2888ecbe
qcint-1.8.6-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-74d77b7c2f
qcint-1.8.6-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-1227b5a8c2
qcint-1.8.6-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1fe321e1eb
qcint-1.8.6-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-1227b5a8c2
qcint-1.8.6-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-74d77b7c2f
qcint-1.8.6-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-6a2888ecbe
qcint-1.8.6-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
qcint-1.8.6-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
qcint-1.8.6-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
qcint-1.8.6-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.