Postings by Orion Poplawski

octave 5.1 coming to rawhide

I'm about about to start building octave 5.1 and dependent packages in
rawhide. This is a soname and octave api change.

Fedora Distgits

There's a nifty site here:

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

That collects statistics on git contributions to Fedora (as well as
other projects), including numbers of commits by individuals. However,
it's based on email address, and many people have used multiple

Orphaning kdesvn

I'm going to orphan kdesvn as I no longer use it. It needs updating:

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

Let me know if you are interested in taking it over.

hdf5, netcdf, and vtk updates coming to Rawhide today

I'm updating:

hdf5 to 1.10.5
netcdf to 4.6.3
vtk to 8.2

in Rawhide starting today. All are soname updates so I'll be rebuilding
all dependent packages as well. Some of these packages (notably vtk)
take a long time to build so there may be broken deps for a couple of days.

- Orion

/usr/bin/ld is broken in rawhide

With current koji buildroot I end up with:

+ ls -l /usr/bin/ld /usr/bin/ld.bfd /usr/bin/ /usr/bin/ldd
--w-------. 1 root root 3814880 Feb 27 04:00 /usr/bin/ld
-rwxr-xr-x. 1 root root 1841608 Feb 26 15:02 /usr/bin/ld.bfd
-rwxr-xr-x. 1 root root 3814880 Feb 26 15:02 /usr/bin/
-rwxr-xr-x. 1 root root 5441 Feb 19 07:39 /usr/bin/ldd

and thus:

BUILDSTDERR: collect2: fatal error: cannot find 'ld'

OpenMPI 3.1.3 rebuilds (mostly) complete

The rebuilds of the OpenMPI deps are (mostly) complete.

openmpi 3.1.3?

I'm thinking about trying to sneak in openmpi 3.1.3 before the f30
branch. My COPR rebuilds have been looking pretty good lately so I hope
it will go fairly smoothly. Does anyone have any objections? I'm
planning on starting tomorrow if not.

- Orion

plplot 5.14.0 coming to rawhide

I'm building plplot 5.14.0 for rawhide. This involves a soname bump.
I'll be rebuilding the dependent packages when it's complete:


GCC 9 OpenMP issues

Looks like GCC 9 is finally enforcing an OpenMP change:

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

- change data sharing for readonly variables without mutable members,
they are
no longer predetermined shared (this actually changed in earlier
OpenMP standard
releases, but was considered a mistake; for 5.0 it was decided it
isn't going to
be reverted; this makes a difference mainly when using default(none))

Which is now leading to some (expected) compilation failures:

BUILDSTDERR: nco_omp.c: In function 'nco_openmp_ini':
BUILDSTDERR: nco_omp.c:210:38: error:

Identical doxygen docs on different architectures

With the introduction of doxygen 1.8.15 in rawhide (or perhaps just
better noarch rpmdiff checks?), the paraview-doc noarch sub-package is
now different on different architectures:

BuildError: The following noarch package built differently on different
architectures: paraview-doc-5.5.2-20.fc30.noarch.rpm
rpmdiff output was:
removed /usr/share/doc/paraview/doxygen/html/dir_000001_000006.html
removed /usr/share/doc/paraview/doxygen/html/dir_000001_000022.html
removed /usr/share/doc/paraview/doxygen/html/dir_000001_000071.html
removed /usr/share/doc/paraview/doxygen/html/dir_0

How to resubmit a module build

Module build number 2628 failed due to what appears to have been a koji

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

<class 'psycopg2.extensions.TransactionRollbackError'>: deadlock detected
DETAIL: Process 31743 waits for ShareLock on transaction 4127247553;
blocked by process 17714.
Process 17714 waits for ShareLock on transaction 4127247628; blocked by
process 31743.
HINT: See server log for query details.

The other builds (f29, f28) succeeded.

Is there a way to re-submit just this build?

Issue building modules with package branches

I'm trying to build some modules that specify the branch for the package
to use, e.g.:

rationale: The core package
ref: 2.1
buildorder: 10

My first builds failed because I had failed to push the proper commits
to the new branches.

Need help with illegal instruction errors in COPR

I'm testing out rebuilding packages with openmpi 3.1 in COPR:

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

A number of packages are failing running tests only on Fedora Rawhide
x86_64 with processes killed with signal 4 (Illegal instruction).

Problems building a module

I'm trying to build a module, and it's failing without much useful

octave (4.4)]$ fedpkg module-build
Submitting the module build...
Could not execute module_build: The build failed with:
The following invalid modulemd was encountered:

So something presumably is wrong with my modulemd file - but how can I
figure out what?


Octave 4.4 update coming soon to rawhide

I've planning on building octave 4.4 soon (next day or two) in rawhide.
I've been building dependent packages here:

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

Anyone in the scitech group can submit builds there if needed.

Notes on needed changes to packages are here:

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

I'm going to start working on PRs for the various changes for
maintainers to review.

VTK 8.1.1 coming to rawhide

Building now. I'll be rebuilding dependent packages when it completes

Some packages (InsightToolkit, DiffusionKurtosisFit, and petpvc) are
failing to build due to an issue with vxl and C++11. I've filed
<a href="" title=""></a>

documentation issue

<a href="" title=""></a> contains this:

To enable multiple deliveries per TLS connection, specify:

smtp_tls_connection_reuse = yes

However, that does not appear to be a valid postfix option.

plplot 5.13.0 soname bump

I'll be buiding plplot 5.13 and dependencies shortly. This has a soname

Intent to retire StarCluster and python-iptools

I'm going to be retiring StarCluster and its dependency python-iptools
shortly. Upstream is dead and I'm not using it.

libdap 3.19.1 soname bump

I'll be building libdap 3.19.1 soon in rawhide. This includes a soname
bump so dependencies will be rebuilt as well.

Help with strict-aliasing warning

I'm getting:

/builddir/build/BUILD/gdl-0.9.8/src/basic_pro_jmg.cpp: In function 'void
/builddir/build/BUILD/gdl-0.9.8/src/basic_pro_jmg.cpp:159:36: warning:
dereferencing type-punned pointer will break strict-aliasing rules
(BaseGDL* &) dynFun[count_fun] =
(BaseGDL*) dlsym(module[count], entryName.c_str());

dynFun is defined as:

BaseGDL*(*dynFun[MAXNDLL/2])( EnvT* e);

This is all beyond me. Missing the function pointer argument specification?


New gdl segfaults with gcc 8 in antlr

I've just discovered that gdl appears to be segfaulting a lot now deep
in the antlr c++ generated parser code with the switch to gcc 8. Has
anyone else run into similar issues?