Postings by Jussi Lehtola

gsl soname bump


GSL 2.6 has just been released, and it comes with an soname bump. All
dependent packages will need to be rebuilt in rawhide.

libxc bump to version 4.1.1, license change LGPLv3 -> MPLv2.0


I'm updating libxc to version 4.1.1 in rawhide. This comes with a soname
change, and will require rebuilds of dependent packages, which should go

The license changes from LGPLv3 to MPLv2.0 in the 4.1 series onward. The
library does not forbid secondary licensing, so it is still GPL compatible.

packmol license change


I've updated packmol to version 18.013. This carries a license change
from GPLv2+ to MIT. No other packages are affected, since packmol is
executable only.

heads-up: OpenMesh soname bump

Hi all,

this is to let you know that I've upgraded OpenMesh in rawhide from the
4.1 series to the 6.3 series, which is fully backward compatible with
2.x and 5.x according to upstream. The upgrade came with a soname bump,
so all dependent packages need to be rebuilt.

heads up: libxc soname bump


I'm updating libxc in rawhide to version 4.0.1. This update contains a
soname bump, so rebuilds of dependent packages will be necessary:

- cp2k
- gpaw
- elk
- exciting

I don't think there have been any API changes, so the rebuilds should go
smoothly. I'll take care of the rebuilds.

psi4 license change: GPLv2+ -> LGPLv3

Dear all,

starting from version 1.1 (building in rawhide), the license of psi4 has
been changed from GPLv2+ to LGPLv3.

libint license change

Dear all,

starting from version 1.2 (building in rawhide), the license of libint
has been changed from GPLv2+ to LGPLv3.

Builds not hitting rawhide


it seems there's a snag in the rawhide buildroot update. My F24 and F25
buildroot overrides went into action ages ago, but rawhide still doesn't
have a package I built hours ago.

I notice that according to
<a href="" title=""></a>

f26 is supposed to branch tomorrow from rawhide, is the problem I'm
describing related to this?

Noarch package with arched tests


I've packaged pybind11 which is a seamless interface between Python and
C++11. This is a headers-only package, which would make it noarch...
However, it also carries a testsuite, which - of course - is important
to run on all architectures.

Is there some nifty trick to trick the build system to build the package
on all arches simultaneously while making the headers package noarch?

If there were any binaries produced by the package, this would be easily
accomplished, but I don't think there's any sense in shipping e.g.

libxc bump to 3.0.0 in rawhide - API changes


I'm going to bump libxc to the newly released 3.0.0 version in rawhide.
This introduces some changes to the API as well as a split of the
libraries, which may require changes to programs compiling against libxc.

The list for the affected packages is a rather short one

$ repoquery --disablerepo=* --enablerepo=rawhide --source --whatrequires


I will handle the rebuilds for these packages.

OpenMesh soname bump in rawhide


I'm updating OpenMesh in rawhide to version 4.1, which bumps the soname.
Only IQmol seems to use OpenMesh, which I'm rebuilding soon after.

Problem with build system?

Hi all,

I was just trying to build QMsgBox-0-6.20130830git94677dc, but the build
fails on all distros.

Note for packages linking against GSL [ACTION NEEDED]


the GNU Scientific Library (GSL) contains some linear algebra routines
that need a CBLAS library to work.

GSL contains a compatibility CBLAS library (gslcblas) that provides a
version of these routines. In 2010, we started to link libgsl by a
Fedora patch to libgslcblas, so linking to libgsl could be done just by
-lgsl instead of -lgsl -lgslcblas.

However, the GSL CBLAS library is far from optimal, and you can
typically get an order of magnitude more performance by using an
optimized library.

Mass Fortran rebuilds due to new GCC?


