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.

This afternoon, I received email from koschei, telling me that
polymake's builds have started to fail:

<a href="https://apps.fedoraproject.org/koschei/package/polymake?collection=f29" title="https://apps.fedoraproject.org/koschei/package/polymake?collection=f29">https://apps.fedoraproject.org/koschei/package/polymake?collection=f29</a>

The failure is due to this:

/builddir/build/BUILD/polymake-3.2/include/core/polymake/internal/shared_object.h:410:9:
error: ‘void pm::shared_object<Object, TParams>::leave() [with Object
= pm::sparse2d::Table<pm::Rational, false,
(pm::sparse2d::restriction_kind)0>; TParams =
{pm::AliasHandlerTag<pm::shared_alias_handler>}]’ causes a section
type conflict with ‘const pm::perl::RegistratorQueue&
polymake::common::get_regi

I don't see anything but green on status.fedoraproject.org, but the
last two builds I have submitted have both failed on s390x only with
an error that looks like this:

Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1244, in runTask
response = (handler.run(),)
File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 307, in run
return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
File "/usr/lib/python2.7/site-packages/koji/util.py", line 209, in
call_with_argcheck
return func(*args, **kwargs)
File "/us

I intend to update the ntl package from 11.0.0 to 11.1.0 in Rawhide.
Upstream has a policy of bumping the soname on every release, whether that
is necessary or not, so I will also rebuild all dependent packages, namely
these:

- eclib
- flint
- giac
- latte-integrale
- linbox
- pynac
- Macaulay2
- sagemath
- Singular

Since several of these packages depend on python, I plan to wait until the
python3 update is complete before starting these builds.

I will build cryptominisat 5.6.3 for Rawhide momentarily. With this
version, the license changes from LGPLv2 to MIT. This version also carries
an soname bump. I will rebuild the only dependent package in Fedora,
namely stp.

I somehow wound up owning python-sphinx_rtd_theme, I think probably because
I was the first person to attempt to do a build that needed it. :-)
Anyhow, I am not at all sure that I am competent to be the maintainer. I
need some advice. There is a new upstream version available, 0.4.0. I am
looking at it right now, and my attempts at unbundling fonts from this
package seem to be unraveling.

Three font families are bundled: fontawesome, Roboto Slab, and Lato. We
have all 3 of these in Fedora, but the problem is that this package wants
the web versions of these fonts, too.

For work reasons, I need a Fedora 28 VM. I've got a bunch of disk space
set aside to create logical volumes (LVM) for exactly this purpose, with
several existing VMs. On this occasion, I decided that I no longer needed
an older Fedora VM and decided to recycle it. I got the Fedora 28 x86_64
Workstation ISO image, set that as the boot CD in virt-manager, and fired
it up.

Hello everyone. Months ago, I started working on updates to a couple of
our mathematical packages. But they, in turn, required other packages to
be updated, and those updates required other packages to be updated, and
the whole thing kind of snowballed. I believe that I have finally reached
a point of closure, where I can update the whole pile and have everything
still work afterwards.

I propose to do the following updates and builds in Rawhide in about a
week.

I installed the latest batch of updates for F28 tonight. Since that
included a new kernel (4.16.10-300.fc28), I rebooted. The system came up
with the GDM panic screen [1]. I rebooted into the previous kernel
thinking that something might be wrong with the new one. Same result. I
rebooted again and added enforcing=0 to the kernel boot line. That
worked. I did a full SELinux relabel immediately afterwards. Nothing
relevant changed labels.

The SELinux Alert Browser says there are no alerts.

On Sun, Feb 18, 2018 at 10:09 AM, Igor Gnatenko
< ... at fedoraproject dot org> wrote:
Fixed: abc, gnofract4d, libedit, lrslib.

The abe package does not actually need a C++ compiler for building on
Linux. The configure script does check for a C++ compiler, for use
with XCode on OS X. But only a C compiler is ever invoked on non-OS X
platforms.

This is the second of two attempts to build sympy this evening, both
of which failed the same way:

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

According to mock_output.log, the spec file can't be found. What is going on?

Here's something I didn't expect from the new ABI gate. Which, before
I go further, I think will be a great idea nearly all of the time. I
think avoiding unintentional ABI breaks in stable releases is a worthy
goal.

But ... I maintain a package called gap. It provides what amounts to
a scripting language for doing certain types of math. It comes with a
bunch of addon packages that provide specific mathematical
capabilities. Most of them are written solely in the scripting
language, but a few have to interface with external libraries.

I have orphaned some Java packages. These two were used to support
jnormaliz, which used to be part of the normaliz package. It is now a
separate project, and I don't use it, so I am not packaging it. If
somebody would like to do so, you will want to take up these two
packages:
- balloontip (balloon tip component for Swing applications)
- javasysmon (Java system monitor)

The other two were intended to be dependencies of jReality. However,
while I was still moving these packages along, jReality upstream moved
from the free version of itext to the non-free version.

On Wed, Dec 27, 2017 at 5:16 AM, < ... at redhat dot com> wrote:
Why am I on the

On Sat, Oct 7, 2017 at 9:34 AM, Jerry James < ... at gmail dot com> wrote: