Spec URL: https://pcpa.fedorapeople.org/brial.spec SRPM URL: https://pcpa.fedorapeople.org/brial-0.8.5-1.fc26.src.rpm Description: The core of PolyBoRi is a C++ library, which provides high-level data types for Boolean polynomials and monomials, exponent vectors, as well as for the underlying polynomial rings and subsets of the powerset of the Boolean variables. As a unique approach, binary decision diagrams are used as internal storage type for polynomial structures. On top of this C++-library we provide a Python interface. This allows parsing of complex polynomial systems, as well as sophisticated and extendable strategies for Gröbner base computation. PolyBoRi features a powerful reference implementation for Gröbner basis computation. Fedora Account System Username: pcpa
I will take this review.
Issues ====== 1. This is causing some problems: checking size of void *... 0 checking size of int... 0 checking size of long... 0 If you look through the build log, you'll see warnings about casting between pointers and integers of a different size. This is due to the configure failure above. The problem seems to be that the configure checks are linked with $RPM_LD_FLAGS, but compiled without %{optflags}, so the link step fails due to bad relocations. The problem is this line in the spec file: export CXXFLAGS="$CXXFLAGS -std=c++98" At that point, CXXFLAGS has not been set, so the $CXXFLAGS inside quotes is the empty string, resulting in CXXFLAGS set to " -std=c++98". Do this instead: export CXXFLAGS="%{optflags} -std=c++98" 2. The license field reflects the final binary contents. Since the GPL, both versions 2 and 3, subsumes BSD, it is permissible make the license field read simply "GPLv2+" if you wish. Otherwise, you need to document the multiple license scenario in the spec file. See https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Multiple_Licensing_Scenarios 3. In the review below, I presume that polybori will be retired. For example, I don't mark that this package causes conflicts. It does, but that will be handled by removing polybori. However, that means that the "Conflicts" tag in the -devel package should be removed. Instead, add "Obsoletes" and "Provides" tags to each package as described here: https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages 4. The rpmlint output shows some unused direct library dependencies. I like to do this after the %configure step to remove both rpaths and such unused dependencies: # Get rid of undesirable hardcoded rpaths, and workaround libtool reordering # -Wl,--as-needed after all the libraries. sed -e 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' \ -e 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' \ -e 's|CC="\(g..\)"|CC="\1 -Wl,--as-needed"|' \ -i libtool It is not enough to add -Wl,--as-needed to LDFLAGS, unfortunately, since libtool has a long-standing bug where it reorders -Wl,--as-needed AFTER all of the libraries, where it does no good at all. 5. The changelog remarks that the python sources have been prepared for python 3. Is it possible to make both python 2 and python 3 subpackages? Also, see https://fedoraproject.org/wiki/Packaging:Python for information on the %python_provide macro. 6. Note the rpmlint complaint about mixed use of space and tabs. Choose one. 7. I don't like the summary line. Yes, this is a replacement for polybori, but what does it DO? Maybe reuse the polybori summary line: "Framework for Boolean Rings". Along those lines, I think the description is confusing, since it mentions polybori, but not brial. 8. What version of cudd is bundled? The Provides line should indicate that; e.g., "Provides: bundled(cudd) = 2.5.1". Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated ===== MUST items ===== C/C++: [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. [!]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [x]: Package does not own files or directories owned by other packages. Note: Dirs in package are owned also by: /usr/include/polybori/ring (polybori-devel), /usr/include/polybori/iterators(polybori-devel), /usr/include/polybori/diagram(polybori-devel), /usr/include/polybori/orderings(polybori-devel), /usr/include/polybori/factories(polybori-devel), /usr/include/polybori/cudd(polybori-devel), /usr/include/polybori/common(polybori-devel), /usr/include/polybori (polybori-devel), /usr/include/polybori/literals(polybori-devel), /usr/include/polybori/cache(polybori-devel), /usr/include/polybori/except(polybori-devel), /usr/include/polybori/groebner(polybori-devel), /usr/include/polybori/routines(polybori-devel) [!]: %build honors applicable compiler flags or justifies otherwise. [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. [!]: Useful -debuginfo package or justification otherwise. This is due to the CXXFLAGS snafu described above. [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 40960 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]: 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 Python: [x]: Python eggs must not download any dependencies during the build process. [-]: A package which is used by another package via an egg interface should provide egg info. [x]: Package meets the Packaging Guidelines::Python [x]: Package contains BR: python2-devel or python3-devel [x]: Binary eggs must be removed in %prep ===== 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. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: 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]: Package should compile and build into binary rpms on all supported architectures. [!]: %check is present and all tests pass. [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: brial-0.8.5-1.fc26.x86_64.rpm brial-devel-0.8.5-1.fc26.x86_64.rpm python-brial-0.8.5-1.fc26.x86_64.rpm brial-debuginfo-0.8.5-1.fc26.x86_64.rpm brial-0.8.5-1.fc26.src.rpm brial.x86_64: W: name-repeated-in-summary C BRiAl brial.x86_64: W: spelling-error %description -l en_US monomials -> binomials brial.x86_64: W: spelling-error %description -l en_US powerset -> power set, power-set, Powers brial-devel.x86_64: W: only-non-binary-in-usr-lib python-brial.x86_64: W: no-documentation brial.src: W: name-repeated-in-summary C BRiAl brial.src: W: spelling-error %description -l en_US monomials -> binomials brial.src: W: spelling-error %description -l en_US powerset -> power set, power-set, Powers brial.src:8: W: unversioned-explicit-provides bundled(cudd) brial.src:9: W: mixed-use-of-spaces-and-tabs (spaces: line 9, tab: line 1) 5 packages and 0 specfiles checked; 0 errors, 10 warnings. Rpmlint (debuginfo) ------------------- Checking: brial-debuginfo-0.8.5-1.fc26.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. Rpmlint (installed packages) ---------------------------- brial.x86_64: W: name-repeated-in-summary C BRiAl brial.x86_64: W: spelling-error %description -l en_US monomials -> binomials brial.x86_64: W: spelling-error %description -l en_US powerset -> power set, power-set, Powers brial.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libbrial_groebner.so.0.0.0 /lib64/libpng16.so.16 brial-devel.x86_64: W: only-non-binary-in-usr-lib python-brial.x86_64: W: no-documentation 4 packages and 0 specfiles checked; 0 errors, 6 warnings. Requires -------- brial (rpmlib, GLIBC filtered): /sbin/ldconfig libbrial.so.0()(64bit) libc.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libm.so.6()(64bit) libm4ri-0.0.20140914.so()(64bit) libpng16.so.16()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) rtld(GNU_HASH) brial-devel (rpmlib, GLIBC filtered): boost-devel(x86-64) brial(x86-64) libbrial.so.0()(64bit) libbrial_groebner.so.0()(64bit) brial-debuginfo (rpmlib, GLIBC filtered): python-brial (rpmlib, GLIBC filtered): brial(x86-64) python(abi) Provides -------- brial: brial brial(x86-64) bundled(cudd) libbrial.so.0()(64bit) libbrial_groebner.so.0()(64bit) brial-devel: brial-devel brial-devel(x86-64) brial-debuginfo: brial-debuginfo brial-debuginfo(x86-64) python-brial: python-brial python-brial(x86-64) Source checksums ---------------- https://github.com/BRiAl/BRiAl/releases/download/0.8.5/brial-0.8.5.tar.bz2 : CHECKSUM(SHA256) this package : 44b1b16c7a3c973d0a049d5e8bb8f54bedee5810e0b174acd7ebfc9fa9f2475e CHECKSUM(SHA256) upstream package : 44b1b16c7a3c973d0a049d5e8bb8f54bedee5810e0b174acd7ebfc9fa9f2475e Generated by fedora-review 0.6.1 (f03e4e7) last change: 2016-05-02 Command line :/usr/bin/fedora-review -b 1367526 -m fedora-rawhide-x86_64 Buildroot used: fedora-rawhide-x86_64 Active plugins: Python, Generic, Shell-api, C/C++ Disabled plugins: Java, SugarActivity, fonts, Haskell, Ocaml, Perl, R, PHP Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6
(In reply to Jerry James from comment #2) > Issues > ====== > 1. This is causing some problems: > > checking size of void *... 0 > checking size of int... 0 > checking size of long... 0 > > If you look through the build log, you'll see warnings about casting > between > pointers and integers of a different size. This is due to the configure > failure above. The problem seems to be that the configure checks are > linked > with $RPM_LD_FLAGS, but compiled without %{optflags}, so the link step > fails > due to bad relocations. The problem is this line in the spec file: > > export CXXFLAGS="$CXXFLAGS -std=c++98" > > At that point, CXXFLAGS has not been set, so the $CXXFLAGS inside quotes > is > the empty string, resulting in CXXFLAGS set to " -std=c++98". Do this > instead: > > export CXXFLAGS="%{optflags} -std=c++98" Fixed, thanks! > 2. The license field reflects the final binary contents. Since the GPL, both > versions 2 and 3, subsumes BSD, it is permissible make the license field > read simply "GPLv2+" if you wish. Otherwise, you need to document the > multiple license scenario in the spec file. See > > https://fedoraproject.org/wiki/Packaging: > LicensingGuidelines#Multiple_Licensing_Scenarios I added a comment about what code is under a BSD like license (Cudd) > 3. In the review below, I presume that polybori will be retired. For > example, > I don't mark that this package causes conflicts. It does, but that will > be > handled by removing polybori. However, that means that the "Conflicts" > tag > in the -devel package should be removed. Instead, add "Obsoletes" and > "Provides" tags to each package as described here: > > https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming. > 2FReplacing_Existing_Packages Ok. Added the proper Obsoletes/Provides. Only sagemath uses it, so, once a sagemath 7.3 package is available, polybori can be retired. > 4. The rpmlint output shows some unused direct library dependencies. I like > to > do this after the %configure step to remove both rpaths and such unused > dependencies: > > # Get rid of undesirable hardcoded rpaths, and workaround libtool reordering > # -Wl,--as-needed after all the libraries. > sed -e 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' \ > -e 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' \ > -e 's|CC="\(g..\)"|CC="\1 -Wl,--as-needed"|' \ > -i libtool > > It is not enough to add -Wl,--as-needed to LDFLAGS, unfortunately, since > libtool has a long-standing bug where it reorders -Wl,--as-needed AFTER > all > of the libraries, where it does no good at all. Thanks. Changed to use the suggested pattern, that indeed corrects the problem. On not yet released versions it should actually make use of gd and png. > 5. The changelog remarks that the python sources have been prepared for > python > 3. Is it possible to make both python 2 and python 3 subpackages? Also, > see https://fedoraproject.org/wiki/Packaging:Python for information on the > %python_provide macro. I believe this is more of something to ask upstream, it explicitly requires python 2.7: AM_PATH_PYTHON([2.7]) so, I believe this is a work in progress by upstream. > 6. Note the rpmlint complaint about mixed use of space and tabs. Choose one. Corrected. Was a bad cut&paste. > 7. I don't like the summary line. Yes, this is a replacement for polybori, > but what does it DO? Maybe reuse the polybori summary line: "Framework > for > Boolean Rings". Along those lines, I think the description is confusing, > since it mentions polybori, but not brial. I used the sagemath SPKG.txt text, but indeed it was not looking right. Now it was changed the Summary to the same as polybori, and description basically s/PolyBori/BRiAl/. > 8. What version of cudd is bundled? The Provides line should indicate that; > e.g., "Provides: bundled(cudd) = 2.5.1". The code is significantly changed, but appears to be based/forked from 2.5.0, I changed to: # brial-0.8.5/Cudd/cudd/cudd.h:#define CUDD_VERSION "2.5.0" Provides: bundled(cudd) = 2.5.0 > [!]: If the package is under multiple licenses, the licensing breakdown > must be documented in the spec. should be fixed. > [!]: %build honors applicable compiler flags or justifies otherwise. should be fixed. > [!]: If the package is a rename of another package, proper Obsoletes and > Provides are present. should be fixed. > [!]: Useful -debuginfo package or justification otherwise. > This is due to the CXXFLAGS snafu described above. should be fixed. Spec URL: https://pcpa.fedorapeople.org/brial.spec SRPM URL: https://pcpa.fedorapeople.org/brial-0.8.5-2.fc26.src.rpm
A few more fixes to make, all small. See below. (In reply to Paulo Andrade from comment #3) > Ok. Added the proper Obsoletes/Provides. Only sagemath uses it, so, > once a sagemath 7.3 package is available, polybori can be retired. I see Obsoletes/Provides for the -devel package, but not for the main package, nor for the python package. Shouldn't those Obsolete/Provide their polybori equivalents, too? > Thanks. Changed to use the suggested pattern, that indeed corrects the > problem. On not yet released versions it should actually make use of gd > and png. The current code base only uses gd if m4ri has not been built with png support (and the Fedora version does have such support). Are you saying that the next version will use gd anyway? > I believe this is more of something to ask upstream, it explicitly requires > python 2.7: > AM_PATH_PYTHON([2.7]) > so, I believe this is a work in progress by upstream. Okay. It would be nice to provide the python 3 version when it is available. > I used the sagemath SPKG.txt text, but indeed it was not looking right. > Now it was changed the Summary to the same as polybori, and description > basically s/PolyBori/BRiAl/. Note that the very last sentence of %description still uses the word PolyBoRi. Also, the bug title needs to match the %summary line before you request package creation. There is no changelog entry in the spec file for your latest version. Summary of changes to be made: 1. Obsoletes/provides for all packages, or a reason why that isn't needed. 2. Change one more instance of "PolyBoRi" in %description. 3. Add a changelog entry to the spec file for version 0.8.5-2. 4. Update the bug title with the current %summary in the spec file.
(In reply to Jerry James from comment #4) > A few more fixes to make, all small. See below. > > (In reply to Paulo Andrade from comment #3) > > Ok. Added the proper Obsoletes/Provides. Only sagemath uses it, so, > > once a sagemath 7.3 package is available, polybori can be retired. > > I see Obsoletes/Provides for the -devel package, but not for the main > package, nor for the python package. Shouldn't those Obsolete/Provide their > polybori equivalents, too? Only brial-devel conflicts with polybori-devel, so at first I preferred to not create an artificial conflict, as runtimes can be installed at the same time. But I can add it, as one doing "serious" work depending on polybori (and not using brial) is likely not using the system package. > > Thanks. Changed to use the suggested pattern, that indeed corrects the > > problem. On not yet released versions it should actually make use of gd > > and png. > > The current code base only uses gd if m4ri has not been built with png > support (and the Fedora version does have such support). Are you saying > that the next version will use gd anyway? I was going to ask upstream, but it was already asked :( https://github.com/BRiAl/BRiAl/issues/6 > > I believe this is more of something to ask upstream, it explicitly requires > > python 2.7: > > AM_PATH_PYTHON([2.7]) > > so, I believe this is a work in progress by upstream. > > Okay. It would be nice to provide the python 3 version when it is available. Ok. The code is there, so upstream is more of in a waiting for contributions as well. Something to do, but likely, upstream sagemath is who has more resources for it. > > I used the sagemath SPKG.txt text, but indeed it was not looking right. > > Now it was changed the Summary to the same as polybori, and description > > basically s/PolyBori/BRiAl/. > > Note that the very last sentence of %description still uses the word > PolyBoRi. Thanks! Fixed. > Also, the bug title needs to match the %summary line before you request > package creation. Also fixed. > There is no changelog entry in the spec file for your latest version. Ops, sorry, fixed. > Summary of changes to be made: > 1. Obsoletes/provides for all packages, or a reason why that isn't needed. > 2. Change one more instance of "PolyBoRi" in %description. > 3. Add a changelog entry to the spec file for version 0.8.5-2. > 4. Update the bug title with the current %summary in the spec file. I can make a new srpm with Obsoletes/Provides for the "non conflicting" polybori packages, as otherwise they may sit without use on a system being updated from a previous sagemath version, but should it also Obsoletes/Provides the other polybori packages that brial does not (yet) have an alternative? Those are polybori-gui polybori-docs polybori-static # on purpose there is no alternative polybori-ipbori Spec URL: https://pcpa.fedorapeople.org/brial.spec SRPM URL: https://pcpa.fedorapeople.org/brial-0.8.5-3.fc26.src.rpm
(In reply to Paulo Andrade from comment #5) > Only brial-devel conflicts with polybori-devel, so at first I > preferred to not create an artificial conflict, as runtimes can > be installed at the same time. But I can add it, as one doing > "serious" work depending on polybori (and not using brial) is > likely not using the system package. [snip] > I can make a new srpm with Obsoletes/Provides for the > "non conflicting" polybori packages, as otherwise they may > sit without use on a system being updated from a previous > sagemath version, but should it also Obsoletes/Provides > the other polybori packages that brial does not (yet) have > an alternative? Those are > polybori-gui > polybori-docs > polybori-static # on purpose there is no alternative > polybori-ipbori Yes, we are going to remove polybori from the distribution, so we shouldn't leave unsupported RPMs on people's machines. So the main brial package should Obsoletes/Provides all of those. If you like, leave yourself a note that the Obsoletes/Provides can all be removed once Fedora 25 reaches EOL. I'm going to approve this package now. You can fix up the Obsoletes/Provides when you import the package.
Thanks! I am adding this to the spec: # FIXME This full block, as well as other Provides/Obsoletes # can be removed once f25 reaches EOL # Obsolete unsupported/unused packages that may be left after an # update from previous sagemath package versions. # NOTE that the Provides is just to remove polybori, as besides # the -static not generated on purpose, the others do not yet # have a real provides from upstream, as noted at # https://github.com/BRiAl/BRiAl/issues/6 Obsoletes: polybori-gui <= %{version}-1 Provides: polybori-gui <= %{version}-1 Obsoletes: polybori-docs <= %{version}-1 Provides: polybori-docs <= %{version}-1 Obsoletes: polybori-static <= %{version}-1 Provides: polybori-static <= %{version}-1 Obsoletes: polybori-ipbori <= %{version}-1 Provides: polybori-ipbori <= %{version}-1 # END FIXME
Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/brial
brial-0.8.5-4.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f426f272fe
brial-0.8.5-4.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-f426f272fe
brial-0.8.5-4.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.