DevHeads.net

Postings by Jonathan Dieter

Can we use SCLs for building for EPEL 6?

So, the background is that I'd like to build zchunk for EPEL 6 (it's
already built for EPEL 7).

How to fix dnf segmentation fault (zchunk metadata is re-enabled)

FESCo has given us the go-ahead to turn zchunk metadata on again[1] for
the F30 fedora repository after the librepo segmentation fault bug[2]
was fixed. An updated librepo[3] was built a week ago and was pushed
to stable five days ago, so most beta users should have the new
version.

If you're using F30 and have librepo-1.9.6-1.fc30, please update to
librepo-1.9.6-2.fc30 as soon as possible!

PSA: workaround for segfault when running dnf update in F30

<tl;dr>
librepo-1.9.6 has a major bug that will cause a segfault when a
repository has zchunk metadata. To temporarily work around the
problem, set zchunk=False in /etc/dnf/dnf.conf or wait until the next
updates push comes out
</tl;dr>

About a week ago, we disabled zchunk metadata in the main F30
repository because of arm-specific compose problems[1].

Call for zchunk repodata testers

Just a heads up Rawhide has had zchunked metadata for almost three
weeks, and I'd greatly appreciate some more testing on the client side
before we finish pushing the client changes to Rawhide.

If you're running Rawhide, are willing to test, and have backups of
libdnf and librepo, please enable the COPR by running:

dnf copr enable jdieter/dnf-zchunk
dnf update librepo libdnf

At this point all tools using libdnf will default to zchunked metadata
if it's available.

If the second day's repository download size for Rawhide is less than
54MB, you'll know everything's working correctly.

--- Det

Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

For reference, this is in reply to Paul's email about lifecycle
objectives, specifically focusing on problem statement #1[1].

<tl;dr>
Have rpm use zchunk as its compression format, removing the need for
deltarpms, and thus reducing compose time. This will require changes
to both the rpm format and new features in the zchunk format.
</tl;dr>

*deltarpm background*
As part of the compose process, deltarpms are generated between each
new rpm and both the GA version of the rpm and the previous version.

Cannot find -latomic when building for epel7 aarch64

I'm trying to build duperemove[1] for epel7[2], and it's building on
all the arches except aarch64.

I'm BR'ing libatomic, but the error it gives in build.log[3] for
aarch64 is:
/usr/bin/ld: cannot find -latomic

All current Fedora release builds were fine.

I'm sure I'm missing something obvious, but does anyone have an idea
what's going on?

[1] <a href="https://github.com/markfasheh/duperemove" title="https://github.com/markfasheh/duperemove">https://github.com/markfasheh/duperemove</a>
[2] <a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=30336065" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=30336065">https://koji.fedoraproject.org/koji/taskinfo?taskID=30336065</a>
[3] <a href="https://kojipkgs.fedoraproject.org//work/tasks/6089/30336089/build.log" title="https://kojipkgs.fedoraproject.org//work/tasks/6089/30336089/build.log">https://kojipkgs.fedoraproject.org//work/tasks/6089/30336089/build.log</a>

Missing deltarpms?

It seems that deltarpms aren't being kept from one push to another for
Fedora 13 (and, also it seems, Fedora 11). For example, there's an
openoffice update, but though there were deltarpms when it first came
out, they've gone now. Where should I report the bug?

Jonathan

Deltarpm volunteers welcome (was Re: Fedora 13 continuing the tradition of being an update monster)

On that subject, anyone who wants to fix this would be much appreciated.
The problem is that when deltarpm *creates* a new deltarpm, it reads the
full uncompressed old rpm and uncompressed new rpm into RAM. The way to
fix it is to delta chunks of the old and new rpm at a time.

Unfortunately, given the way the code is written, it's not a trivial fix
and I haven't had time over the last year or so to get it done.

So volunteers are welcome.

Jonathan

Missing iwl5150-firmware package?

Is there some reason we don't have a iwl5150-firmware package? Or
that /lib/firmware/iwlwifi-5150-2.ucode isn't included in
iwl5000-firmware?

Just asking because I was helping someone on #fedora get their Intel
5150ABN working, and it seems that this missing firmware was the reason
it wasn't. The firmware is available from
<a href="http://intellinuxwireless.org/?p=iwlwifi&amp;n=downloads" title="http://intellinuxwireless.org/?p=iwlwifi&amp;n=downloads">http://intellinuxwireless.org/?p=iwlwifi&amp;n=downloads</a>.

Jonathan