DevHeads.net

Postings by Richard W.M. Jones

FYI: ocaml-camomile-0.8.6-1.fc28 (in Rawhide) is broken

ocaml-camomile-0.8.6-1.fc28 breaks ocaml-gettext which is required
to generate translations for some virt tools.

I'm trying to get it untagged to avoid having to do an Epoch:

<a href="https://pagure.io/releng/issue/7101" title="https://pagure.io/releng/issue/7101">https://pagure.io/releng/issue/7101</a>

Rich.

mandb takes forever to run during package updates

I've noticed for a while that updates get "stuck" in the scriptlets
phase.

OCaml / aarch64 / binutils / coq mess

OCaml 4.05 was added to Fedora 27+ recently. Unfortunately, on
aarch64 only, it interacts badly with a change made in binutils 2.29
which tightens up the rules on relocations for PC-relative addresses.
More details:

<a href="https://caml.inria.fr/mantis/view.php?id=7585" title="https://caml.inria.fr/mantis/view.php?id=7585">https://caml.inria.fr/mantis/view.php?id=7585</a> detailed discussion
<a href="https://github.com/ocaml/ocaml/pull/1268" title="https://github.com/ocaml/ocaml/pull/1268">https://github.com/ocaml/ocaml/pull/1268</a> partial solution
<a href="https://sourceware.org/ml/binutils/2017-06/msg00171.html" title="https://sourceware.org/ml/binutils/2017-06/msg00171.html">https://sourceware.org/ml/binutils/2017-06/msg00171.html</a> binutils change

This only affects dynamic loading of OCaml modules on aarch64, and in
particular it only affects the Coq theorem prover.

Confusing SCM package request

I'm trying to import this package into Fedora:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1174036" title="https://bugzilla.redhat.com/show_bug.cgi?id=1174036">https://bugzilla.redhat.com/show_bug.cgi?id=1174036</a>

I went through the new process as far as I can tell and the tool just
filed a bug and printed out the URL of the bug:

$ fedrepo-req -t 1174036 ocaml-re
<a href="https://pagure.io/releng/fedora-scm-requests/issue/596" title="https://pagure.io/releng/fedora-scm-requests/issue/596">https://pagure.io/releng/fedora-scm-requests/issue/596</a>

Do I have to wait for that request to be handled now? The
documentation seems to suggest that the branch should actually have
been created, but it is not.

Rich.

mock or dnf or fedora-review tries to install a binary of a package it is test-building

I don't know what component to file this bug under ...

When running ‘fedora-review -b 1477363’, it fails to test build the
package in mock.

Is it possible atlas is linked wrongly by new binutils?

ocaml-gsl (OCaml bindings for GNU Scientific Library) currently
fails to link to atlas:

+ /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib -I examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.native
/usr/lib64/atlas/libsatlas.so: undefined reference to `dlarfy_'
/usr/lib64/atlas/libsatlas.so: undefined reference to `slarfy_'
/usr/lib64/atlas/libsatlas.so: undefined reference to `clarfy_'
/usr/lib64/atlas/libsatlas.so: undefined reference to `zlarfy_'
collect2: error: ld returned 1 exit status

However this only happens with the very latest atlas that was bu

Long time for package to be tagged into Rawhide

I built this one 3½ hours ago:

<a href="https://koji.fedoraproject.org/koji/buildinfo?buildID=953201" title="https://koji.fedoraproject.org/koji/buildinfo?buildID=953201">https://koji.fedoraproject.org/koji/buildinfo?buildID=953201</a>

A whole series of builds depend on this but I'm still waiting for it
to get into the buildroot ... Can something be done to speed this up?

Rich.

Are we going to do another mass rebuild for ppc64le problems?

It looks like the mass rebuild completed. However I have quite a few
packages which failed because of the ppc64le / binutils(?) /
"localentry:0" thing. Are we going to do another mass rebuild to fix
this?

Rich.

Do we have any OCaml-written setuid binaries?

I'm fairly sure we don't have any setuid binaries written in OCaml.
However I've no idea how we would go about mechanically checking this,
hence why I'm asking here.

OCaml 4.04.2 (23 Jun 2017):
### Security fix:

- PR#7557: Local privilege escalation issue with ocaml binaries.
(Damien Doligez, report by Eric Milliken, review by Xavier Leroy)

CVE-2017-9772: Privilege escalation in OCaml runtime for SUID executables

The environment variables CAML_CPLUGINS, CAML_NATIVE_CPLUGINS, and
CAML_BYTE_CPLUGINS can be used to auto-load code into any ocamlopt-

