DevHeads.net

Postings by Matthew Miller

Minor schedule procedure tweak (rain dates and such)

It turns out that the "Rain Date" concept is confusing to some people
(particularly where that idiom is not familiar). I propose that for F28
and onward, we keep the basic concept, but ditch that term. Instead, we
use:

* Release Date Target 1
* Release Date Target 2 (a week later).

As now, these will exist for both Beta and Final, and final will only
be pushed back if Beta Target 2 is missed.

Then (and also new), if the Beta does slip past Target 2, we add a new
"Target 3". If Beta slips to Target 3, Final slips to Target 2 (and we
don't yet add a Target 3).

Fedora Modular Server: status and game plan?

From ... at lists dot fedoraproject.org:

FWIW, AFAICT the current state of this is that we had some F27
modular composes that 'succeeded' (the last being 20170831.n.0), but
none of them contained any images at all. Since 20170831.n.0, the
compose has failed each day, apparently due to
<a href="https://pagure.io/releng/issue/7011" title="https://pagure.io/releng/issue/7011">https://pagure.io/releng/issue/7011</a> .

: Service levels and EOL expectations?

I'm looking at:

<a href="https://fedoraproject.org/wiki/Module:Guidelines#SLs_and_EOLs" title="https://fedoraproject.org/wiki/Module:Guidelines#SLs_and_EOLs">https://fedoraproject.org/wiki/Module:Guidelines#SLs_and_EOLs</a>

While not a part of the modulemd specification yet, modules will
eventually carry a Service Level (SL) value and an End of Life
(EOL) value.

The work in Changes/ArbitraryBranching will enable packagers to
select independent SLAs and EOLs for both their rpm branches as
well as their module branches.

Arbitrary Branching and solving the "Change Checkpoint? Better hit the gas!" problem

Our Change process has the basic assumption that if a Change isn't
working, we will be able to back out. But, in practice, when there are
problems, we often find it that it's easiest to shrug and go forward,
scrambling to fix problems in the change itself as well as any fallout.
I won't say this is a _failure_ exactly — with the Change process, at
least, we do have that checkpoint where we know the scramble is needed
rather than waiting until the very last minute.

Fedora, apps, and the Flatpak opportunity

Containers (and particularly, Docker-style containers with Kubernetes
orchestration) are rapidly taking over the server world. This is not
hyperbole, and while one might fairly throw "everything old is new
again", it's not a fad. This is a real generational shift.

We're at the forefront of this with Fedora Atomic Host (and OpenShift
Origin in Fedora as well). This is awesome.

I think these technologies are going to come to the desktop, too.

Fedora 26 is officially here!

Fedora 26 is here! Read the official announcement with
hyperlinks and fancy formatting and details and (especially)
thanks to the community at:

<a href="https://fedoramagazine.org/fedora-26-is-here/" title="https://fedoramagazine.org/fedora-26-is-here/">https://fedoramagazine.org/fedora-26-is-here/</a>

or just go ahead and grab it from

<a href="https://getfedora.org/" title="https://getfedora.org/">https://getfedora.org/</a>

super-drafty F28 and F29 schedules

It's probably no surprise if you've ever heard me talk that I really
think hitting early May / late October is important for our release
cadence.

A proposal for stream naming

Okay, so, I decided to get my hands dirty with this to make sure my
conceptual understanding stays in sync with the reality. And, it turns
out we really do need a system-tools module. So, I'm going to make
that. And in doing so, I ran into something I think is unresolved.

An early decision needed when making a module is the label for the
stream — that is, the dist-git branch it builds from. The convention is
that within a stream, interfaces remain the same (just as now we expect
big changes from release to release, not within f25 or f26).

off-topic suggested reading: why containers really are revolutionary

I know that a lot of us in the Fedora world are from traditional IT
backgrounds.

Please note that F26 schedule does not affect F27 change deadlines

I just wanted to call out in particular this bit from Jan's note:

This means that system-wide changes for Fedora 27 should be submitted
to FESCo *before* the Fedora 26 final release. Changes which require a
mass rebuild should be in _this_ month.

Updating the Fedora Project Mission statement — please read and join the discussion

I just posted in the council-discuss mailing list about the work we did
last month towards an updated Fedora Project mission statement. Please
see:

