DevHeads.net

Postings by Richard W.M. Jones

FYI: Fedora/RISC-V second bootstrap

I thought I'd be interesting to say something about Fedora on RISC-V
to a wider audience ... and there's some news too.

First the basics: RISC-V is a free and open Instruction Set
Architecture (ISA). You can read more about it on the RISC-V
Foundation's website here:

<a href="https://riscv.org/" title="https://riscv.org/">https://riscv.org/</a>

Fedora/RISC-V is a project to port Fedora to RISC-V.

Is there a "Python 3 is available" macro for spec files?

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

In this commit:

<a href="https://src.fedoraproject.org/rpms/nbdkit/c/f38f61c339f925928e8cd6e520581968105ada96" title="https://src.fedoraproject.org/rpms/nbdkit/c/f38f61c339f925928e8cd6e520581968105ada96">https://src.fedoraproject.org/rpms/nbdkit/c/f38f61c339f925928e8cd6e52058...</a>

I accidentally disabled Python 3 support on Fedora.

Is there a better way to write this? What I really need is a pair of
macros "Python 2 is supported" & "Python 3 is supported" which I can
use to conditionalize the spec file. Maybe checking if %{__python2}
and %{__python3} are non-empty?

Rich.

Intending to orphan 9 OCaml packages

I have identified a few OCaml packages which have all of the following
properties:

- no active upstream,
- a high maintenance burden,
- aren't used or useful.

I'm intending to orphan these, and recommend that they be removed in
the Fedora 29 time-frame.

american-fuzzy-lop contains exploit samples which trigger ClamAV

(Thanks to Patrick for bringing this issue to my attention.)

American Fuzzy Lop ("afl", Fedora package american-fuzzy-lop) is an
instrumentation-driven fuzzer for binary formats. ClamAV is a
(Windows?) virus scanner.

Afl's documentation comes with some demonstration vulerabilities found
by afl.

Tagging large packages (texlive) takes a very long time

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

This has been stuck in the final tagging stage for must be at least 1
hour now, possibly 2 hours.

Is there anything that can be done?

Rich.

1 review swap

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

ocaml-num used to be a part of the OCaml compiler up to 4.05.0.
It has now been spun out into a separate package.

It's marked as "legacy", but some important Fedora packages depend on
it, notably Coq.

Rich.

rjones's ocaml-4.06.0-1.fc28 failed to build - hmm, really?

Looks like success to me ...

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

Is there something I'm missing?

Rich.

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

Package: ocaml-4.06.0-1.fc28
Status: complete
Built by: rjones
ID: 995995
Started: Tue, 07 Nov 2017 18:06:21 UTC
Finished: Tue, 07 Nov 2017 18:34:16 UTC

Closed tasks:

package webkitgtk4-2.19.1-2.fc28.x86_64 requires libupower-glib.so.3()(64bit), but none of the providers can be installed

There are a bunch of problems which have just appeared
(literally in the last hour) in Rawhide:

DEBUG util.py:439: Error:
DEBUG util.py:439: Problem 1: package webkitgtk4-2.19.1-2.fc28.x86_64 requires libupower-glib.so.3()(64bit), but none of the providers can be installed
DEBUG util.py:439: - package emacs-1:25.3-3.fc28.x86_64 requires libwebkit2gtk-4.0.so.37()(64bit), but none of the providers can be installed
DEBUG util.py:439: - package upower-0.99.6-1.fc28.x86_64 requires udev, but none of the providers can be installed
DEBUG util.py:439: - conflicting requests
DEBUG util.py

FYI: OCaml 4.06 in Fedora 28 will change default mutability of strings

Since forever ...

# string_of_bool true;;
- : string = "true"
# String.blit "urgh" 0 (string_of_bool true) 0 4;;
- : unit = ()
# string_of_bool true;;
- : string = "urgh"

Since OCaml 4.02 (in 2014) it has been possible to opt in to
‘-safe-string’ to make strings immutable.

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.