Hi everyone! Since it's a new year and a new decade [*], it seems like a
good time to look forward and talk about what we want the Fedora Project to
be in the next five and even ten years. How do we take the awesome
foundation we have now and build and grow and make something that continues
to thrive and be useful, valuable, and fun?
[My thoughts below. Feel free to respond to those, or cut here and start
I see three big themes I think we need to tackle.
First, I'd like to see Fedora become more of an "operating system factory".
The direction we took with the Fedora Editions has been a success — Fedora's
general growth and popularity bears that out. But now it's a good time to
re-examine the positioning. The Editions were meant to fit big, broad
use-cases defined by (at the time) the Fedora Board and FESCo. Since then,
everything's become more complicated, with Atomic and then CoreOS, and IoT,
and Silverblue — and we never really found a satisfying way to present the
work of our other desktop SIGs.
So, I think we should revisit the top-level design for Get Fedora. I'm not a
designer and I don't have a particular answer in mind, but I think we should
try an approach which showcases all of our different outputs in some way
which also makes it easy for new users to find the right solution quickly
(and to understand the support options and expecations for their choice).
In support of that, I'd like to also have that page steer people into
tooling for creating new spins —- and I'd like to see us invest in and
rebuild the spin creation processes. (Particularly, I'd like spin releases
to be decoupled from the main OS release, and for those to be self-service
by their SIGs with minimal rel-eng involvement needed.)
Second, we need to figure out how to work with language-native packaging
formats and more directly with code that's distributed in git repos rather
than as tarball releases.
We're not adding meaningful end-user value by manually repackaging these in
our own format. We _do_ add value by vetting licenses and insuring
availability and consistency, but I think we can find better ways to do
that. I think the "source git" project is an interesting step here.
These two things are linked. I want application developers to find Fedora a
convenient and easy way to get their software to users. Pulling from the
Fedora container and flatpak registries should give the same feeling of
trust and safety that installing and RPM from our repos does today. We're
not going to get either of those things with the system we have now. Our
value is unclear to both developers and end users, so we just get left out.
If we don't address this, we're ultimately going to be reduced to a
barely-differentiated implementation of a base OS that no one really cares
about, not the rich software ecosystem we've always aspired to build.
Third, we really need to continue to grow the project as more than coding
Obviously that engineering work is the core of the project
(and we should grow that too!), but it doesn't matter what we build if no
one can find it or find how to use it. We need to feed and grow our
documentation and support communities around the world. Marie (our new
FCAIC, in case you missed that!) and I have been talking about this, and we
hope to really expand the $150-mini-event Mindshare program in the next
year, and hopefully build on that further in the coming ones.
Those are my thoughts. What other challenges and opportunities do you see,
and what would you like us to focus on?
(Also, on a more personal note: I've been SUPER swamped with email. If you
sent me something over the holiday break and I didn't answer, it's not you,
it's me. If I dropped something important, please send again. I'm declaring
email bankrupcy and starting the year fresh.)
Fedora Project Leader
I noticed there is a Fedora minimization project which seems could be
a bit related to the thing I'm trying to do, and this could be a
What I'm trying to do is reduce the initramfs size used for kdump.
Kdump loads a crash kernel and kdump initramfs image in a prereseved
memory region, which get booted when current kernel crashed and
perform crash dump. The prereserved memory is limited, so initramfs
shouldn't go too big.
Kdump in Fedora use Dracut to create bootable initramfs, just hook the
final step to do kdump things instead of switch root. And to reduce
the size only the binaries and drivers required to boot and perform
kdump on current machine is installed. So long it have been working
But problem is Dracut works by reusing binaries and libraries from the
currently running system, and many userspace binaries and libraries is
keep growing and using more space. So the initramfs is also growing.
Some component, like Systemd, have grown by a lot, here is a list of
the size of part of binaries along with the binaries they required in
There are overlays between the libraries they used so when installed
into the initramfs, the total size didn't go too big yet. But we can
see the size of systemd binary and libraries it used is much bigger
And as a compare, from version 219 to 243, systemd's library
dependency increased a lot:
(v219 is 5M in total, v243 is 20M in total)
[root@localhost ~]# systemctl --version
systemd 243 (v243.4-1.fc31)
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified
[root@localhost ~]# ldd /usr/bin/systemctl
libc.so.6 => /lib64/libc.so.6 (0x00007fe2bbd63000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe2bba73000)
librt.so.1 => /lib64/librt.so.1 (0x00007fe2bba68000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007fe2bba61000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007fe2bba56000)
libcryptsetup.so.12 => /lib64/libcryptsetup.so.12 (0x00007fe2bb9e3000)
libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fe2bb8c5000)
libip4tc.so.2 => /lib64/libip4tc.so.2 (0x00007fe2bb8bb000)
libkmod.so.2 => /lib64/libkmod.so.2 (0x00007fe2bb8a1000)
libmount.so.1 => /lib64/libmount.so.1 (0x00007fe2bb83e000)
libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007fe2bb7f1000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fe2bb7c2000)
libidn2.so.0 => /lib64/libidn2.so.0 (0x00007fe2bb7a0000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fe2bb777000)
liblz4.so.1 => /lib64/liblz4.so.1 (0x00007fe2bb756000)
libblkid.so.1 => /lib64/libblkid.so.1 (0x00007fe2bb6ff000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe2bb6dd000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007fe2bb6d3000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fe2bb6c9000)
libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00007fe2bb66c000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe2bb5d6000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fe2bb2f6000)
libargon2.so.1 => /lib64/libargon2.so.1 (0x00007fe2bb2ec000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe2bb2e3000)
libjson-c.so.4 => /lib64/libjson-c.so.4 (0x00007fe2bb2d1000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007fe2bb2ae000)
libpcap.so.1 => /lib64/libpcap.so.1 (0x00007fe2bb262000)
libz.so.1 => /lib64/libz.so.1 (0x00007fe2bb248000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fe2bb1ba000)
libunistring.so.2 => /lib64/libunistring.so.2 (0x00007fe2bb034000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007fe2bb006000)
libm.so.6 => /lib64/libm.so.6 (0x00007fe2baec0000)
[root@localhost test]# systemctl --version
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS
[root@localhost test]# ldd /bin/systemctl
linux-vdso.so.1 => (0x00007fffc407f000)
librt.so.1 => /lib64/librt.so.1 (0x00007f70255bd000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f7025396000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f7025170000)
liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f7024f5b000)
libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00007f7024cda000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f7024ad5000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70248bf000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f70246a3000)
libc.so.6 => /lib64/libc.so.6 (0x00007f70242d5000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f7024073000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f7023e6f000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f7023c6a000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f7023a65000)
Kdump in Fedora relies heavily on Dracut, and Dracut relies on
systemd. But kdump only expect systemd to start some services. I think
there might be many features not needed by kdump being brought in.
Is there any way to have a smaller systemd binary that is just enough
to boot the initramfs into the stage before switch-root?
when doing `fedpkg scratch-build --target epel8-candidate --srpm sox-188.8.131.52-29.el8.src.rpm`, I get:
[====================================] 100% 00:00:01 1.02 MiB 773.06 KiB/sec
Building sox-184.108.40.206-29.el8.src.rpm for epel8-candidate
Created task: 41245726
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=41245726
Watching tasks (this may be safely interrupted)...
41245726 build (epel8-candidate, sox-220.127.116.11-29.el8.src.rpm): free
41245726 build (epel8-candidate, sox-18.104.22.168-29.el8.src.rpm): free -> FAILED: BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information
0 free 0 open 0 done 1 failed
41245727 rebuildSRPM (noarch): FAILED: BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information
41245726 build (epel8-candidate, sox-22.214.171.124-29.el8.src.rpm) failed
When I investigating the logs (both `root.log` and `mock_output.log`), I found that `dnf` has problem with package downloading:
Error: Error downloading packages:
Status code: 404 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_... (IP: 10.5.126.23)
I get the same result also with `--target epel8`.
Any ideas how to resolve this issue?
Since I've moved my last dependent package off of this old stack, I've
retired gstreamer & gstreamer-plugins-base in rawhide (again).
Before reviving these poor and tired packages, please consider the
* Upstream is not maintaining this code branch anymore.
* There are significant improvements in the gstreamer0.10 branch (which is
separately packaged and maintained in Fedora)
This seems to repeat every 6 months: rawhide mock is broken on stable
Fedora, people are scrambling to install the right gpg keys, dnf reports
Looking at https://bodhi.fedoraproject.org/updates/?packages=fedora-repos,
there is still no F30 package with the right keys.
Can we *please* send out the FN+1 and FN+2 keys a month before branching,
to *all* releases of Fedora, so we can avoid this pointless scramble?
Hello, Fedora has an approved security policy since September 2018 :
> If a CRITICAL or IMPORTANT security issue is currently open
> against a package, or a security issue of lower severity has been
> open for at least 6 months, four weeks before the branch point a
> procedure similar to long-standing FTBFS will be triggered
> immediately, with 8 weeks of weekly notifications to maintainers and
> subsequent orphaning and then subsequent removal from distribution.
> This applies to all packages, not just leaf.
I have decided to have a look into this, since this has been approved more than
a year ago and nothing ever happened since. Fedora has a very big pile of open
CVE bugzillas .
There are several things I'd like us to consider based on the experience from
the FTBFS policy adjustments  before I go implement stuff:
A. It's easier to **orphan** packages soon, retire later -- this allows the
dependent package owners to notice the breakage and possibly adopt the packages
themselves if needed while gives very little room for "cheating".
B. Getting this done on a certain point in the release schedule is complicated
and requires a lot of planning and focus -- if we miss the window, nothing can
change until the next release. We have missed the window 3 times already.
C. Also because of the fixed date, the CRITICAL or IMPORTANT security issues
have no response time, if you get a new one at a certain point, the package is
immediately treated as problematic, while getting it 1 day later, there is a 6
month period where no action is required.
I'd like to adjust the policy before I go implement some tooling around this.
This is vague proposal of what I think would work easier for both "the
executioner" and the affected maintainers:
1. We automatically send reminders to NEW security bugzillas (as with FTBFS)
2. BZs that remain in NEW state for X reminders: pkg is orphaned
3. BZs that remain not CLOSED for Y months: pkg is retired (with notifications)
Point 2 makes it so that only a couple remaining packages actually need to
survive unfixed to point 3. Hence, point 3 can happen at a certain point in the
schedule with less severe impact of points B and C -- and if we miss the window,
we still have point 1 happening.
The bugzilla reminders are sent every third calendar week (every week is too
Here is an initial (albeit randomly generated) proposal of X and Y:
severity CRITICAL/HIGH MEDIUM LOW
X 2 4 6
Y 2 4 6
Note that X=1 effectively means anything from 1 second to 3 weeks, X=2 means
anything from 3 weeks (+1 second) to 6 weeks. Hence, we cannot orphan packages
after just 1 reminder.
I've made it so that X always equals to Y and every lower level is +2, to make
it easier to document, understand and remember, however this is not required.
For this example a critical/high CVE would get a reminder every third calendar
week. After two reminders (that is after 3-6 weeks), if still in NEW state,
package is orphaned. The maintainer (and others) still have extra 6 weeks to
If the bug is ASSIGNED, MODIFIED, etc., the package may be retired after 2
months, but that only happens regularly at a certain point in the schedule.
Similarly, a package with a medium CVE NEW bugzilla would be orphaned after 4
reminders (after 9-12 weeks), retired at a point if still not CLOSED after 4 months.
With low severity, that is 6 reminders (after 15-18 weeks), retired at a point
if still not CLOSED after 6 months (similarly to the current policy).
Please share your feedback, before I proceed with this to FESCo.
If somebody would be interested in maintaining this procedure, I'd be happy to
hand over that responsibility to anybody who is willing to help.
The idea is to start with semi-automation and have something -- currently we had
hoped for fully automated and we have nothing.
With more responsibilities (FPC, Stewardship SIG, FESCo) and the
ever-growing number of packages I maintain, I don't have as much time
for the things I originally started my contributions to fedora with -
the Pantheon desktop and the accompanying elementary applications.
What makes things worse is that I am not particularly proficient with
Vala or C/GObject, other than including upstream patches or doing
simple backports. That means some issues are punted until upstream
projects get around to fixing them (and if these issues are only
affecting "third-party" distros like fedora, that can take a while).
Also, the fact that GNOME frequently (almost with every new major
stable release, which means with almost every fedora release) breaks
something - either subtly or not - does not help.
gnome-settings-daemon changes its DBus interfaces almost every
release. mutter makes sweeping API changes almost every release. Both
gala and the elementary LightDM greeter can't keep up with upstream
mutter, and are basically still stuck on mutter 3.28 support (which is
why there is a mutter328 compat package) ...
Overall, this results in the quality of all these packages not being
as high as I would like it to be (though it's still pretty good, all
things considered). In particular, there are some components that are
more "crashy" than the rest, and I don't have the time and skill to
get deep into debugging the issue in most cases:
- wingpanel (the panel for Pantheon); issues in individual indicators
also crash the whole app because they are just dlopen()ed
- switchboard (the settings application); issues in individual
settings panels also crash the whole app because they are just
- gala (the window manager): obviously bad if the WM crashes, though
not as bad because it's still an Xorg session
- plank (the dock); also optionally used on XFCE (I think)
- sequeler (third-party SQL client developed for Pantheon)
I would greatly appreciate if somebody who knows their GObject-fu
could help me out here.
The elementaryOS upstream developers are usually helpful and accept
patches - even for things that are not a problem on elementaryOS, so
long as they can be switched on/off with e.g. conditional compilation.
But reported issues - that only affect fedora - without attached
patches / PRs are obviously low priority for them, and often sit
untouched for months or years.
In general, I manage to keep the packages for Pantheon / elementary
projects up-to-date. Having set up "nightly" builds on COPR a few
years ago really helps to catch potential issues early.
If anybody is interested, here are some pointers:
- all packages are tracked in koschei, in the decathorpe/elementary group:
- nightly builds are done on COPR:
Good Morning Everyone,
We are pleased to announce that the work to gate rawhide packages has leveled
Back in July we announced the first phase where bodhi got the support to gate
single-build updates. We can now officially announce that bodhi can gate
multi-builds updates. This is achieved through the use of side-tags, which can
be created on demand via ``fedpkg request-side-tag``. The package can then be
built using ``fedpkg build --target=<your side-tag>`` or via ``fepdkg
chain-build --target=<your side-tag>``. Once all your packages are built, you
can create a bodhi update from this side-tag using either the ``Use Side-Tag``
drop-down or in the CLI by using the ``--from-tag`` argument to the ``bodhi
updates new`` command.
Every build in the update will then be tested by the CI system which will report
the outcome. Bodhi will then query greenwave which will rely on the collection
of these individual results to make a decision about whether to gate the update
More detailed documentation is available at:
Note: this is not the end of rawhide-gating. We still have some changes planned
to make it easier for greenwave to make a decision about an update containing
multiple builds, we want to improve the documentation for on-boarding new CI
systems and make them matter for rawhide as well as for stable releases.
We then have all the work ahead to improving our tests, including enabling some
of them distribution-wide, looking at the reverse dependencies or testing for
the impact of an update on our composes.
Looking forward for your feedback!
For the rawhide gating team
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com...
Too many people (like also me) try to use samba-dc on fedora for deploy
a production AD DC controller, without know that MIT kerberos is
experimental and some useful things cannot work (es. win to win
An recent last example:
> On 01/11/2019 22:23, Vex Mage wrote:
> > The script is expecting dpkg however this is a Red Hat
> > derived distro (Fedora Server.)
> Where did you get the Samba packages from ?
> If they are the default OS packages, then you should stop using
> them, they use MIT kerberos and are experimental.
There is many approach for resolve this issue:
a) Stop use MIT kerberos and rebuild samba with Heimdal Kerberos.
b) Produce a samba alternative package version (like, for example,
firefox-x11) build it with Heimdal Kerberos (es samba-hk-*)
c) Stop enable DC on Fedora, like RH/Centos do.
d) Notify users at the end of the installation that Fedora Samba DC is
e) Solve the problems that make MIT kerberos experimental and put us in
a position to ask for help on the samba team.
f) ... some other proposal ?
What is the best approach chosen by Fedora ?
(inviato dal mio Linux Fedora 31 Workstation)