<a href="https://lists.fedoraproject.org/archives/list/council- ... at lists dot fedoraproject.org/message/RJQWWPGDVBXPNHP6KGISKYY74CZH47UQ/" title="https://lists.fedoraproject.org/archives/list/council- ... at lists dot fedoraproject.org/message/RJQWWPGDVBXPNHP6KGISKYY74CZH47UQ/">https://lists.fedoraproject.org/archives/list/council- ... at lists dot fedo...</a>

and join the conversation there. Thank you!

Understanding the Fedora Modularity initiative (video + slides)

Hi everyone. The Fedora Council holds monthly video-based meetings
where we host a report from one of our various subprojects or official
objectives. This month, Langdon White presented on Modularity.

If you're a Fedora contributor busy in other areas and haven't paid
much attention, you might be wondering what Modularity is, exactly.
Modularity is an effort to address the "moves too fast!

CVE-2016-8655, systemd, and Fedora

In case you haven't seen: there was a recent kernel vulnerability in a
feature called "AF_PACKET". Most services don't need to use the raw
sockets this makes available, and on his blog*, Lennart Poettering notes
that systemd actually has a feature where services can whitelist or
blacklist address families, protecting them from not just this exploit
but similar classes.

The upcoming systemd v232 will include this by default for systemd's
own unit files. But, of course, that's a tiny subset of services in
Fedora. So....

Question 1: How can we take advantage of this feature in specific?

Two more concrete ideas for what a once-yearly+update schedule would look like

Trying to make this idea a little more concrete. Here's two suggestions
for how it might work. These are strawman ideas -- please provide
alternates, poke holes, etc. And particularly from a QA and rel-eng
point of view. Both of these are not taking modularity into account in
any way; it's "how we could do this with our current distro-building
process".

Option 1: Big batched update

1. Release F26 according to schedule
<a href="https://fedoraproject.org/wiki/Releases/26/Schedule" title="https://fedoraproject.org/wiki/Releases/26/Schedule">https://fedoraproject.org/wiki/Releases/26/Schedule</a>

2. At the beginning of October, stop pushing non-security updates
from updates-testing to updates

3.

Some preliminary Fedora 25 stats — and future release scheduling

The stats I get are about a week behind, which means I now have
information about the first week of the Fedora 25 release. See the
graph here:

<a href="https://mattdm.fedorapeople.org/stats/fedora-os-select-2016-11-22.png" title="https://mattdm.fedorapeople.org/stats/fedora-os-select-2016-11-22.png">https://mattdm.fedorapeople.org/stats/fedora-os-select-2016-11-22.png</a>

(and please note the caveats about what you're looking at — the numbers
on the left shouldn't be construed as "number of Fedora systems" or
anything like that).

I'd draw it in ASCII art, but the detail is hard to reproduce. :)

Anyway, there's great news: the F25 uptake is rapid.

Fedora 25 released!

Fedora 25 released!
===================

The Fedora Project is pleased to announce the immediate availability of
Fedora 25, the next big step our journey into the containerized, modular
future!

Fedora is a global community that works together to lead the advancement
of free and open source software.

today I learned: {{FedoraVersionNumber}} macro in wiki

Ooh! This is handy:

<a href="https://fedoraproject.org/wiki/Template:FedoraVersionNumber/doc" title="https://fedoraproject.org/wiki/Template:FedoraVersionNumber/doc">https://fedoraproject.org/wiki/Template:FedoraVersionNumber/doc</a>

The current version of [[Fedora]] is
'''{{FedoraVersionNumber|current}}'''.

The next version of [[Fedora]] is '''{{FedoraVersionNumber|next}}'''.

where is /1 coming from?

Someone on Reddit noted that there's a zero-length file named `1` in /
on their F25 system. I just looked on mine, and I have one too. It's
not owned by any RPM. And I checked on an F24 box, and it's got that
too. Anyone know where this is coming from?

PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

I've talked about this before, but maybe the F26 cycle is time to make
it happen. Right now, we have only one way of saying "this bug is
important to the project as a whole; could we please get resources
focused on it?" — and that way is to stop the whole vehicle until
someone does something about it. This has always been kind of
problematic, even though it has served well enough so far...

orphaning ec2-metadata, system-autodeath, s3cmd

ec2-metadata
system-autodeath
s3cmd

Thanks everyone!

Fedora 24 is a wonderful release. Thanks to everyone for all of your
hard work!

best approach for cleaning package metadata cache for old versions on upgrade?

There is a thread on the users' list * dealing with the issue that
after an upgrade, there's no non-obscure way to clean cached metadata
(or packages, even) from previous releases. The thread discussses DNF
and Yum, but it may apply to PackageKit/Software as well; I'm not sure
offhand.

