Postings by Martin Gieseking

Heads up: soname bump of liblouis and liblouisutdml

Hello all,

I've just updated liblouis and liblouisutdml in rawhide to the latest
upstream releases.

Orphaning The Mana World (tmw and tmw-music)


unfortunately, I have to orphan the two Mana World packages tmw [1] and
tmw-music [2] since I don't use them any longer and don't have enough
time to maintain them properly.

help needed to find a bug in zorba (or gcc 4.9)


I've tried to fix the broken zorba package in rawhide for a couple of
weeks now but, unfortunately, without much success. The upstream
developers don't seem to be able to find the cause for the issue either.

The problem is that the package fails to build with gcc 4.9.0 (all
archs) because the generated zorba binary segfaults for some queries due
to accessing already freed memory. The issue only occurs with optimized
builds (-O1, -O2, -O3) using gcc 4.9.0. With gcc 4.8.x the binary and
thus the whole package build and work correctly.

package doesn't build due to possible regression in gcc 4.9.0


I'm currently trying to rebuild the zorba package due to a broken
dependency in rawhide. Unfortunately, the newly built binary segfaults
when it's compiled with gcc 4.9.0. The same package builds correctly for
f20 (using gcc 4.8.2). It seems that this is a regression in the
optimizer of gcc 4.9.0 since the issue only appears when building with
-O1, -O2, or -O3. An "unoptimized build" (-O0) succeeds.

Unfortunately, it's pretty hard to debug an optimized binary in order to
isolate the origin of the segfault.

Looking for co-maintainer to fix build issue on ARM (zorba package)


finally, I found some time to update one of my bigger packages (zorba)
to the latest release and to adapt it to build successfully on f21.
However, the package (still) fails to build for armv7hl. The generated
binary segfauls and therefore also prevents creating additional files
during the build process:
<a href="" title=""></a>

Since the ARM emulation is horribly slow on my computers, I can't
actually use it to debug the issue in a reasonable timespan.

should file ncrack-services go to /etc?


during the review of ncrack
(<a href="" title=""></a>) I noticed that the
file ncrack-services is placed in /usr/share/ncrack by default. Since it
is a kind of configuration file that contains mappings between port
numbers and protocol names (similar to /etc/services), I'm not sure
whether the location /usr/share/ncrack is OK or whether it's required to
move it to /etc.

Question concerning bundled SQLite in Fossil tarball


I'd like to see the distributed SCM "Fossil" (<a href="" title=""></a>)
packaged for Fedora because I find the concept of the tool quite
attractive. There was already a review request for it in bugzilla:

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

After looking into the code I noticed that SQLite is bundled with the
tarball. Does the Fedora policy require to link against the separately
packaged libsqlite3 in this case, or may we use the bundled version that
will be statically linked?