I don't know if this is a problem with this specific version of koji,
or our Koji builders, but:

$ koji download-build nbdkit-1.7.3-1.fc30 --arch=x86_64 --arch=noarch
Downloading: nbdkit-ext2-plugin-1.7.3-1.fc30.x86_64.rpm
2018-09-19 10:14:21,056 [ERROR] koji: PermissionError: [Errno 13] Permission denied: 'nbdkit-ext2-plugin-1.7.3-1.fc30.x86_64.rpm'

$ rpm -q koji
koji-1.16.0-1.fc29.noarch

This happens with other fc30 builds I have tried to download too.

Rich.

I just hit a weird bug. When I typed:

$ sudo dnf update --best /mnt<tab>sc<tab>

bash exited (and with it, my ssh session) saying:

*** stack smashing detected ***: <unknown> terminated
Connection to srv closed.

This was after updating to glibc-2.28-9.fc29.x86_64.
Unfortunately I cannot seem to reproduce it on demand.

The good news is that a coredump was collected. The bad news is
it looks pretty useless:

Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)):
#0 0x00007f13c71ce46f in ?? ()
#1 0x0000000000000000 in ?? ()

Before I file a bug, what component should be used?

I've rebased mingw-openssl to match the latest version in Fedora
Rawhide. This fixes a number of CVEs, but also it's the version with
the new API.

I have kicked off rebuilds for (hopefully) all dependent packages.

Rich.

This build:

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

changed the soname from libconfig.so.9 to libconfig.so.11 thus
breaking a number of packages.

I can't find any announcement.

Rich.

OCaml 4.07.0 was released on Tuesday and it's in Fedora Rawhide today.
All packages that use OCaml have been recompiled except:

- why3: "Error: Unbound module Stdlib" - probably needs an
upstream change

If you see any other problems related to OCaml compilation with the
new package then let me know.

Rich.

Hoard, a memory allocator, fails to build in Fedora for a
long time.

I posted about this over a year ago:

<a href="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/message/2B254TXRF443HGGT2NELAQXEYFTQBLEN/" title="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/message/2B254TXRF443HGGT2NELAQXEYFTQBLEN/">https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject....</a>

at which time the upstream owner claimed they would become a packager
and fix it. However that didn't happen, so I'm really going to orphan
it now, and recommend that it is retired asap.

Rich.

Just wanted to bring this to wider attention:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1592374" title="https://bugzilla.redhat.com/show_bug.cgi?id=1592374">https://bugzilla.redhat.com/show_bug.cgi?id=1592374</a>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1593411" title="https://bugzilla.redhat.com/show_bug.cgi?id=1593411">https://bugzilla.redhat.com/show_bug.cgi?id=1593411</a>
<a href="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/thread/YCBS5Y33YFBN2NPNPRUH6YJQFB5CVQ4F/" title="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/thread/YCBS5Y33YFBN2NPNPRUH6YJQFB5CVQ4F/">https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.or...</a>

There is no kernel being built on i686. This breaks several
assumptions:

(1) Any package which depends on a kernel module by requiring
‘kmod(foo.ko)’ will no longer be installable on i686.

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

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.

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

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.

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.