It seems like we should handle this in some way on upgrade. My first
thought was to make it an RFE dnf-plugin-system-upgrade. But, is that
the right place? Maybe some time-base system should prune metadata
associated with repositories for any earlier $releasever?

Modularity Working Group: Call for Self-Nominations

Two and a half years ago¹ (woah, time goes fast!), we formed the
initial Fedora.next Working Groups — three for the Cloud, Workstation,
and Server editions, and two more for exploring the "Fedora Rings"
concept, Base and Environments & Stacks.

On Monday, the Fedora Council unanimously approved an update to this
structure as part of the next phase of the Modularity Objective².

Containers: we're asking for ponies, so here's a suggestion for the Minimum Viable (Modular) Pony Show

At DevConf.cz, I said that 2016 needed to be the year of the _show_
part of "show & tell" for what we started with the "rings" proposal and
now what we're calling, vaguely, "modularity".

Some of that is scary, because anything really new always is. It's
important that we do this in a way that *both* brings useful new
functionality _and_ doesn't break what we have.

In the commercial world, there's a concept of "minimum viable product" --
not done, not perfect, but what it takes to actually start solving problems
and providing value.

Fedora directions and priorities in 2016 (council-discuss thread)

Hey all! I posted this over on the Fedora Council Discus list, but it's
really relevant across the project. Rather than splitting into a bunch
of crazy cross-posts, I'd love to hear your input at
<a href="https://lists.fedoraproject.org/archives/list/council- ... at lists dot fedoraproject.org/message/B6XWQTXIAXXGXIPPVNFZXO3JLBUJXQJM/" title="https://lists.fedoraproject.org/archives/list/council- ... at lists dot fedoraproject.org/message/B6XWQTXIAXXGXIPPVNFZXO3JLBUJXQJM/">https://lists.fedoraproject.org/archives/list/council- ... at lists dot fedo...</a>

intent to retire Scratch

Several years ago, I packaged up Scratch 1.4 -- the visual programming
language for kids. However, it never really worked perfectly (it's not
64 bit clean) and upstream for this line is dead (as Scratch 2.0 is
based on Adobe Air -- and hopefully _soon_ HTML5).

I'd like to let go of ownership of the package, and unless someone else
really wants to invest time into it, I think retiring it completely is
the way to go.

Bodhi2 migration: 2015-08-19 16:00 UTC

This message went to the devel list, but I think it kind of buries the
lede: After this outage is complete, the long-mythical but never
forgotten Bodhi 2 will be realized! (If you're just tuning in, Bodhi is
the system we use to push out updates, including the "karma" system for
update testing.)

Check out <a href="https://fedoraproject.org/wiki/Bodhi/2.0" title="https://fedoraproject.org/wiki/Bodhi/2.0">https://fedoraproject.org/wiki/Bodhi/2.0</a> for some of the
capabilities we can expect from this new system.

Hopefully, this rollout will be trouble-free, although as I understand
it, Top People are Standing By for Response in the Event of Trouble.

DNSSEC/unbound -> boingboing.net failures

With the DNSSEC feature enabled as per the testing instructions, I'm
sometimes (but not always) getting failures for popular geek blog Boing
Boing, when public DNS still works:

$ host boingboing.net
Host boingboing.net not found: 2(SERVFAIL)

$ host boingboing.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

boingboing.net is an alias for boingboing.net.global.prod.fastly.net.
boingboing.net.global.prod.fastly.net is an alias for
global-ssl.fastly.net.
global-ssl.fastly.net is an alias for fallback.global-ssl.fastly.net.
fallback.global-ssl

how do I diagnose dnssec/unbound issues?

Okay, so... I enabled unbound and the dnssec-trigger package as
outlined on the change page. It seems to mostly work, but, today:

$ host <a href="http://www.boingboing.net" title="www.boingboing.net">www.boingboing.net</a>
Host <a href="http://www.boingboing.net" title="www.boingboing.net">www.boingboing.net</a> not found: 2(SERVFAIL)

$ host <a href="http://www.boingboing.net" title="www.boingboing.net">www.boingboing.net</a> 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

<a href="http://www.boingboing.net" title="www.boingboing.net">www.boingboing.net</a> has address 204.11.50.136
$ cat /etc/resolv.conf
# Generated by dnssec-trigger-script
nameserver 127.0.0.1

How do I go about diagnosing this?