as has happened many times before, the GCC bump in rawhide has broken
all Fortran packages, desperately needing a mass rebuild. Unfortunately,
rpm is blissfully unaware of any breakage happening (BZ #1192617) so
maintainers won't even know when this breakage happens.

Before I start rebuilding packages, are there any plans to do the
rebuilds soon..?

Review swap


due to a new dependence in the IQmol package, I need to get OpenMesh

<a href="" title=""></a>

It's a very straightforward package, and I'm willing to review
something of similar complexity.

Orphaning packages


due to relocation to another continent and starting a new job, I have
to refocus my reduced time for Fedora on packages that I actively use.
So, I'm orphaning the following packages:


MPICH update


looks like mpich has been updated with a soname bump.
Why has this not been announced in the devel list?

TeXLive broken in rawhide?

Looks like TeXLive is broken in rawhide.

+ pdflatex progman
This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2014/dev)
restricted \write18 enabled.
kpathsea: Running mktexfmt pdflatex.fmt
tcfmgr: config file `' (usually in $TEXMFMAIN/texconfig) not found (ls-R missing?).
fmtutil: config file `fmtutil.cnf' not found.
I can't find the format file `pdflatex.fmt'!
RPM build errors:

Libint update, recompiles due


I've changed some configuration parameters in the libint-1.1.5-2 build,
which requires all dependent packages to be rebuilt. Because this build
addresses some missing functionality, I'm going to push it in older
distributions as well. I'll handle the necessary changes to other
packages myself.

Problem getting package to compile on EL6


I have a very weird problem. I'm trying to update the EPEL
branches of json-c to 0.11.

Orphaned packages


I've just orphaned all Fedora branches of
- gausssum
- qmforge

and the EL branches of tinyfugue.

.lz sources?


investigating the FTBFS of ddrescue I noticed that upstream has
switched to releasing tarballs only in .lz compressed format. This is
currently not supported by rpmbuild.

How should one proceed with the situation? Manual decompression instead
of %setup?

Review swaps


I'd be willing to swap reviews for the following packages that are
necessary for an update of JMol to the version 13 series.

jspecview <a href="" title=""></a>
naga <a href="" title=""></a>

I also have a third package up for review grabs

libint2 <a href="" title=""></a>

All of these are relatively simple packages.

Help with java problem: ant vs eclipse


I'm trying to update JMol to the version 13 series, but this requires
the introducion of a couple other packages in Fedora. However, I've run
into problems with jspecview [1] - for some reason I can't get it to
build a proper jar file, some classes always end up missing.

This is a rather odd problem, as if I build the thing in Eclipse as
upstream does (still using ant!), I get a working jar file.

I hope someone can help me in getting the package to build.

Octave api bump coming up


Octave 3.6.0 was released yesterday, so I'm updating the rawhide branch
to 3.6.0. This causes an API bump, causing the need to rebuild all
octave related packages.

ARPACK - Change of upstream


ARPACK used to be a project at Rice University [1], but they abandoned
it many years ago. After that many projects (e.g. Octave and Scilab)
started bundling their own patched versions of the software to fix the
bugs they had found in the package.

Taking a two-week holiday


just to let you know - I'm taking a two-week holiday starting
tomorrow, during which time I probably won't have internet access. So,
don't wonder why I'm not, e.g., attending anything in bugzilla.

Jmol, Java and netscape.javascript


I tried to update Jmol to the latest release, when I ran once again

error: package netscape.javascript does not exist
import netscape.javascript.JSObject;

My spec builds fine in Fedora 15, but fails to build in 16 and 17.
<a href=";a=blob;f=jmol.spec;hb=HEAD" title=";a=blob;f=jmol.spec;hb=HEAD">;a=blob;f=jmol.spec;hb=HEAD</a>

Does someone have a solution to this problem?

PokerTH orphaned


I've just orphaned PokerTH, since I'm trying to free myself some time
and I don't use it myself.

PokerTH does not currently build on rawhide, since OpenSSL support has
been dropped from GnuTLS a week ago (BZ #726697). Getting it to build
again would then require building against OpenSSL (and asking upstream
for a GPL license exception), or shipping a private copy of GnuTLS.

Defining build options based on available compiler version


I tried using
%global gccver %(gcc -dumpversion)
%if %{gccver} >= 4.6.0
foo here

to conditionalize usage of quadruple precision support in a spec file
that ships on multiple distros, but the comparison gives the error

parseExpressionBoolean returns -1

Is there a way to check if the gcc version is sufficient with some rpm