fedora-review prints "Package contains BR: python2-devel or python3-devel"

fedora-review prints this in the ‘Issues’ section of the report:

‘- Package contains BR: python2-devel or python3-devel’

This has happened on a couple of reviews I have done recently. There
is no other information given about what this means or why it's bad.

Both were Python packages and the Python package guidelines mention
that you *should* have BR: python2-devel / python3-devel
(<a href="https://fedoraproject.org/wiki/Packaging:Python#BuildRequires" title="https://fedoraproject.org/wiki/Packaging:Python#BuildRequires">https://fedoraproject.org/wiki/Packaging:Python#BuildRequires</a>)

So .. what does it mean?

Rich.

ppc64/ppc64le dynamic linker or tcmalloc problem

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1452813" title="https://bugzilla.redhat.com/show_bug.cgi?id=1452813">https://bugzilla.redhat.com/show_bug.cgi?id=1452813</a>

In Rawhide on ppc64 or ppc64le, ‘qemu-system-ppc64 -help’ segfaults in
the dynamic linker. As far as I can tell, it's something to do with
ifuncs, the _ZdlPvm symbol, C++ sized-delete(?), and tcmalloc.

The system in general works fine - ie. binaries aren't all
segfaulting.

Anyway it's very deep in the dynamic linker and the emulated system
I'm using is very very slow which makes debugging painful. Can a
compiler expert take a look?

Rich.

Koji: List of recent builds for a particular user

I can list my most recent builds here:

<a href="https://koji.fedoraproject.org/koji/userinfo?userID=458" title="https://koji.fedoraproject.org/koji/userinfo?userID=458">https://koji.fedoraproject.org/koji/userinfo?userID=458</a>

but, it's very slow (I assume it's doing some complex database query)
and it only shows 10 builds at a time.

Is there a way to show more builds, and a bit faster?

I could even work out how to do it from the ‘koji’ command line tool.
‘koji list-pkgs --owner=rjones’ and ‘koji list-history --user=rjones’
seem likely candidates, but they don't do what I want.

Rich.

OCaml 4.04.1 rebuild in Rawhide

OCaml 4.04.1 was released last month. It is a simple bugfix update
which shouldn't bring any surprises.

