Bug 1367526

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.