One of my upstreams picked up a new documentation dependency. Who would
like to swap reviews? This one should be quick and easy.

python-sphinx-copybutton:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1780426" title="https://bugzilla.redhat.com/show_bug.cgi?id=1780426">https://bugzilla.redhat.com/show_bug.cgi?id=1780426</a>

Thank you,

I will soon build libfplll 5.3.0 in Rawhide, which entails an soname
bump from libfplll.so.5 to libfplll.so.6, even though abipkgdiff
reports no ABI changes. I will rebuild the dependent packages,
gap-pkg-float and python-fpylll. Note that linbox and Macaulay2 also
consume libfplll-static, but since there are no ABI changes, I'll
leave them to their next updates or the mass rebuild, whichever comes
first.

Awhile back, polymake upstream started shipping two new components in
the polymake tarball: JuPyMake (a python interface to polymake) and
jupyter-polymake (a Jupyter kernel for polymake). Even though they
are all shipped in the same tarball, they have different version
numbers. This has made the polymake spec file brittle; pretty much
every automatic update messes up the release numbers and I keep
fumbling them myself with manual updates.

It's a mess. I want to extract those two components from the polymake srpm.

I have hunted down github repos for those two components.

I somehow overlooked the fact that stringtemplate4 was going to be
retired due to having been orphaned. I need it for antlr3, which I
need because the cvc4 project still hasn't migrated to antlr4 (argh!).
I have filed a ticket with releng asking for it to be unretired:

<a href="https://pagure.io/releng/issue/8971" title="https://pagure.io/releng/issue/8971">https://pagure.io/releng/issue/8971</a>

Hi all,

I'm in the midst of the mpfr 4 rebuilds. I just tried to kick off a
long chain build, the first build of which is the final gcc rebuild
that will give us an mpfr 4-using gcc.

An update of mpfr from version 3.1.6 to version 4.0.2 is about to begin in
Rawhide in a side tag:

<a href="https://fedoraproject.org/wiki/Changes/mpfr-4.0.2" title="https://fedoraproject.org/wiki/Changes/mpfr-4.0.2">https://fedoraproject.org/wiki/Changes/mpfr-4.0.2</a>

If you see a "Rebuild for mpfr 4" commit in your package repo, then please
coordinate with me before building your package in Rawhide. If you do need to
build it, please do so in the side tag, like so:

$ fedpkg build --target=f32-mpfr4

A build of mpfr, and 2 builds apiece of libmpc and gcc will be needed before
the other builds can be started.

The upstream download site for the cudd package stopped responding about 8
months ago. About 4 months ago, the DNS entry for the upstream download
site disappeared. Strangely, the author's home page still has a link
pointing to that site.

In any case, nothing in Fedora uses cudd anymore. The cbmc package still
has a BuildRequires for cudd-devel, but doesn't appear to actually use it.
I intend to drop the BR from cbmc and retire cudd in F31 and Rawhide at the
end of this week.

If anybody wants to keep it, let me know.

Hi all,

Recently, at the request of my youngest child, who is in his high
school marching band [1], I took over as maintainer of the mscore
package (MuseScore). I'm working on unbundling some stuff from it.
One of them is a music font:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1753839" title="https://bugzilla.redhat.com/show_bug.cgi?id=1753839">https://bugzilla.redhat.com/show_bug.cgi?id=1753839</a>

I have never attempted to package a font before.

A new version of ntl, 11.3.4, has been released. Since upstream has a
policy of bumping the soname on every release, all dependent package
must be rebuilt. I will take care of all of the rebuilds. (I'm
maintainer or comaintainer on almost all of them, anyway). The builds
will be done in about a week.

The packages to be rebuilt are:
eclib
flint
giac
latte-integrale
linbox
Macaulay2
normaliz
polymake
pynac
sagemath
Singular

In addition, a new version of normaliz (3.8.0) is available. I have
not yet determined if the current versions of polymake and Singular
are compatible with it.

What's this all about (seen after doing a git push to gap-pkg-hecke)?

$ git push
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 690 bytes | 690.00 KiB/s, done.
Total 5 (delta 1), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
remote: * Publishing information for 1 commits
remote: Traceback (most recent call last):
remote: File "/usr/lib/python2.7/site-packages/pagure/hooks/__init__.py",
line 394, in run_project_hooks
remote: changes=changes,
re

I am building qd 2.3.22 in Rawhide right now. The license has been
corrected from "BSD" to "LBNL BSD".

