DevHeads.net

Postings by Dave Love

unable to branch to epel8

I've tried to get a couple of epel8 branches created, and the tickets
have been closed (twice in one case after I re-opened it) with "The
branch in PDC already exists". (It worked for other packages.) I don't
know what PDC is, but the branch definitely isn't in git. An example is
<https://pagure.io/releng/fedora-scm-requests/issue/15061>. Can someone
tell me what to do about that?

Also, I don't get any notifications from pagure (as with various other
-- most? -- services), despite turning on anything relevant-looking in
the notifications app.

responding to CVEs

Is there any specific requirement to change packages in response to
CVEs, specifically if they appear to be bogus? I can't find anything
specifying that.

I ask because three CVEs have triggered automated bug reports against
libxsmm <https://apps.fedoraproject.org/packages/libxsmm/bugs>. I don't
understand why the CVEs were issued, since a problem with unrealistic
input to a (rather rarely used) development tool doesn't strike me as a
security problem.

On that basis I didn't bother including the upstream patch with the
latest version, and I'm inclined to close the issues as wontfix.

"TLS reference ... mismatches non-TLS reference"

I've been trying to build a new version of the scorep package with
%check running make check. A couple of days ago it failed with strange
link errors concerning symbols not found which are defined in the
libraries it was linking against (apparently in the right order). Now
it's failing on rawhide x86_64 and armv7hl with

/usr/bin/ld: pomp_tpd_: TLS reference in ./.libs/libscorep_adapter_opari2_openmp_event.so mismatches non-TLS reference in jacobi_omp_f90-jacobi.mod.o

but working on aarch64, for instance.

change in -fpic handling?

What has changed in the last month to affect building shared libraries
in rawhide?

I tried to rebuild libxsmm in rawhide, after changing the spec to use
python2 explicitly, and it failed with

/usr/bin/ld: build/intel64/libxsmm_main.o: relocation R_X86_64_PC32 against symbol `libxsmm_crc32_u64' can not be used when making a shared object; recompile with -fPIC

The sources are compiled with -fpic and it's x86_64 only, so -fPIC
v.

equivalent of Debian config-package?

Is there any existing system for rpm like the Debian one
<https://debathena.mit.edu/config-package-dev/> for building local
configuration packages?

MPI packaging change?

I've been mostly out of action for a while but am trying to sort out an
MPI package which is now uninstallable in rawhide and I don't know
what's changed in the packaging procedure.

It's just an MPI-based library which is failing on the
libsuperlu_dist.so.1()(64bit) requirement as follows:

$ rpm -qp --requires superlu_dist-openmpi-5.1.3-2.fc27.x86_64.rpm | grep superlu
warning: superlu_dist-openmpi-5.1.3-2.fc27.x86_64.rpm: Header V3
RSA/SHA256 Signature, key ID f5282ee4: NOKEY
libsuperlu_dist.so.1()(64bit)
libsuperlu_dist.so.1()(64bit)(openmpi-x86_64)
$ rpm -qp --provides superlu