I'm planning to rebuild the OCaml packages in Rawhide into a side tag
today (<a href="https://pagure.io/releng/issue/6782" title="https://pagure.io/releng/issue/6782">https://pagure.io/releng/issue/6782</a>).

The other change is that since fedorahosted was closed a few months
ago, the fedora-ocaml git repository was homeless. I have now moved
the project to pagure.io: <a href="https://pagure.io/fedora-ocaml" title="https://pagure.io/fedora-ocaml">https://pagure.io/fedora-ocaml</a>
You should consult this repository if you want to see what downstream
features/patches we include.

Rich.

ERROR: No build ID note found in <object file>

I'm trying to compile native LLVM support into American Fuzzy Lop.
Unfortunately debuginfo generation fails with:

+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 /home/rjones/d/fedora/american-fuzzy-lop/master/afl-2.41b
extracting debug info from /home/rjones/rpmbuild/BUILDROOT/american-fuzzy-lop-2.41b-2.fc27.x86_64/usr/bin/afl-tmin
extracting debug info from /home/rjones/rpmbuild/BUILDROOT/american-fuzzy-lop-2.41b-2.fc27.x86_64/usr/bin/afl-analyze
extracting debug info from /home/rjones/rpmbuild/BUILDROOT/american

RPM boolean dependencies in Requires

I have a package which needs GNU Privacy Guard (GPG) at runtime.

Import of key(s) didn't help, wrong key(s)?

Obviously this could be worked around using --nogpgcheck,
but what does it mean?

Rich.

# dnf install /usr/lib/crt1.o --releasever=26 --best --allowerasing
Failed to synchronize cache for repo 'rpmfusion-nonfree-updates', disabling.
Failed to synchronize cache for repo 'rpmfusion-nonfree', disabling.
Failed to synchronize cache for repo 'rpmfusion-free', disabling.
Failed to synchronize cache for repo 'rpmfusion-free-updates', disabling.
Last metadata expiration check: 5:10:29 ago on Tue Mar 21 16:09:04 2017.
Dependencies resolved.
=============================================================

Fedora kernel crashing in virtio when running on qemu

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1430297" title="https://bugzilla.redhat.com/show_bug.cgi?id=1430297">https://bugzilla.redhat.com/show_bug.cgi?id=1430297</a>

This has been going on for a few weeks with no attention. It prevents
anyone from running libguestfs on Fedora 26.

It's (IMHO) pretty serious for anyone using virtualization: "kernel
doesn't boot on qemu" should be a blocker for a Fedora release.

Can anyone see what's going on?

Rich.

Default permissions on /dev/kvm

Currently if you install a minimal-ish, non-"Virtualization Host"
Fedora, then the permissions on the /dev/kvm device are:

crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm

(I believe this is because of some kernel defaults for the device. In
any case there seems to be no base install udev rule which applies a
`MODE=' line explicitly for /dev/kvm).

There mere act of installing the qemu package adds a new udev rule
which changes the permissions:

[root@rawhide ~]# ll /dev/kvm
crw-------.

Bodhi broken now?

I get this doing 'fedpkg update':

fedora.client.bodhi.BodhiClientException: Unable to create update.
Authentication required

It's unclear what authentication is required, but I have a valid ssh
key and live Kerberos key, so I'm not sure what else it needs ...

Rich.

Intent to orphan and retire Hoard (a memory allocator)

Hoard is an alternative memory allocator (ie. malloc implementation)
for C++.

ceph / boost broken in koji Rawhide

<a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=17707485" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=17707485">https://koji.fedoraproject.org/koji/taskinfo?taskID=17707485</a>

The error is:

DEBUG util.py:435: Error: nothing provides libboost_system.so.1.60.0()(64bit) needed by librbd1-1:10.2.5-1.fc26.x86_64

This is fixed by a new ceph build which was completed yesterday
morning:

<a href="https://koji.fedoraproject.org/koji/buildinfo?buildID=839565" title="https://koji.fedoraproject.org/koji/buildinfo?buildID=839565">https://koji.fedoraproject.org/koji/buildinfo?buildID=839565</a>

but the new ceph package is for some reason unavailable for building
against in Koji.

What's going on? Does this need a build override? (And if so, why?)

Rich.

Why does BuildRequires: kernel in Koji pull in kernel-debug-*?

libguestfs BuildRequires: kernel, but gets kernel-debug-core:

<a href="https://kojipkgs.fedoraproject.org//packages/libguestfs/1.34.4/1.fc25/data/logs/x86_64/root.log" title="https://kojipkgs.fedoraproject.org//packages/libguestfs/1.34.4/1.fc25/data/logs/x86_64/root.log">https://kojipkgs.fedoraproject.org//packages/libguestfs/1.34.4/1.fc25/da...</a>
(from <a href="https://koji.fedoraproject.org/koji/buildinfo?buildID=837312" title="https://koji.fedoraproject.org/koji/buildinfo?buildID=837312">https://koji.fedoraproject.org/koji/buildinfo?buildID=837312</a>)

Why?

Rich.

kernel-PAE-core disappeared on i686 (was: Broken dependencies: libguestfs)

----- Forwarded message from <a href="mailto: ... at fedoraproject dot org"> ... at fedoraproject dot org</a> -----

libguestfs has broken dependencies in the rawhide tree:
On x86_64:
1:libguestfs-1.35.20-1.fc26.i686 requires kernel-PAE-core
Please resolve this as soon as possible.

kernel-PAE-core seems to exist.

gperf 3.1 changes the type of the hash 'len' parameter

I pushed gperf 3.1 to Rawhide.

This changes the type of one of the parameters of the generated
perfect hash function:

-char *in_word_set (register const char *str, register unsigned int len);
+char *in_word_set (register const char *str, register size_t len);

If you have the function prototyped in another file, then you have to
be careful that the prototype exactly matches the new type.

Problems using Tex dependencies in copr Rawhide?

* <a href="https://copr.fedorainfracloud.org/coprs/rjones/riscv/build/491172/" title="https://copr.fedorainfracloud.org/coprs/rjones/riscv/build/491172/">https://copr.fedorainfracloud.org/coprs/rjones/riscv/build/491172/</a>

DEBUG util.py:421: Error: nothing provides libpoppler.so.65()(64bit) needed by texlive-xetex-bin-6:svn41091-24.20160520.fc26.1.x86_64.
DEBUG util.py:421: package texlive-collection-latex-6:svn41011-24.20160520.fc26.1.noarch requires texlive-collection-basic, but none of the providers can be installed

* <a href="https://copr.fedorainfracloud.org/coprs/rjones/riscv/build/491142/" title="https://copr.fedorainfracloud.org/coprs/rjones/riscv/build/491142/">https://copr.fedorainfracloud.org/coprs/rjones/riscv/build/491142/</a>

DEBUG util.py:421: Error: package texi2html-5.0-4.fc24.noarch requires latex2html, but none of the providers can be installed

Are these problems with Raw

Erik van Pienbroek (epienbro) passed away

I just want to pass on the sad news that Erik van Pienbroek (epienbro),
long time Fedora and MinGW contributor, passed away last Saturday
(2016-12-10). His funeral was today and this is his whimsical online
funeral card: <a href="http://kar.xs4all.nl/erik/evp.jpg" title="http://kar.xs4all.nl/erik/evp.jpg">http://kar.xs4all.nl/erik/evp.jpg</a>

I only met him in person twice. But he brilliantly led the Windows
cross-compiler packaging in Fedora which I was involved with. He will
be greatly missed.

Rich.

Use of %{?_isa}

Here are three packages, none of them using %{?_isa} in their spec files:

(a) libvirt <a href="http://pkgs.fedoraproject.org/cgit/rpms/libvirt.git/tree/libvirt.spec" title="http://pkgs.fedoraproject.org/cgit/rpms/libvirt.git/tree/libvirt.spec">http://pkgs.fedoraproject.org/cgit/rpms/libvirt.git/tree/libvirt.spec</a>
(b) libguestfs <a href="http://pkgs.fedoraproject.org/cgit/rpms/libguestfs.git/tree/libguestfs.spec" title="http://pkgs.fedoraproject.org/cgit/rpms/libguestfs.git/tree/libguestfs.spec">http://pkgs.fedoraproject.org/cgit/rpms/libguestfs.git/tree/libguestfs.spec</a>
(c) qemu <a href="http://pkgs.fedoraproject.org/cgit/rpms/qemu.git/tree/qemu.spec" title="http://pkgs.fedoraproject.org/cgit/rpms/qemu.git/tree/qemu.spec">http://pkgs.fedoraproject.org/cgit/rpms/qemu.git/tree/qemu.spec</a>

They all have a "core" package, and subpackages which Require this
core package, for example:

%package system-x86 # subpackage of qemu
Summary: QEMU system emulator for x86
Group: Development/Tools
Requires: %{name}-common = %{epoch}:%{versi

RPM dependency generator ignoring %{_libdir}/pkg/plugin.so

I'm packaging up a program that puts plugins into

%{_libdir}/pkg/plugin.so

Unfortunately rpmbuild doesn't seem to generate automatic dependencies
for these files (they are regular ELF files and I have checked that
they contain DT_NEEDED fields).

Any ideas on that? There's a lot of documentation about how to
exclude files from automatic dep generation, but I want to include
these.

Rich.

Strange mldonkey build error

$ fedpkg build --target=f26-ocaml
Building mldonkey-3.1.5-10.fc26 for f26-ocaml
Created task: 16300957
Task info: <a href="http://koji.fedoraproject.org/koji/taskinfo?taskID=16300957" title="http://koji.fedoraproject.org/koji/taskinfo?taskID=16300957">http://koji.fedoraproject.org/koji/taskinfo?taskID=16300957</a>
Watching tasks (this may be safely interrupted)...
16300957 build (f26-ocaml, /rpms/mldonkey:8013f45d7fdb6095949016e6135c6c11176f83d0): open (arm04-builder07.arm.fedoraproject.org)
16300958 buildSRPMFromSCM (/rpms/mldonkey:8013f45d7fdb6095949016e6135c6c11176f83d0): open (buildvm-08.phx2.fedoraproject.org)
16300958 buildSRPMFromSCM (/rpms/mldonkey:8013f45d7fdb6095949016e6135c6c11176f83d0): open (buildvm-08.phx2.fedorapr

Review swap: ocamlbuild

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1391950" title="https://bugzilla.redhat.com/show_bug.cgi?id=1391950">https://bugzilla.redhat.com/show_bug.cgi?id=1391950</a>

This is ocamlbuild, which used to be part of the ocaml package
(indeed, it still is in Fedora <= 25) but was spun out upstream and so
needs to be packaged separately in Fedora too.

So far so easy. However the problem is you won't be able to build
this package to test it because it requires the new OCaml package
being prepared as part of:
<a href="https://fedorahosted.org/rel-eng/ticket/6486#comment:13" title="https://fedorahosted.org/rel-eng/ticket/6486#comment:13">https://fedorahosted.org/rel-eng/ticket/6486#comment:13</a>
For the same reason it cannot easily be built by 'fedora-review'
unless you set up a local repo for mock or something like that.