DevHeads.net

Postings by Orion Poplawski

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:

gdl
psfex
scamp

GCC 9 OpenMP issues

Looks like GCC 9 is finally enforcing an OpenMP change:

From <a href="https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00628.html" title="https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00628.html">https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00628.html</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
issue:

<a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=31483290" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=31483290">https://koji.fedoraproject.org/koji/taskinfo?taskID=31483290</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.:

components:
rpms:
openmpi:
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="https://copr.fedorainfracloud.org/coprs/g/scitech/openmpi3.1/builds/" title="https://copr.fedorainfracloud.org/coprs/g/scitech/openmpi3.1/builds/">https://copr.fedorainfracloud.org/coprs/g/scitech/openmpi3.1/builds/</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
information:

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:
/tmp/tmpCyuFOY/octave/octave.yaml

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

Thanks.

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="https://copr.fedorainfracloud.org/coprs/g/scitech/octave4.4/packages/" title="https://copr.fedorainfracloud.org/coprs/g/scitech/octave4.4/packages/">https://copr.fedorainfracloud.org/coprs/g/scitech/octave4.4/packages/</a>

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

Notes on needed changes to packages are here:

<a href="https://docs.google.com/spreadsheets/d/1bBEe4Ng3TBUh-EWOQTZt_SvbBYoKWgrC-qH5VOggG_M/edit?usp=sharing" title="https://docs.google.com/spreadsheets/d/1bBEe4Ng3TBUh-EWOQTZt_SvbBYoKWgrC-qH5VOggG_M/edit?usp=sharing">https://docs.google.com/spreadsheets/d/1bBEe4Ng3TBUh-EWOQTZt_SvbBYoKWgrC...</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
tomorrow.

Some packages (InsightToolkit, DiffusionKurtosisFit, and petpvc) are
failing to build due to an issue with vxl and C++11. I've filed
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1637255" title="https://bugzilla.redhat.com/show_bug.cgi?id=1637255">https://bugzilla.redhat.com/show_bug.cgi?id=1637255</a>

documentation issue

<a href="http://www.postfix.org/TLS_README.html#client_tls_reuse" title="http://www.postfix.org/TLS_README.html#client_tls_reuse">http://www.postfix.org/TLS_README.html#client_tls_reuse</a> contains this:

To enable multiple deliveries per TLS connection, specify:

/etc/postfix/main.cf:
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
bump.

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
lib::linkimage(EnvT*)':
/builddir/build/BUILD/gdl-0.9.8/src/basic_pro_jmg.cpp:159:36: warning:
dereferencing type-punned pointer will break strict-aliasing rules
[-Wstrict-aliasing]
(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?

Thanks.

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?