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:

I started an F27 build this morning:

<a href="https://koji.fedoraproject.org/koji/buildinfo?buildID=979845" title="https://koji.fedoraproject.org/koji/buildinfo?buildID=979845">https://koji.fedoraproject.org/koji/buildinfo?buildID=979845</a>

Hours later, all arches but 32-bit ARM have finished. The 32-bit ARM
build appears to be stuck setting up the buildroot.

I would like to update a bunch of the numerical packages in the near
future. I will do the updates for Rawhide only at first, although if
everything seems stable I may update F-27 as well. Here is the
proposed list of changes. Package maintainers and co-maintainers are
CCed to this email.

arb: update from 2.10.0 to 2.11.1

cddlib: polymake used to link with both the GMP and non-GMP versions
of cddlib. We have some ugly linker tricks in the cddlib package to
support both this and other package's use of cddlib.

Tonight I am trying to figure out why gfan failed the mass rebuild.
I'm a bit confused, so I'm writing in the hopes that one of you
recognizes what is going on.

The gfan library is linked with libcddgmp. Libcdd can be built with
or without gmp support. Polymake, weirdly, wants to link with both
versions, so libcdd is built without gmp support and libcddgmp is
built with gmp support. Polymake expects the gmp version to have
symbols that are suffixed with _gmp.

Are there any test s390x instances available for a peon like me to use
to diagnose a build failure? Failing that, does anybody with access
to an s390x instance have time to help me? The latest bigloo release
built successfully on all arches but s390x:

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

The failure comes after the main binary has been built and linked
successfully, but then is executed to compile some Scheme files. The
binary is reporting that it was invoked on an empty input file.

Thank you,

I will shortly build ocaml-menhir version 20170509. With this
version, the license of the main packages changes from QPL with
exceptions to GPLv2. Also, an earlier mistake will be corrected: the
ocaml-menhir-devel subpackage should be LGPLv2 with exceptions, not
LGPLv2+ with exceptions.

Work has been going on for months now to update quite a few of our
numerical packages. It looks like we've finally ironed the last
problems out, so Rawhide builds will start shortly.

The latest version of the python-ZODB package has a couple of new
build dependencies that aren't yet in Fedora. Both of these are very
small, very simple packages. I'm happy to swap reviews for these two:

python-j1m.sphinxautointerface:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1435920" title="https://bugzilla.redhat.com/show_bug.cgi?id=1435920">https://bugzilla.redhat.com/show_bug.cgi?id=1435920</a>
python-j1m.sphinxautozconfig:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1435921" title="https://bugzilla.redhat.com/show_bug.cgi?id=1435921">https://bugzilla.redhat.com/show_bug.cgi?id=1435921</a>

Thanks,

Hello everybody,

I am the primary point of contact for a handful of voice
recognition-related packages:
- cmusphinx3
- irstlm
- openfst
- opengrm-ngram
- pocketsphinx
- sphinxbase
- sphinxtrain

I have not used these packages myself for quite some time, and am
unlikely to start using them again anytime soon, so I think a new
primary point of contact is appropriate.

I fixed the mass rebuild FTBFS errors for clisp and ecl yesterday, and
started a build of maxima due to changes in both clisp and ecl.
Something is afoot.

There are two previous builds for maxima that both claim to be in the
building state, but were started quite a long time ago:

19 Dec 2016: <a href="https://koji.fedoraproject.org/koji/buildinfo?buildID=826479" title="https://koji.fedoraproject.org/koji/buildinfo?buildID=826479">https://koji.fedoraproject.org/koji/buildinfo?buildID=826479</a>
12 Jan 2017: <a href="https://koji.fedoraproject.org/koji/buildinfo?buildID=833415" title="https://koji.fedoraproject.org/koji/buildinfo?buildID=833415">https://koji.fedoraproject.org/koji/buildinfo?buildID=833415</a>

Then there is my attempt from yesterday:

<a href="https://koji.fedoraproject.org/koji/buildinfo?buildID=861874" title="https://koji.fedoraproject.org/koji/buildinfo?buildID=861874">https://koji.fedoraproject.org/koji/buildinfo?buildID=861874</a>

In all 3 cases, the build finished successfully on all architect

I've got 3 updates where something weird happened. Is this a known
bodhi issue? First is this update:

