DevHeads.net

Postings by Colin Walters

Why Atomic Host should be built using Modularity

There was a discussion today in the Atomic WG about using Modules.
Meeting log: <a href="https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-August/msg00004.html" title="https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-August/msg00004.html">https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-...</a>
Agenda discussion: <a href="https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-August/msg00002.html" title="https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-August/msg00002.html">https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-...</a>
(Side note; this doc was originally stored at <https://gist.github.com/cgwalters/c69bf2091eab7c1af316d0d7dd41f530>)

This post is the "why" that I'd written earlier.

atomic7-testing repo content vanished?

<a href="https://cbs.centos.org/repos/atomic7-testing/" title="https://cbs.centos.org/repos/atomic7-testing/">https://cbs.centos.org/repos/atomic7-testing/</a>

used to have content, but no longer does. I tried doing a
new build:
<a href="https://cbs.centos.org/koji/taskinfo?taskID=187981" title="https://cbs.centos.org/koji/taskinfo?taskID=187981">https://cbs.centos.org/koji/taskinfo?taskID=187981</a>

But it hasn't shown up there.

Increasing compatibility with rpm-ostree for host packages

Hi,

rpm-ostree is the underlying hybrid image/package system for the Fedora Atomic Host edition.
The layering functionality however requires some potential changes
in your packages.

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

is a recent bug that shows one example. You can find more information
in the current bugzilla tracker:

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

If your software makes sense directly on the host (as opposed to always
in a container), please take a look.

keeping Extras in sync with Core

So right now following the instructions on:
<a href="https://wiki.centos.org/Cloud/Docker" title="https://wiki.centos.org/Cloud/Docker">https://wiki.centos.org/Cloud/Docker</a>
results in a non-working Docker because the
version in Extras hasn't been rebuilt yet, and
there's a strong dependency on selinux policy.

I'm still trying to wade through the pile of
virt7* repos to find something working,
right now hitting a requirement on `skopeo-containers`.

In the future, can we ensure that there's a "CR" version
of Extras[1] that is built at the same time, and they're all released at once?

We also need to figure out how CR interacts with the CBS
content better.

[1] And ideally other thing

Using pungi for CentOS (AH specifically)

Hey, so upstream Fedora has been working on this:
<a href="https://pagure.io/pungi" title="https://pagure.io/pungi">https://pagure.io/pungi</a>

And I'd like to discuss trying to use it for Atomic Host
work. The concept of a "compose" that ties together
the ISO and cloud images is nice for example. It's
going to need to gain some more sophistication
around OSTree, and there'd likely be some details
that need changing such as how signing happens.

But having a common codebase here would be nice,
and I think we could also stop doing this in Jenkins
for <a href="https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel" title="https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel">https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel</a>
too.

Switching to NetworkManager dhcp=internal

Hey, so as part of the discussion about NetworkManager vs systemd-networkd,
one thing that happened is networkd started exposing its DHCP code as
a shared library, and NetworkManager learned to use it if one specifies

```
[main]
dhcp=internal
```

in /etc/NetworkManager/NetworkManager.conf.

adopting the Docker base image into Atomic WG

Now that Cloud -> Atomic and will be focusing on Project Atomic, can we move the
Docker base image into this group from the "Fedora Base" group?

It never really made sense to me in Base; in:

$ git log --format='%ae' fedora-docker-base.ks | sort -u
<a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>
<a href="mailto: ... at ausil dot us"> ... at ausil dot us</a>
<a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>
<a href="mailto: ... at fedoraproject dot org"> ... at fedoraproject dot org</a>
<a href="mailto: ... at gmail dot com"> ... at gmail dot com</a>
<a href="mailto: ... at mattdm dot org"> ... at mattdm dot org</a>
<a href="mailto: ... at fedoraproject dot org"> ... at fedoraproject dot org</a>
<a href="mailto: ... at gmail dot com"> ... at gmail dot com</a>
<a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>
<a href="mailto: ... at verbum dot org"> ... at verbum dot org</a>

Most of the recent committers are outside of the Base group.

And it makes sense to me to have synchronized landing pages/information
for At

rpm-ostree 2016.4 now with package layering

rpm-ostree 2016.4:

<a href="https://github.com/projectatomic/rpm-ostree/releases/tag/v2016.4" title="https://github.com/projectatomic/rpm-ostree/releases/tag/v2016.4">https://github.com/projectatomic/rpm-ostree/releases/tag/v2016.4</a>

is now in Bodhi:

<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2016-2b9342c5cc" title="https://bodhi.fedoraproject.org/updates/FEDORA-2016-2b9342c5cc">https://bodhi.fedoraproject.org/updates/FEDORA-2016-2b9342c5cc</a>
<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2016-bfecf6abed" title="https://bodhi.fedoraproject.org/updates/FEDORA-2016-bfecf6abed">https://bodhi.fedoraproject.org/updates/FEDORA-2016-bfecf6abed</a>

Remember, to try it, you can rebase an existing Atomic Host system using:
<a href="https://fedoraproject.org/wiki/QA:Updates_Testing" title="https://fedoraproject.org/wiki/QA:Updates_Testing">https://fedoraproject.org/wiki/QA:Updates_Testing</a>

(Also in our CentOS devel stream: <a href="https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel" title="https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel">https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel</a> )

This release has a number of changes, but as the git tag says, I think
the package layering that we have now finally brings into focus
a long-held go

Migrating https://github.com/cgwalters/centos-release-atomic-host-devel into CentOS namespace

Hi,

I'm working on a "devel/continuous" Atomic Host stream[1] and we were pulling in `centos-release` via deps which I think is wrong. Also, I needed to fix a bug[2].

Can we migrate:
<a href="https://github.com/cgwalters/centos-release-atomic-host-devel" title="https://github.com/cgwalters/centos-release-atomic-host-devel">https://github.com/cgwalters/centos-release-atomic-host-devel</a>
into the CentOS namespace?

Re: [CentOS-devel] numbering and building the CentOS Atomic story

Thanks for posting this!

On Wed, Jul 15, 2015, at 06:18 AM, Karanbir Singh wrote:

"CentOS.devel"

For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com.

Time sync

Hi,

Since <a href="http://lists.freedesktop.org/archives/systemd-devel/2015-March/029482.html" title="http://lists.freedesktop.org/archives/systemd-devel/2015-March/029482.html">http://lists.freedesktop.org/archives/systemd-devel/2015-March/029482.html</a>
systemd-timesyncd can be enabled in more places. (That change isn't in F22 now
but could be backported easily). Looking at the state
of things here, there was a previous discussion on the desktop list:
<a href="https://lists.fedoraproject.org/pipermail/desktop/2014-September/010751.html" title="https://lists.fedoraproject.org/pipermail/desktop/2014-September/010751.html">https://lists.fedoraproject.org/pipermail/desktop/2014-September/010751....</a>

From an Atomic Host perspective,
systemd-timesyncd now looks fairly equivalent to chrony, and is 140k
that's already shipped.

consolidating some of the Atomic changes

Right now we have:

<a href="https://fedoraproject.org/wiki/Changes/AtomicHost" title="https://fedoraproject.org/wiki/Changes/AtomicHost">https://fedoraproject.org/wiki/Changes/AtomicHost</a>

Which I think encompasses:

<a href="https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic" title="https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic">https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic</a>
<a href="https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic" title="https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic">https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic</a>

Any objections to consolidating?

New wiki page: https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintainers

Recently, I've ended up interacting with Fedora packages that use several different "higher order" or "layered" tools on top of fedpkg.

I created this page:

<a href="https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintainers" title="https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintainers">https://fedoraproject.org/wiki/Layered_build_scripts_for_package_maintai...</a>

which attempts to enumerate the ones I know of. It's certainly non-exhaustive,
so if you maintain a tool that's not listed there, please add it!

Note: polkit daemon now optional (notably with NM)

I pushed: <a href="http://pkgs.fedoraproject.org/cgit/polkit.git/commit/?id=1224d7b427a507339087e2f72c481b560c85149b" title="http://pkgs.fedoraproject.org/cgit/polkit.git/commit/?id=1224d7b427a507339087e2f72c481b560c85149b">http://pkgs.fedoraproject.org/cgit/polkit.git/commit/?id=1224d7b427a5073...</a>
Built as: <a href="http://koji.fedoraproject.org/koji/taskinfo?taskID=8072916" title="http://koji.fedoraproject.org/koji/taskinfo?taskID=8072916">http://koji.fedoraproject.org/koji/taskinfo?taskID=8072916</a>

Which makes polkit optional if NM (or anything else that links to libpolkit) is used. This is a follow up to <a href="http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=53e244bef637c3e4004961651d4ed23eda7393b5" title="http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=53e244bef637c3e4004961651d4ed23eda7393b5">http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=53e...</a>

I suspect for most people this is a "duh, finally" thing. Upgrades should work fine (polkit gains a new dep on polkit-libs).

Request to join the Atomic SIG

Hi,

I'd like to join the Atomic SIG. I am upstream author of one of the
components (rpm-ostree), and have contributed to others like systemd,
and SELinux, as well as work on packaging Kubernetes in
<a href="http://copr.fedoraproject.org/coprs/walters/atomic-next/" title="http://copr.fedoraproject.org/coprs/walters/atomic-next/">http://copr.fedoraproject.org/coprs/walters/atomic-next/</a>.

I'm particularly interested in how we maintain the atomic host ostree
composes and integrating it with the CentOS infrastructure.

maintenance of "setup" and https://fedoraproject.org/wiki/Packaging:UsersAndGroups

Hi,

I was looking at user/group stuff more as part of the other thread on
<a href="https://fedoraproject.org/wiki/Changes/SystemdSysusers" title="https://fedoraproject.org/wiki/Changes/SystemdSysusers">https://fedoraproject.org/wiki/Changes/SystemdSysusers</a> - but let's
ignore that for a second.

So on
<a href="https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation" title="https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation">https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allo...</a>
- I followed the link to the "uidgid" section, and noticed "Hey, we have
another uid/gid listing here".

Scanning that list, I saw "polkituser"...which:
1) Doesn't exist - the polkit package allocates a user named "polkit"
2) Isn't used even if it did: polkit allocates a dynamic uid/gid.

