TL;DR: It seems like armv7hl koji builders are locking up, most often
when running dnf to install the buildroot or to install dependencies.
I've seen many people getting hit by this issue:
So, if your build takes unusually long time on armv7hl, look at the
task's logs in koji, and if they're stuck at an early stage of the
build, you will need to cancel the task and resubmit it (or ask releng
to run "koji free-task NNNNNNN" for the stuck armv7hl task).
During the FESCo panel during Nest one of the conclusions was that FESCo should
take a more proactive role in pushing changes in Fedora. We talked about enabling
koschei by default and other similar things. Here's my attempt to start with
something I hope will be somewhat easier:
** Let's make %autorelease + %autochangelog the default approach in Fedora packaging **
I think we should follow the Change process for this, to raise visibility and
reach all interested parties. I'll file such a Change later [*], based on the
initial feedback here. Jump to the end to see the proposed Scope.
** Why? **
The original motivation for %autorelease + %autochangelog was to save some
typing for packagers. In Fedora all packaging work happens in dist-git, so every
change would need to be described twice: once in the %changelog entry and
a second time in the git commit message.
A second motivation is to ease cherry-picking commits between branches. The
Release field and the %changelog sections would often be the only source of a
trivial conflict when merging branches or when backporting a commit from rawhide
to a release branch.
A third motivation to improve the workflow for pull requests. (This is a variant
of the previous item, but worth mentioning on its own.) If a pull request is not
merged right away, the Release value used may in the meantime be taken by a
different update, and the %changelog text may conflict.
A fourth motivation that has become more relevant is rust2rpm and other
automatic packaging workflows. As described e.g. in Fabio's Rust Packaging
Tutorial , one may want to regenerate the spec file for new rust2rpm version
or when the package is updated. With the traditional %changelog section, old
entries need to be copied over, but with %autochangelog we get continuity
without any additional work.
** Why now? **
rpmautospec has been slowly improving over time. With the 0.2.6 release, it
is ready for general use with all packages.
** What exactly is being proposed? **
rpmautospec , i.e. 'Release:%autorelease' and '%changelog\n%autochangelog'
becomes the recommended workflow for new packages.
All documentation is updated to describe this workflow.
Converting existing packages is recommended.
The legacy workflow is still supported and there is no plan to disallow or
No mass-conversion of existing packages is planned.
(I think it'd be reasonable to do this at some point in the future, but this is
explicitly out-of-scope for now.)
** Scope **
1. implement changelog skipping [3, 4]
2. any other rpmautospec issues?
(I don't see other big issues, but if people consider something important,
we could treat them as blockers.)
2. release and deploy new rpmautospec version
3. adjust packaging guidelines 
4. adjust tutorials [6, any other?]
6. adjust fedora-review (, but that's the wrong place)
7. adjust rust2rpm default [DONE in v19, 8]
8. other packaging tools?
(do we use an automatic converter for pypi?)
9. adjust rpmdevtools templates
9b. adjust emacs-mode
10. make it easier for packagers to know what changelog version is *deployed* in koji 
So… I think we should do this. Please say that you agree ;)
Is something missing from the scope?
[*] The Change process doesn't fit very well because this will not be tied to
any release of Fedora, but it's good enough. Similarly as for the change to
SPDX that's happening now.
I posted the following recently to the Fedora legal list, but it was pointed out by Fabio Valentini that the legal list is sort of obscure so I'm reposting it here in the hope that it may reach more interested people:
CC0 has been listed by Fedora as a 'good' license for code and content
(corresponding to allowed and allowed-content under the new system).
We plan to classify CC0 as allowed-content only, so that CC0 would no
longer be allowed for code. This is a fairly unusual change and may
have an impact on a nontrivial number of Fedora packages (that is not
clear to me right now), and we may grant a carveout for existing
packages that include CC0-covered code. While we are moving towards a
process in which license approvals are going to be done primarily
through the Fedora license data repository on gitlab.com, I wanted to
note this on the mailing list because of the significance of the
The reason for the change: Over a long period of time a consensus has
been building in FOSS that licenses that preclude any form of patent
licensing or patent forbearance cannot be considered FOSS. CC0 has a
clause that says: "No trademark or patent rights held by Affirmer are
waived, abandoned, surrendered, licensed or otherwise affected by this
document." (The trademark side of that clause is nonproblematic from a
FOSS licensing norms standpoint.) The regular Creative Commons
licenses have similar clauses.
A few months ago we approved ODbL as a content license; this license
contained its own "no patent license" clause. Up till this time, the
official informal policy of Fedora has been that 'content' licenses
must meet the standards for 'code' licenses except that they can
prohibit modification. The new Fedora legal documentation on the
license approval categories will note that allowed-content licenses
can also have a no-patent-license clause. In a FOSS development and
distribution context, the absence of patent licensing for non-software
material is of significantly less concern than the software case.