I am about to build gap-pkg-guava 3.15 in Rawhide. This version
changes the license from "GPLv2 or GPLv3" to "GPLv2+", which makes no
practical difference at the moment.

Per the "Claiming Ownership of a Retired Package" checklist, I am
announcing that I wish to unretire the qd package:

<a href="https://pagure.io/releng/issue/8673" title="https://pagure.io/releng/issue/8673">https://pagure.io/releng/issue/8673</a>

It appears to have been one of the packages that was retired recently
due to FTBFS. I maintain the libfplll package, which depends on qd.

I use the default GNOME desktop, using Wayland with Intel graphics. I
have a web browser, a terminal, and an editor running on desktop 1.
On desktop 2 (i.e., where Ctrl-Alt-Down takes you) I have virt-manager
running, with open windows for whichever VMs are currently in use.

Yesterday, I updated my Fedora 30 machine. See the list of updated
packages below. After rebooting into the new kernel, I interacted
with a CentOS 7 VM for maybe 10 minutes. When I moved the mouse
pointer out of the VM window on desktop 2, the pointer vanished.

I just visited <a href="https://bodhi.fedoraproject.org/" title="https://bodhi.fedoraproject.org/">https://bodhi.fedoraproject.org/</a> to check on my updates
in testing. I clicked on my profile. The section named "jjames's
latest updates" used to show me the most recent few updates I have
submitted for stable branches. Now it is completely full of Rawhide
builds. I don't want to see those. They don't require any action
from me. Can we hide those Rawhide updates?

So I clicked on "Testing". That brings up an empty list, showing
"Page 1 of 0". That is wrong. I have one update in Fedora 30 testing
(normaliz and polymake, which is broken...).

I am orphaning some packages I no longer use. None of them need any
immediate maintenance.

abe: a 2-D scrolling platform game. My kids used to play this when
they were little. Now my youngest is going to be a sophomore in high
school in the fall. I'm not quite sure how that happened, but anyway,
nobody at my house plays this game anymore.

meataxe: this used to be a dependency of a couple of components of the
GAP collection of packages, but nowadays everything that needs this
has the algorithms built in.

trinity: this is a kernel system call fuzzer.

I'm working on getting some optional dependencies of sagemath into
Fedora. All of these should be fairly simple reviews. Let me know
what I can review for you in exchange.

gap-pkg-happrime: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1723997" title="https://bugzilla.redhat.com/show_bug.cgi?id=1723997">https://bugzilla.redhat.com/show_bug.cgi?id=1723997</a>
coxeter: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1727498" title="https://bugzilla.redhat.com/show_bug.cgi?id=1727498">https://bugzilla.redhat.com/show_bug.cgi?id=1727498</a>
gap-pkg-forms: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1727499" title="https://bugzilla.redhat.com/show_bug.cgi?id=1727499">https://bugzilla.redhat.com/show_bug.cgi?id=1727499</a>
gap-pkg-hecke: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1727500" title="https://bugzilla.redhat.com/show_bug.cgi?id=1727500">https://bugzilla.redhat.com/show_bug.cgi?id=1727500</a>
gap-pkg-profiling: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1727501" title="https://bugzilla.redhat.com/show_bug.cgi?id=1727501">https://bugzilla.redhat.com/show_bug.cgi?id=1727501</a>
mcqd: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1727502" title="https://bugzilla.redhat.com/show_bug.cgi?id=1727502">https://bugzilla.redhat.com/show_bug.cgi?id=1727502</a>

Thank you!

Is anything happening with introducing MPFR 4 into Fedora? I found these:

<a href="https://fedoraproject.org/wiki/Changes/mpfr-4.0.0" title="https://fedoraproject.org/wiki/Changes/mpfr-4.0.0">https://fedoraproject.org/wiki/Changes/mpfr-4.0.0</a>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1537252" title="https://bugzilla.redhat.com/show_bug.cgi?id=1537252">https://bugzilla.redhat.com/show_bug.cgi?id=1537252</a>

but they indicate that efforts to update have come to a halt. I ask
because I have had to patch 2 of my packages to keep them working with
MPFR 3, and I've got more that are said to work with either version 3
or version 4.

I am willing to put some effort into making the update happen.

I generated a new API key on June 16, and used it. Just now, I tried
to do a fedpkg operation that resulted in the error:

Could not execute request_repo: The following error occurred while
creating a new issue in Pagure: Invalid or expired token. Please visit
<a href="https://pagure.io/settings#api-keys" title="https://pagure.io/settings#api-keys">https://pagure.io/settings#api-keys</a> to get or renew your API token.
For invalid or expired token refer to "fedpkg request-repo -h" to set
a token in your user configuration.

