I'm sure not many people have RISC-V machines cluttering their homes
and offices, but in case you can now run Fedora 27 on 64 bit RISC-V (RV64GC).

We have:

- A choice of GCC 7.3.1 or GCC 8
- Perl, Python, Ruby, Erlang, OCaml, Lua, Tcl/Tk, ...
- vi, emacs, git, rpm-build, etc.
- PostgreSQL and MariaDB.
- TeXlive.
- Most of X11, Wayland and the basics of GNOME.
- A few games (quake2!)

A practical solution is to run it under qemu.

zerofree is a package that can take an ext2 (only?) filesystem, work
out what parts of the filesystem are not used, and either zero them or
sparsify them.

This was useful in about 2009 when I added it to Fedora. However
nowadays it's more convenient to use the equivalent kernel
functionality (via the ‘fstrim’ command or equivalent ioctls).

sln (staticly linked ‘ln’) was removed from glibc recently:

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

The explanation for this was:

"The sln program is no longer useful, so we will not ship it anymore."

and it was removed from Rawhide 3 days later.

There are some %post scripts which still use this, notably
ca-certificates, so that's now broken.

What does it mean?

Rich.

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

The following comment has been added to the libguestfs-1.36.13-1.fc26 update:

bodhi - 2018-02-13 03:01:37.555909 (karma: 0)
Bodhi is unable to request this update for stabilization: invalid syntax (ssl.py, line 7)

To reply to this comment, please visit the URL at the bottom of this mail

================================================================================
libguestfs-1.36.13-1.fc26
================================================================================
Update ID: FEDORA-2018-49

It looks as if upstream RISC-V / glibc teams settled on some exciting
new paths to use for libc.so.6:

<a href="https://sourceware.org/ml/libc-alpha/2018-01/msg00969.html" title="https://sourceware.org/ml/libc-alpha/2018-01/msg00969.html">https://sourceware.org/ml/libc-alpha/2018-01/msg00969.html</a>

In short, on normal 64 bit hardware which is all we really care about,
it'll use /lib64/lp64d/libc.so.6.

For Fedora we've settled on supporting only RV64GC as a baseline,
which means we don't care about hardware which lacks floating point,
nor 32 bit-only hardware since that is likely to be embedded and too
small to run Linux (32 bit embedded hardware is best served by
cross-compilers).

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

This build fails, but only on s390x:
<a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023">https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023</a>

The strange this is that libiscsi is not installed into the build root
on s390x (but it is on other architectures) and that apparently causes
the missing dependency which causes the build to fail.

Rich.

binutils 2.30 has been out for about a week. Will we get it in
Rawhide soon? It has some modest enhancements related to the RISC-V
architecture.

Rich.

About a month ago I posted about the state of the RISC-V architecture
for Fedora:

<a href="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/thread/EYY4TFJTV66EAG322F3E6V6TA7I3RZAZ/" title="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/thread/EYY4TFJTV66EAG322F3E6V6TA7I3RZAZ/">https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject....</a>

Quoting from that email:

| 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.

Can someone decode what this means?

If anyone notices Ruby programs which suddenly start to throw stack
overflow errors (SystemStackError or the error message
"stack level too deep") but *only* in the latest Rawhide (glibc >=
2.26-9000, ruby >= 2.5.0), then I'm interested to hear from you.

Rich.

<a href="https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&amp;oldid=508864" title="https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&amp;oldid=508864">https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval&amp;oldid=...</a>
says:

"Packages which need rpcgen will have to add BuildRequires: libtirpc-devel to their spec files."

but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen.

Rich.

----- Forwarded message from "Richard W.M. Jones" < ... at redhat dot com> -----

I've almost reached the end of the allotted time available for
bootstrapping Fedora/RISC-V for a second time, so this is a status
report describing what I found and how far I got.

Background
Fedora is a binary Linux distribution.

There's a rather prominent and obviously serious bug in open-vm-tools
right now which causes the daemon to segfault. It seems like each
time this happens we get a new bug filed in Bugzilla. So far over 50
bugs have been filed ...

Yes we know, and someone from VMware is working on it, but it probably
won't get fixed until the New Year.

Can we temporarily stop new bugs being filed by abrt for this
component (open-vm-tools)?

Rich.

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.

<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.

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.

(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.

<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.

<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.

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:

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

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.

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.

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

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.

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.

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.

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

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.

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.