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.

I have been working on an update for coq 8.9.0 in Rawhide. A mock
build fails when building the documentation:

Latexmk: applying rule 'makeindex CoqRefMan.idx'...

The dependency on xindy comes from Sphinx.

Was the apparently in-progress readline 8.0 rebase announced
somewhere? All I can recall seeing is [1], which said, 3.5 weeks ago,
that the rebase would happen "in a couple of weeks". But apparently
there is a side tag and builds are in progress.

I would have appreciated a heads-up on this. I chose this weekend,
when I get an extra day off of work, to do the big gap 4.10.0 and
sagemath 8.6 updates. But in between the bootstrap build of gap
4.10.0 and the final build of it, a readline rebuild, into the side
tag, happened. Now what am I supposed to do?

Hi all,

Sagemath 8.6 is out, which means that at long last we can upgrade the
gap package. Upgrading gap means dealing with the fact that some of
the fundamental group libraries have now been split out of the main
package and have their own upstream repositories.

The following commands are executed on an x86_64 Fedora 29 machine.
What am I doing wrong?

$ dnf repoquery --srpm --whatrequires python2-repoze-sphinx-autointerface
enabling fedora-modular-source repository
enabling updates-modular-source repository
enabling updates-source repository
enabling fedora-source repository
Last metadata expiration check: 0:13:21 ago on Sat 24 Nov 2018 09:19:28 AM MST.
$ dnf repoquery --srpm --requires python2-BTrees
enabling fedora-modular-source repository
enabling updates-modular-source repository
enabling updates-source repository
enabling fedora-source reposito

Hi folks,

It's about time for another "update the world" moment for some of the
mathematical software we have in Fedora. I'm going to try to clear
away a big chunk of my backlogged package work with this update, so it
will be even bigger than usual. Primary goals are to switch from
atlas or the reference blas to openblas, and to drop python 2
packages.

I plan to do all of the necessary rebuilds myself. Package
maintainers, if you would rather that I did not rebuild your package
for you, please let me know. Otherwise, I will do all of these builds
in approximately 1 week from today.

I am trying to determine why the latest version of bigloo segfaults on
s390x during the build. I launched a mock build with mock -r
fedora-rawhide-s390x --forcearch=s390x --rebuild
bigloo-4.3c-1.fc30.src.rpm, then went away for several hours.

Koji seems to be requiring 7 days in -testing for F29. Shouldn't it
be requiring 3 days at this point?

We're heading for a Fedora 29 release with a broken coq/frama-c/why3
stack. I've got fixes waiting in the wings, but they're blocked on
these antlr4 bugs:

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

Time is running out, and the antlr4 maintainer clearly doesn't have
time to do anything about the situation. I don't have the bandwidth
to just jump in and take over. Is there anybody who can help with the
2 new Java packages required to upgrade antlr4, and the actual upgrade
itself?

I just saw a remark on another mailing list about an updated version
of a package I maintain. Sure enough, a new version was released, but
I never got email from release-monitoring.org about it. So I started
checking, and I've got nearly 2 dozen packages with new versions
upstream, but nary an email about it.

It looks like something might be broken with monitoring github. None
of the new versions have shown up on release-monitoring.org, and they
all show errors in the logs.

Bugs have been filed asking packagers to build with openblas instead
of atlas. But there are multiple openblas libraries.

I've accumulated another set of package updates for the
sagemath/Macaulay2 set of packages. I would like to build these in
Rawhide in about a week. Here are the proposed changes. Please let
me know of any objections. I believe I have all dependent packages
for the soname bumps on the list to rebuild.

arb: update to 2.14.0

clisp: rebuild due to the pari update

cocoalib: update to 0.99595

eclib: update to 20180710.

With cvc4 1.6 building in Rawhide right now, the last Fedora user of
cryptominisat 4.x is gone. All Fedora consumers are now on
cryptominisat 5.x, which is in the cryptominisat package.
Consequently, I intend to retire the cryptominisat4 package soon. If
somebody needs it, let me know and I will give it to you instead of
retiring it.

The license of cvc4 has been corrected from GPv3+ to "Boost and BSD
and MIT". Since that is a less restrictive license, it should cause
no issues.

A new version of cvc4 is available. It depends on cryptominisat 5.x
instead of 4.x. Since cvc4 was the last consumer of cryptominisat 4.x
in Fedora, this means that we can finally retire the cryptominisat4
package.

On the other hand, cvc4 1.6 has new dependencies. I get to add 4
packages in order to retire 1. Um ... yay?

I need reviews for the following.