Self Introduction: Piotr Szubiakowski
by Piotr Szubiakowski
Hello Fedora Developers,
I want to introduce myself. I'm from Poland and currently live in
Munich. I have been a Fedora user since the first Fedora Core release.
I work for European Southern Observatory [1]. My team prepares the
development environment for Extremely Large Telescope [2] Control
Software. We decided to use Fedora as a base distribution. On top of
Fedora, we build additional packages. Most of them are Python and C/C++
libraries. As a team, we decided to contribute RPMs that are in good
enough shape to Fedora. We hope that users will benefit from additional
packages. We also think that joining the Fedora community and being
part of the development process will teach us how to become better
package maintainers.
Many thanks,
Piotr
[1] https://www.eso.org/public/
[2] https://en.wikipedia.org/wiki/Extremely_Large_Telescope
1 year, 10 months
Fedora CoreOS Meeting Minutes 2022-07-20
by Dusty Mabe
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-20/fedora_core...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-20/fedora_core...
Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-20/fedora_core...
========================================
#fedora-meeting-1: fedora_coreos_meeting
========================================
Meeting started by dustymabe at 16:30:08 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-20/fedora_core...
.
Meeting summary
---------------
* roll call (dustymabe, 16:30:14)
* Action items from last meeting (dustymabe, 16:34:50)
* No action items from last meeting \o/ (dustymabe, 16:35:00)
* Develop Fedora CoreOS layering user stories (dustymabe, 16:35:51)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1219
(dustymabe, 16:35:58)
* please review the use cases described in
https://github.com/coreos/fedora-coreos-tracker/issues/1219 and give
us feedback on improvements or corrections (dustymabe, 16:41:00)
* tracker: Fedora 37 changes considerations (dustymabe, 16:41:50)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1222
(dustymabe, 16:41:58)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/915
(dustymabe, 16:46:38)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/919
(dustymabe, 16:49:57)
* MACAddressPolicy for bridges/bonds etc.. (dustymabe, 16:56:09)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/919
(dustymabe, 16:56:14)
* open floor (dustymabe, 17:06:30)
* it's come to our attention that our docs around tpm2 pinned
encrypted rootfs weren't clear on the drawbacks. i've added more
details in https://github.com/coreos/fedora-coreos-docs/pull/434. if
you're using tpm2 pinning today, make sure you see the updated docs.
(jlebon, 17:10:40)
Meeting ended at 17:18:56 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* dustymabe (97)
* jlebon (28)
* jdoss (26)
* zodbot (18)
* travier (5)
* jbrooks (3)
* ravanelli (1)
* bgilbert (1)
* aaradhak (1)
* gursewak (1)
Generated by `MeetBot`_ 0.4
.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
1 year, 10 months
Non-responsive packagers: michaelanguskelly
by Pierre-Yves Chibon
Good Morning Everyone,
The packagers listed here have been receiving a daily email asking them to
either adjust their bugzilla or their FAS account so the email address in FAS
matches an existing bugzilla account.
Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Cr...
- benzea contacted since June 23rd 2022
benzea is maintainer of rpms/bolt
benzea is main admin of rpms/devtodo
benzea has a bugzilla override on rpms/devtodo
benzea is main admin of rpms/fprintd
benzea has a bugzilla override on rpms/fprintd
benzea is main admin of rpms/fwts
benzea has a bugzilla override on rpms/fwts
benzea is maintainer of rpms/gamemode
benzea is main admin of rpms/gnome-network-displays
benzea has a bugzilla override on rpms/gnome-network-displays
benzea is main admin of rpms/libfprint
benzea has a bugzilla override on rpms/libfprint
benzea is maintainer of rpms/libusb
benzea is maintainer of rpms/libusb-compat-0.1
benzea is maintainer of rpms/libusb1
benzea is main admin of rpms/libusbx
benzea has a bugzilla override on rpms/libusbx
benzea is main admin of rpms/thermald
benzea has a bugzilla override on rpms/thermald
benzea is maintainer of rpms/umockdev
benzea is maintainer of rpms/upower
benzea is main admin of rpms/uresourced
benzea has a bugzilla override on rpms/uresourced
Does anyone know how to contact them?
Thanks,
Pierre
1 year, 10 months
F37 proposal: Preset All Systemd Units on First Boot (Self-Contained
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Preset_All_Systemd_Units_on_First_...
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Systemd will execute the equivalent of '''systemctl preset-all''' when
an unconfigured system is booted
([https://www.freedesktop.org/software/systemd/man/machine-id.html#First%20...
"First Boot"] condition). This means that units will be enabled or
disabled according to the preset configuration. We currently do the
equivalent of '''systemctl preset-all --preset-mode=enable-only''',
and this will be extended to also disable units, i.e. '''systemctl
preset-all --preset-mode=full'''. Any units which are manually
symlinked but presets say they shouldn't (which is against the
packaging guidelines for packaged units) will be disabled.
Note that this applies to "first boot" only, i.e. to boot from an
image without ''/etc'' fully populated. In does not apply to systems
that were installed using Anaconda.
== Owner ==
* Name: [[User:jlebon| Jonathan Lebon]]
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl, jlebon at redhat.com
== Detailed Description ==
Our [https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_sy...
guidelines] say that units that are packaged in rpms must be enabled
through macros (''%systemd_post'') and the preset system. Almost all
packages conform to this, so effectively their enablement state
follows the preset config. When the system is installed, or more
precisely when ''systemd.rpm'' is installed, we do ''preset-all''. But
for historical reasons, when booting an unconfigured system ("first
boot") we only 'enable' units in this fashion. In Fedora and RHEL
CoreOS, some symlinks are created in the golden image, but should be
disabled in the local image after local preset configuration has been
inserted. To make this work, the call in systemd will be changed to
execute the equivalent of ''preset-all --preset-mode=full'', making
enablement during "first boot" more like enablement during an Anaconda
installation.
== Benefit to Fedora ==
* CoreOS can insert local preset configuration through Ignition and
this configuration will be applied on the first boot.
* Users can do something similar with local preset configuration on
distributed images.
* The system is made a bit simpler and easier to understand, because
we can say that "units are enabled/disabled after installation as
specified by the preset system".
* Users can call ''systemctl preset-all'' at any time to apply
preset-configuration. If no local changes to configuration have been
made, ''preset-all'' would make no changes to unit state. If units
have been enabled or disabled, ''preset-all'' would return unit
enablement to the pristine state after installation.
== Scope ==
* Proposal owners:
** implement patch for systemd to configure preset-all mode on first
boot (https://github.com/systemd/systemd/pull/15205)
** build systemd with this mode changed to ''--preset-mode=full''
** provide pull requests for two packages which have been identified
to not use the preset system for enablement to conform to the
packaging guidelines
(https://bugzilla.redhat.com/show_bug.cgi?id=2070862,
https://bugzilla.redhat.com/show_bug.cgi?id=2070726)
* Other developers: review and merge the pull requests
* Release engineering: N/A
* Policies and guidelines: none, this change is about following the
guidelines more closely
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
None.
== How To Test ==
* On a newly installed system, with arbitrary set of packages: call
''systemctl preset-all''. This should result in no changes.
* On a system which is booted from an unconfigured image (e.g. the new
Server VM image should qualify, see
[[Changes/Supplement-server-by-kvm-vm-image]]): before the first boot,
enable some units manually that are disabled in presets. After
booting, those units should be disabled again.
== User Experience ==
In general this change will be a noop for users, because it only
applies to "first boot", i.e. to the case when a system is booted from
a distributable image without local configuration and is configured
when initially booted. In case where Anaconda is used to install
images, /etc is populated before the first boot and the "first boot"
condition never applies, thus this change is irrelevant. On systems
installed from a "golden image" such as Fedora CoreOS, units will
follow the preset configuration more closely. Thanks to the fixes to
make packages conform to packaging guidelines, users can call
'''preset-all''' to return the system to defaults.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Systemd
maintainers: flip back the default in systemd, rebuild.
* Contingency deadline: N/A (not a System Wide Change) This can be
done at any time up to the release.
* Blocks release? No.
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 10 months
ANTLR packages and i686
by Jerry James
The various ANTLR packages will be impacted by
https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs. The parser
generators, which are written in Java, will no longer be available on
i686. If absolutely necessary, we could continue to package the
various language runtimes for i686. That would be a major pain in the
neck. WIth ANTLR 4 in particular, the version currently in Rawhide
(4.10.1) is not compatible with previous runtimes. Most of the
consumers we have in Rawhide ship parsers that were generated with
ANTLR 4.6 through 4.9 generators, so they are not compatible with the
4.10.1 runtimes. (We regenerate the parsers at build time.)
Continuing to support i686 would therefore mean packaging old versions
of the language runtimes, just for i686.
My preference is to stop building everything ANTLR-related on i686.
This has consequences for packages written in C, C++, Go, and OCaml,
at least. I'll omit Java packages other than the ANTLR packages from
the lists below, since they will disappear from i686 on their own.
Affected packages with maintainers:
- antlr3 (jjames, mizdebsk, dchen, mjakubicek, walters): we could
conceivably keep the C, C++, and JavaScript runtimes if absolutely
necessary
- antlr4-project (jjames, mhayden, @go-sig): we could conceivably keep
the C++, Go, JavaScript, Python3, and Swift runtimes, but see above
- azure-cli (mhayden, @python-sig): needs the Python3 runtime from the
antlr4-project package
- belle-sip (nucleo, sdgathman): needs the C runtime from the antlr3 package
- coq (amdunn, jjames): needs the Python3 runtime from the
antlr4-project package
- cvc4 (jjames, brouhaha): needs the C runtime from the antlr3 package
- flocq (jjames): depends on coq
- frama-c (jjames): depends on why3
- gappalib-coq (jjames): depends on flocq
- golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime
from the antlr4-project package
- golang-google-grpc (eclipseo, @go-sig): needs
golang-github-google-cel. Is consumed by a TON of other Go packages,
so many that I did not attempt to trace them.
- ocaml-menhir (jjames): we can remove the coq subpackage only on
i686; it isn't consumed by anything in Fedora
- why3 (jjames): depends on flocq
Packages by maintainer:
@go-sig: antlr4-project, golang-github-google-cel, golang-google-grpc,
numerous consumers of golang-google-grpc
@python-sig: azure-cli
amdunn: coq
brouhaha: cvc4
dchen: antlr3
eclipseo: golang-github-google-cel, golang-google-grpc
jjames: antlr3, antlr4-project, coq, cvc4, flocq, frama-c,
gappalib-coq, ocaml-menhir, why3
mhayden: antlr4-project, azure-cli
mizdebsk: antlr3
mjakubicek: antlr3
nucleo: belle-sip
sdgathman: belle-sip
walters: antlr3
I am going to be mostly offline starting Saturday, so I intend to deal
with this when I get back, approximately July 18. That is just before
the mass rebuild, of course. If anybody has a problem with dropping
i686 builds for the above packages, please come up with a plan to deal
with the situation by then.
--
Jerry James
http://www.jamezone.org/
1 year, 10 months
Comaintainer(s) wanted for qt5-qtwebengine
by Kevin Kofler
Hi,
QtWebEngine is used as the HTML component for many Qt applications,
including large parts of the KDE software universe. It is used by web
browsers such as Falkon, but also, e.g., by KMail/Kontact.
The version that is currently (still) used the most is the Qt 5 version.
There is also a Qt 6 version (has been there since 6.2), which is not
currently packaged in Fedora at all. That, too, needs someone to pick up the
work. But most of the relevant applications are still stuck on Qt 5 anyway,
so this message will focus on the Qt 5 version.
The qt5-qtwebengine package is currently maintained mainly by 2 people: Rex
Dieter (rdieter) and me (kkofler). I used to be the primary maintainer, but
had to resign from that a few years ago due to mainly lack of time. (There
were at the time also some packaging details that I was unhappy with, but
those have all since either been fixed or stopped being relevant. Lack of
time is the big issue that is left.) At that point, Rex Dieter had picked up
the package, but he clearly also lacks the time to really take care of it
(see the evidence below). The package is also open to commits from all @kde-
sig group members, but most of the work is done by the two admin-level
maintainers, i.e., Rex and me.
Qt releases a security update for 5.15.x every couple months. (There were
around 2 months between 5.15.9 and 5.15.10, around 3 between 5.15.8 and
5.15.9.) While Qt 5.15.x LTS is mostly commercial-only (with ancient 1-year-
old releases being released under the LGPL), this does not apply to
QtWebEngine, which is based on third-party LGPL code (mostly the WebKit and
KHTML code on which Chromium's Blink is based), and is hence available under
the LGPL from the public git repository. (There are, however, no official
tarballs until 1 year later, so we have a script to roll our own from git.
We need a custom tarball with patent-encumbered stuff ripped out by a script
anyway, so that just makes the tarball generation one more script to run
first.) Since each 5.15.x release includes a whole bunch of backported
security fixes, and not many other changes (should in principle be bugfix-
only), it is imperative to get these out to our users as quickly as
possible. Those security fixes are already delayed by weeks compared to
Chromium upstream, we should not add our own lag to that.
Now, when we look at how fast (or rather, how slow, sadly) Fedora has been
to roll out qt5-qtwebengine security fixes to users of stable releases, the
results are very disappointing, see:
https://bugzilla.redhat.com/show_bug.cgi?id=2043381
https://bugzilla.redhat.com/show_bug.cgi?id=2079655
The current situation is that 5.15.10 has been tagged in git for almost two
months. Yet, Rawhide is stuck at 5.15.9, and even that has so far not been
pushed to the currently supported stable releases (Fedora 35 and 36), almost
4 months after it was tagged.
So, since all current maintainers of qt5-qtwebengine, including me, are
failing badly at keeping the package up to date with security fixes, this is
an urgent plea for help. The current situation is not acceptable, any
helping hands to improve on it would be extremely welcome. I have admin
rights to the package, so I can add comaintainers that wish so.
Kevin Kofler
1 year, 10 months