<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2017-b4d8e33d45" title="https://bodhi.fedoraproject.org/updates/FEDORA-2017-b4d8e33d45">https://bodhi.fedoraproject.org/updates/FEDORA-2017-b4d8e33d45</a>

I created it to contain updates for both F-24 and F-25 for
python-BTrees. As you can see, it contains two instances of the
update for F-24 now. I didn't notice that until after I pushed it
stable.

Just did a git push to polymake and got this:

$ git push
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 454 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
remote: * Publishing information for 1 commits
remote: * Notifying alternative-arch people
remote: Traceback (most recent call last):
remote: File "./hooks/post-receive-chained.d/post-receive-alternativearch",
line 196, in <module>
remote: run_as_post_receive_hook()
remote: File "./h

Texlive has been uninstallable in Rawhide for a few days now, which is
blocking some of the rebuilds needed to fix python 3.6 breakage:

Error: nothing provides libpoppler.so.65()(64bit) needed by
texlive-xetex-bin-6:svn41091-24.20160520.fc26.1.x86_64

I see that a -25 build was kicked off, and koji thinks it succeeded:

<a href="https://koji.fedoraproject.org/koji/packageinfo?packageID=5402" title="https://koji.fedoraproject.org/koji/packageinfo?packageID=5402">https://koji.fedoraproject.org/koji/packageinfo?packageID=5402</a>

Indeed, all of its subtasks completed and produced binaries:

<a href="https://koji.fedoraproject.org/koji/buildinfo?buildID=826095" title="https://koji.fedoraproject.org/koji/buildinfo?buildID=826095">https://koji.fedoraproject.org/koji/buildinfo?buildID=826095</a>

But the main task is marked in red, with this reason:

GenericError: cannot update build

I'm trying to build python-cvxopt, but gcc is failing on aarch64 with
a bus error:

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

I took a quick look at koji and found another recent failing build
with the same problem:

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

Both builds indicate that gcc was compiling a simple arithmetic
expression when the bus error occurred. Does anybody know what's
going on there? Thanks,

I've got a couple of new package dependencies that need reviews:

prooftree: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1399366" title="https://bugzilla.redhat.com/show_bug.cgi?id=1399366">https://bugzilla.redhat.com/show_bug.cgi?id=1399366</a>
ocaml-ocplib-simplex: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1399367" title="https://bugzilla.redhat.com/show_bug.cgi?id=1399367">https://bugzilla.redhat.com/show_bug.cgi?id=1399367</a>

I've also got a couple more GAP packages waiting in the wings. These
2 are lower priority than the 2 above:

gap-pkg-hapcryst: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1378526" title="https://bugzilla.redhat.com/show_bug.cgi?id=1378526">https://bugzilla.redhat.com/show_bug.cgi?id=1378526</a>
gap-pkg-xmod: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1399365" title="https://bugzilla.redhat.com/show_bug.cgi?id=1399365">https://bugzilla.redhat.com/show_bug.cgi?id=1399365</a>

Let me know what I can review for you in exchange. Regards,

Is anybody around who can check what's going on with a PPC64 build
that appears to be stuck? I noticed that fflas-ffpack has not built
successfully on ppc64 recently, so I kicked off a scratch build last
night to try to diagnose the problem. It finished fairly quickly on
ppc64le, but is still going on ppc64. The last step in the logs is a
g++ invocation.

I am building ntl 10.1.0 for Rawhide tonight. With this version, the
license changes from GPLv2+ to LGPLv2+. Due to an soname bump, I will
also rebuild all packages that depend on ntl.

[This message BCC'd to affected maintainers.]

A new version of tbb has been released. With this release, the
license changes from "GPLv2 with exceptions" to "ASL 2.0".

There is no soname bump in this release, but one section of the API
changed in a backwards-incompatible way. Therefore, I intend to
rebuild all tbb-using packages for Rawhide and F-25, in case they use
that part of the API. I have already done local builds in mock, with
no problems. The affected packages are:

- ceres-solver
- embree
- gazebo
- mathicgb
- OCE
- suitesparse

There is another reason for these rebuilds.

One of my packages has a crashing test suite on aarch64:

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

I'd like to debug the issue, but do not have access to any aarch64
hardware. I looked at
<a href="https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers" title="https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers">https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Mainta...</a>,
but those armv7 machines are 32-bit ARM, right? Are there any
resources I could use to debug this issue? QEMU emulations is soooooo
sloooooow that I don't really want to suffer through it if I don't
have to.

Thanks,