(That URL is not correct, by the way.

Is there any possibility that the new rpmbuild might be responsible
for a change from:

Provides: python-subunit

to:

Provides: python-subunit(architecture)

in a noarch package? See <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1720139" title="https://bugzilla.redhat.com/show_bug.cgi?id=1720139">https://bugzilla.redhat.com/show_bug.cgi?id=1720139</a>.

The drabt package was only ever needed for the cvc4 %check script.
The latest release of cvc4, which I am about to build, no longer uses
drabt. Nothing else in Fedora needs it, so I intend to retire it next
week. If you want it, let me know.

It's time for another game of "my package just grew some new
dependencies." I need reviews for the following and am willing to do
reviews in exchange:

1. catch2: a C++ header-only test framework for unit tests
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1718597" title="https://bugzilla.redhat.com/show_bug.cgi?id=1718597">https://bugzilla.redhat.com/show_bug.cgi?id=1718597</a>

2. cli11: a header-only command line parser for C++11
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1718598" title="https://bugzilla.redhat.com/show_bug.cgi?id=1718598">https://bugzilla.redhat.com/show_bug.cgi?id=1718598</a>

3. drat-trim: a proof checker for DIMACS proofs
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1718599" title="https://bugzilla.redhat.com/show_bug.cgi?id=1718599">https://bugzilla.redhat.com/show_bug.cgi?id=1718599</a>

4.

In a few days, I intend to update coq to version 8.9.1 in Rawhide, and
also update all of the packages that depend on it. The why package
has been abandoned by upstream. Its latest version does not work with
the latest versions of its dependent packages (why3 and frama-c), and
upstream has no intention of fixing it. I intend to retire it when I
do the updates. If somebody wants it, let me know, but be aware that
you will effectively have to become upstream.

Where should problem reports with the test machines be directed? I
can't build for Rawhide in mock on arm03-packager00 because
/etc/mock/fedora-rawhide-armhfp.cfg refers to Fedora 30. The correct
config is in /etc/mock/fedora-rawhide-armhfp.cfg.rpmnew. Can somebody
with admin privileges fix that up, please?

In the meantime, I'll just make my own copy of the config and move on,
but that really should be fixed.

Thanks,

I finally found some time to look at the xindy failure to build.
First, let me say that I've got a workaround for the problem, which
resulted in the beautiful green colors in this xindy-enabled scratch
build of texlive-base:

<a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270">https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270</a>

When the build process reached the xindy part of the build, it would
successfully build xindy itself, then go to work on some
documentation.

I'm building normaliz 3.7.2 for Rawhide. It changes the soname from
libnormaliz.so.0 to libnormaliz.so.3. The only dependent package is
polymake, which I am rebuilding.

Awhile back, I mentioned that GCL was building in mock on my local
machine, but was segfaulting on the koji builders. By dint of much
experimentation, I now know what is going on. For the enlightenment
of anybody who cares:

- GCL is linked with libtirpc.
- libtirpc is linked with libselinux.
- libselinux has a "constructor" function, init_lib(), that runs before main().
- init_lib() calls init_selinuxmnt()
- init_selinuxmnt() checks that /sys/fs/selinux exists, has type
SELINUX_MAGIC (see statfs(2)), and is not read-only.

I had two packages pass review a couple of weeks ago. However, my
requests for repos were closed as invalid because "The PDC branch
already exists". I reopened the tickets with a request for more
information, but they just got closed again with the same message,
which tells me that humans are not reading these, so there's no point
in opening them again.

I ask because the gcl build is failing on every architecture. The gcl
binary segfaults immediately after it is linked in the first stage,
which is what happens if I try to build in mock on my local machine
with SELinux in enforcing mode. But if I put SELinux into permissive
mode, I can build successfully in mock.

<a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=33751679" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=33751679">https://koji.fedoraproject.org/koji/taskinfo?taskID=33751679</a>

Thanks,

I was just looking at reviewing this package:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1684950" title="https://bugzilla.redhat.com/show_bug.cgi?id=1684950">https://bugzilla.redhat.com/show_bug.cgi?id=1684950</a>

It is a Go wrapper around ffprobe, which is in the ffmpeg package,
which is in rpmfusion-free. The package can be built without ffprobe,
but cannot be used without it. The spec file contains this:

# We can't have a hard dependency because patents
Recommends: ffmpeg

Really, this package should have "Requires: ffmpeg", because it cannot
be used at all without ffprobe.