Now Mirek and I currently maintain polkit, and at least

New Fedora 22 Change proposal: systemd-sysusers

Hi, for Atomic I'd like to investigate the new systemd-sysusers, so I
wrote up a Change:

<a href="https://fedoraproject.org/wiki/Changes/SystemdSysusers" title="https://fedoraproject.org/wiki/Changes/SystemdSysusers">https://fedoraproject.org/wiki/Changes/SystemdSysusers</a>

Note: for Fedora 22.

The main motivation for me is it would allow Atomic to not be a Remix
due to the not-in-Fedora shadow-utils patch[1] Further, it would
potentially allow us to migrate away from /usr/lib/passwd and
nss-altfiles which would be really nice. Though I'm still exploring
that.

[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1098304" title="https://bugzilla.redhat.com/show_bug.cgi?id=1098304">https://bugzilla.redhat.com/show_bug.cgi?id=1098304</a>

new dbus-1.8.4-1.fc21

Hi,

I finally rebased dbus to the latest stable release in rawhide. I
tested it lightly by upgrading a F20 cloud image to rawhide, but didn't
get a chance to play around with it on a desktop system. If you see any
issues, don't hesitate to file a bug. Thanks!

updated rpm-ostree composes running again

Hi, just a quick note for those of you tracking the rpm-ostree rawhide
composes from:
<a href="http://rpm-ostree.cloud.fedoraproject.org/#/" title="http://rpm-ostree.cloud.fedoraproject.org/#/">http://rpm-ostree.cloud.fedoraproject.org/#/</a>

The tree composes are running again now, they'd been broken for a week
or so.

The reason the compose broke was due to this bug causing a cascade:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=705443" title="https://bugzilla.redhat.com/show_bug.cgi?id=705443">https://bugzilla.redhat.com/show_bug.cgi?id=705443</a>

And then fedora-release being in the bootstrap set was problematic
since we wanted to install generic-release later (because of
shadow-utils, which has a not-in-Fedora patch).

fedora-atomic discussion point: /usr/lib/passwd

For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.

Patch is linked from my post here:
<a href="http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010099.html" title="http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010099.html">http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010...</a>

Also, some discussion in the glibc bug:
<a href="https://sourceware.org/bugzilla/show_bug.cgi?id=16142" title="https://sourceware.org/bugzilla/show_bug.cgi?id=16142">https://sourceware.org/bugzilla/show_bug.cgi?id=16142</a>

What I'd like to open is a discussion about whether /usr/lib/passwd is
the right thing long term.

Fedora Atomic Initiative (rpm-ostree 2014.5)

Hi,

I'm happy to announce a new version of rpm-ostree - v2014.5:
<a href="https://github.com/cgwalters/rpm-ostree/commit/848fdcb350877ab509c2fef3e482d8da8c97c717" title="https://github.com/cgwalters/rpm-ostree/commit/848fdcb350877ab509c2fef3e482d8da8c97c717">https://github.com/cgwalters/rpm-ostree/commit/848fdcb350877ab509c2fef3e...</a>

With this new release, there is now a new overarching name/brand for
the project formerly known as "rpm-ostree":

Fedora Atomic Initiative
The new website replaces the old one:

<a href="http://rpm-ostree.cloud.fedoraproject.org/" title="http://rpm-ostree.cloud.fedoraproject.org/">http://rpm-ostree.cloud.fedoraproject.org/</a>

The website is hopefully more informative now.

Announce: fedostree/rpm-ostree v2014.3

Hello devel@,

I'm excited to announce the first public release (v2014.3) of the
fedostree/rpm-ostree project.

The web page is here:

<a href="http://rpm-ostree.cloud.fedoraproject.org/#/" title="http://rpm-ostree.cloud.fedoraproject.org/#/">http://rpm-ostree.cloud.fedoraproject.org/#/</a>

rpm-ostree is a quite new, raw, and also quite unofficial project (the instance
above is in the Fedora private scratch cloud). It is suitable for
evaluation primarily by engineers who are working on
build/packaging/deployment tooling in Fedora, and advanced testers.

mozjs17 porting

Hi,

For the next GNOME 3.10 cycle I'd like to port our dependencies to
mozjs17, the new Spidermonkey release.

See:
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=735599" title="https://bugzilla.mozilla.org/show_bug.cgi?id=735599">https://bugzilla.mozilla.org/show_bug.cgi?id=735599</a>
<a href="https://mail.gnome.org/archives/desktop-devel-list/2013-March/msg00135.html" title="https://mail.gnome.org/archives/desktop-devel-list/2013-March/msg00135.html">https://mail.gnome.org/archives/desktop-devel-list/2013-March/msg00135.html</a>

gjs is already ported and hard-depends on it, and I will be working with
Tim Lunn (and hopefully others) on porting other GNOME dependencies such
as polkit.

Omitting those then, in the Fedora package collection, these would also
need to be ported.

(actually I meant f15 branched)

Just for reference, I meant Fedora 15, old habit made me say "rawhide".

gobject-introspection 0.9.5 rebuilds coming to rawhide

Just a quick heads up that I'm going to be updating introspection to
(at least) 0.9.5 in rawhide.

For libraries, this is generally a simple rebuild with no impact on
primary functionality. However
if you are a library maintainer, do see
<a href="http://mail.gnome.org/archives/gnome-announce-list/2010-September/msg00019.html" title="http://mail.gnome.org/archives/gnome-announce-list/2010-September/msg00019.html">http://mail.gnome.org/archives/gnome-announce-list/2010-September/msg000...</a>
And particularly please try the new --warn-all flag.

For apps:
Many more functions require annotations, as the scanner does less
(incorrect) guessing. We
are working on adding annotations for the GNOME 3 (F15ish cycle).

clutter -> 1.3

Heads up to Clutter consumers - I'm updating it in f15 to the 1.3
(master) branch. I've tested GNOME Shell and quadrapassel, feel free
to CC me for other fallout.

assigning of abrt crashes

Hi,

I'd like to propose a general rule that ABRT crash logs should remain
"assigned" to the actual application, unless an actual investigation
has been done and there's a "reasonable" certainty the flaw is in the
library code in which it happened to crash.

Rationale: Applications are more likely to be buggy (I'm just
asserting this, but it seems obvious), and just because a crash
happened inside the library, particularly when C/C++ is involved,
means nothing; the flaw could still be in the application.

rpath handling

Hello internet,

So I lost yesterday and part of today to what I thought was a libtool
bug, but turned out to be an interaction with Fedora's current primary
recommendation for rpath handling:

<a href="http://fedoraproject.org/wiki/RPath_Packaging_Draft" title="http://fedoraproject.org/wiki/RPath_Packaging_Draft">http://fedoraproject.org/wiki/RPath_Packaging_Draft</a>

The main recommendation is to use sed to reach into libtool's guts,
which normally works (well, until libtool changes, then we have a lot
of copy and paste to fix, but that's another story). However, glib2
uses a program called "gtk-doc" which requires actually running an
uninstalled binary to extract some data from it.