DevHeads.net

Postings by Richard W.M. Jones

Is there some problem uploading sources now?

To answer my own question, there's definitely some kind of problem ...

$ fedpkg new-sources nbdkit-1.3.3.tar.gz nbdkit-1.3.3.tar.gz.sig
Could not execute new_sources: Error occurs inside the server.
$ fedpkg sources
Downloading nbdkit-1.3.3.tar.gz
######################################################################## 100.0%
Remove downloaded invalid file ./nbdkit-1.3.3.tar.gz
Could not execute sources: Server returned status code 404

With -v it gives a long stack trace which seems to be some kind
of server problem I suppose:

$ fedpkg -v new-sources nbdkit-1.3.3.tar.gz nbdkit-1.3.3.tar.gz

Unified Unison package (again)

Previously discussed several times, most recently:

* 2015 <a href="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/thread/KQ523Z3S3VUATKU6V2NASAPGBKR5EJWC/" title="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/thread/KQ523Z3S3VUATKU6V2NASAPGBKR5EJWC/">https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject....</a>
* 2011 <a href="https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.html#157495" title="https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.html#157495">https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.ht...</a>

Unison is a fairly widely used file synchronization package. Think of
it as a more efficient, multi-directional 'rsync'.

Unison has the unfortunate property that versions of Unison are not
compatible with each other unless they have the exact same major.minor
release. eg.

NEEDINFO denial of service attack

<a href="https://pagure.io/fesco/issue/1736" title="https://pagure.io/fesco/issue/1736">https://pagure.io/fesco/issue/1736</a>

I've had about 100 bugs set to NEEDINFO of me to check if some obscure
Fedora package is vulnerable to some 1 or 2 year old bug.

Is this a useful use of anyone's time?

I am going to close them all WONTFIX.

Rich.

FYI: OCaml 4.07 (beta2 then release) rebuild ongoing

OCaml 4.07 is due to be released shortly. I'm currently doing a
mostly automated rebuild of OCaml packages against 4.07-beta2. When
4.07 comes out I'll do another one against that.

This all happens into the f29-ocaml side tag in Koji, so this should
not affect anyone, but if you want to test the new packages please do
and let me know how that goes.

Rich.

You can now run Fedora 27 on 64 bit RISC-V machines (or qemu)

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.

Intent to retire: zerofree

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

Removal of sln

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.

"Bodhi is unable to request this update for stabilization: invalid syntax (ssl.py, line 7)"

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

glibc, riscv64, multilib, /lib64 etc

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

libiscsi "missing" on s390x?

<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

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.

FYI: Fedora/RISC-V third and final bootstrap

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.

ocaml-4.04.0-11.fc26]

Can someone decode what this means?

Rawhide / ruby / SystemStackError / "stack level too deep"

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.

rpcgen?

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

FYI Fwd: Status of the second bootstrap of Fedora/RISC-V

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

Anything we can do to temporarily halt new bugs filed by abrt for open-vm-tools?

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.

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.