rpm-ostree 2018.6 (and updates since 2018.3)
by Colin Walters
This is one of a semi-regular "rollup"/"highlights" post of what's happening
in the rpm-ostree project, used by Fedora Atomic Host, as well as Silverblue[1],
and planned to be used by the converged [Fedora CoreOS](https://coreos.fedoraproject.org/)
We release approximately once a month.
The last post here in February[2] was for 2018.3.
We just released 2018.6:
https://github.com/projectatomic/rpm-ostree/releases/tag/v2018.6
Releases happen approximately once a month, and quite a lot has happened
since Feburary. One of the major aims is to fully flesh out support for automatic
updates. The biggest work item actually landed in libostree, called "deployment staging".
https://github.com/ostreedev/ostree/pull/1503
Here's a recent blog post about it in relation to Silverblue:
https://miabbott.github.io/2018/06/13/rpm-ostree-automatic-updates.html
But this will all obviously apply as well to the converged Fedora CoreOS, although
one of our primary targets for Fedora CoreOS is Kubernetes-based systems, and
we have an "operator" for managing host updates and reboots:
https://github.com/ashcrow/container-linux-update-operator/tree/spike
that uses the rpm-ostree DBus API, and we will likely aim to polish (and turn
into a real operator[3]) as part of Fedora CoreOS.
For this audience in particular, I want to highlight that in 2018.5 we finally
fixed using `rpm-ostree override replace`
with both kernel.rpm and systemd.rpm among others:
https://github.com/projectatomic/rpm-ostree/releases/tag/v2018.5
This means rpm-ostree based systems are now much nicer for doing development
of the OS itself - install a custom kernel, systemd, podman, docker, NetworkManager, glibc or whatever,
and know that you always have the "base tree" available offline and can reliably boot into
a previous bootloader entry if something goes wrong, and from there reset things back
to the base.
2018.6 also marks the first introduction of Rust code into the rpm-ostree codebase,
for an optional feature of using YAML for treefiles. We are testing the waters there;
if things work out well it's likely we'll pursue a path of gradual "oxidation"[4].
A lot is happening in the libostree project as well, which also releases on an approximately
monthly cadence. (Remember, libostree is independent of RPM, it's used by a variety
of distributions in different ways. Think "LVM for bootable filesystem trees with a shared library API").
libostree's latest release: https://github.com/ostreedev/ostree/releases/tag/v2018.6
The biggest change there is definitely the "staged deployment" work:
https://github.com/ostreedev/ostree/pull/1503
Which was mentioned above as a fundamental prerequisite for automatic updates.
But there's lots more, from peer-to-peer updates, improved repository locking,
improved ability to repair corrupted trees, "deployment pinning" to control
having more than 2 bootable trees, etc.
Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f0a73dfbf4
[1] https://community.teamsilverblue.org/
[2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[3] https://github.com/operator-framework/operator-sdk/
[4] https://wiki.mozilla.org/Oxidation
5 years, 9 months
Builds failing with connection refused error
by Jerry James
I don't see anything but green on status.fedoraproject.org, but the
last two builds I have submitted have both failed on s390x only with
an error that looks like this:
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1244, in runTask
response = (handler.run(),)
File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 307, in run
return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
File "/usr/lib/python2.7/site-packages/koji/util.py", line 209, in
call_with_argcheck
return func(*args, **kwargs)
File "/usr/sbin/kojid", line 1195, in handler
fn = self.localPath("work/%s" % pkg)
File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 477, in localPath
fsrc = six.moves.urllib.request.urlopen(url)
File "/usr/lib64/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib64/python2.7/urllib2.py", line 429, in open
response = self._open(req, data)
File "/usr/lib64/python2.7/urllib2.py", line 447, in _open
'_open', req)
File "/usr/lib64/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
File "/usr/lib64/python2.7/urllib2.py", line 1230, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/lib64/python2.7/urllib2.py", line 1200, in do_open
raise URLError(err)
URLError: <urlopen error [Errno 111] Connection refused>
Are the s390x builders offline? The host for the most recent build is
buildvm-s390x-07.s390.fedoraproject.org.
Thanks,
--
Jerry James
http://www.jamezone.org/
5 years, 9 months
F29 System Wide Change: Fedora 29 Boost 1.67 upgrade
by Jan Kurik
= Proposed System Wide Change: Fedora 29 Boost 1.67 upgrade =
https://fedoraproject.org/wiki/Changes/F29Boost167
Owner(s):
* Jonathan Wakely <jwakely at fedoraproject dot org>
This change brings Boost 1.67.0 to Fedora 29. This will mean F29 ships
with a recent upstream Boost release.
== Detailed description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boost-ese seen in output from g++. Such care is to be expected
this time around as well.
The equivalent changes for previous releases were Fedora 22 Change
[https://fedoraproject.org/wiki/Changes/F22Boost158] and Fedora 23
Change [https://fedoraproject.org/wiki/Changes/F23Boost159] and Fedora
24 Change [https://fedoraproject.org/wiki/Changes/F24Boost160] and
Fedora 26 Change [https://fedoraproject.org/wiki/Changes/F26Boost163]
and Fedora 27 Change
[https://fedoraproject.org/wiki/Changes/F27Boost164] and Fedora 28
Change [https://fedoraproject.org/wiki/Changes/F28Boost166].
== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
** Request a "f29-boost" build system tag (discussion
[http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html]):
7278 (similar ticket for F28: https://pagure.io/releng/issue/7278)
** Build boost into that tag (take a look at the build #606493
[http://koji.fedoraproject.org/koji/buildinfo?buildID=606493] for
inspiration)
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients
(by fixing the client, or Boost).
* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
* Release engineering:
#7595 [https://pagure.io/releng/issue/7595]
** List of deliverables:
All deliverables will include updated Boost packages.
* Policies and guidelines:
** Apart from scope, this is business as usual, so no policies, no guidelines.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
5 years, 9 months
sisu-mojos license change
by Mikolaj Izdebski
License of rpms/sisu-mojos was updated from EPL to EPL-1.0
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
5 years, 9 months
sisu license change
by Mikolaj Izdebski
License of rpms/sisu was changed from EPL to EPL-1.0
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
5 years, 9 months
junit5 license change
by Mikolaj Izdebski
On Wed Jun 27 2018 License tag of rpms/junit5 was changed
from "EPL" to "EPL-2.0"
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
5 years, 9 months
junit license change
by Mikolaj Izdebski
License tag of rpms/junit was changed
from "EPL" to "EPL-1.0"
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
5 years, 9 months
hawtjni license change
by Mikolaj Izdebski
License tag of rpms/hawtjni was changed
from: "ASL 2.0 and EPL and BSD"
to: "ASL 2.0 and EPL-1.0 and BSD"
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
5 years, 9 months
base64coder license change
by Mikolaj Izdebski
License tag of rpms/base64coder was changed
from: "EPL or LGPLv2+ or GPLv2+ or ASL 2.0 or BSD"
to: "EPL-1.0 or EPL-2.0 or LGPLv2+ or GPLv2+ or ASL 2.0 or BSD"
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
5 years, 9 months
Python question: Dealing with epylog
by Stephen John Smoogen
Epylog is a python27 program and I have not had the time to convert it
to python3 and won't until later this fall. As I don't want this to be
a FTBFS during rebuilds.. I see the following:
1. Retire it in rawhide
2. Make it a python27 module?
I am looking for advise on which people would recommend.
Thank you
--
Stephen J Smoogen.
5 years, 9 months