Red Hat & Fedora -- largely stepping out of this ecosystem
by Jeff Law
I have no illusions that this message is going to change anything at Red
Hat. But I feel I need to get this off my chest. I'm speaking strictly
for myself, not for my current or any former employer, not for the GCC
project and not for any other group/organization I might have some
affiliation with.
--
First a bit of background. I came to Red Hat via the Cygnus
acquisition. My combined service spanned nearly 30 years. During that
time I had the opportunity to be involved in the formation of Fedora,
strategic planning for RHEL while at the same time being able to spend
much of my time on optimizing compilers.
I left Red Hat in 2021 to refocus on what I really enjoy in a small
company where I can make a clear difference in the company's direction
and success. It was, by far, the most difficult decision in my
professional career. I left many friends and colleagues behind.
The point being I had a fantastic career at Cygnus/Red Hat. I got to do
and learn things I never could have imagined. I got to work with many
amazing people spanning many organizations within the company
(engineering, sales, marketing, legal, product management, executives,
etc). By no means do I consider myself a disgruntled former employee.
--
What Red Hat has done recently is depressing, but not a huge surprise to
me. Red Hat struggled repeatedly with how to deal with "the clones".
The core idea I always came back to in those discussions was that the
value isn't in the bits, but in the stability, services and ecosystem
Red Hat enables around the bits. Arguments for protecting the bits were
met with something like "if that's what we need to do to be successful,
then we're failing to provide real value".
At some point in the last 20 years (I forget exactly when) Red Hat was
looking to codify its values. Naturally the topic of open source came
up during those discussions. When open source didn't make the cut, one
could say the writing was on the wall -- open source was a means to an
end. In my mind that opened the door for numerous changes we've seen in
subsequent years.
One could see signs of where this was going with the adjustments that
were made to the exposed RHEL kernel sources some time ago. Then the
dissolution of CentOS a couple years back and most recently with the
lockdown of the RHEL sources.
What Red Hat has done may be technically legal and perhaps good for its
business. However, to me it's ethically unconscionable. Those who
know me know I'm not an zealot, but I do have a baseline set of ethical
values and Red Hat crossed that line.
--
Back in 2002 or 2003 when we were trying to figure out how to salvage
the ill-fated "Red Hat Community Linux Project" resulting in what we now
know as Fedora, one of the key concepts that we pushed to the
executive team at Red Hat was that it was strategically important for
both Fedora and Red Hat to have a strong association with each other. I
think we largely succeeded in building that close association.
I've been a Fedora user since before FC1. I run Fedora on my laptop.
When I need a docker image for something, I start with a Fedora image.
When I need to spin up a server (say to run the GCC CI/CD system) I load
it with Fedora. It's an ecosystem I'm technically comfortable in and
easiest for me to utilize.
That will change across the board this summer. That's a bit hard for me
to swallow, but I can't get past that association we built between Red
Hat and Fedora and Red Hat's recent actions.
I'll still have to deal with the RHEL/CentOS/Fedora ecosystem on a
professional level. Obviously, I'll do what I need to do to help make
my employer successful -- but when a choice exists, Fedora/CentOS/RHEL
won't be where I land going forward.
I wish it hadn't come to this, but I also can't say I'm terribly surprised.
Thanks for your time,
Jeff
10 months
Proposal: drop delta rpms (for real this time)
by Matthew Miller
I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
priority. Last time we talked about this we didn't really get anywhere...
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
... and that ticket hasn't moved, because fixing it isn't trivial.
What we're doing now — as has been the case for several years, already noted
in the previous discussion — has very little end-user value. Also as noted
in that thread (as in the ticket)... that's unfortunate, because it did
bring some real benefits (and could possibly do even more.)
But, I think it's time to move on. We have ostree and various
container-delta approaches. We should focus on those — and give DeltaRPMs a
sad, fond farewell.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10 months
How to deal with sysusers files inside the package
by Ewoud Kohl van Wijngaarden
I'm looking at converting my package (where I'm also the upstream) to
use sysusers.d but I'd prefer shipping the sysusers.d file inside the
source tarball rather than in packaging. This allows me to use the same
definition on Debian, which I think is a huge benefit of systemd
standardizing these kinds of things.
The documentation[1] only mentions shipping it as a separate source, not
inside the tarball. Should I simply replace %{SOURCE3} in the docs with
the path from the extracted tarball? If so, is this something that the
packaging-guidelines should document?
I also noticed that %sysusers_create_compat isn't in EL8 and I'd rather
not depend on epel-rpm-macros. Today we build completely outside of EPEL
and I'd prefer to keep it that way. Is the recommended way to use
%sysusers_create_package (provided by systemd-rpm-macros) instead?
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
10 months
PWG+OpenPrinting meetup 2023
by Zdenek Dohnal
Hi all,
I've joined annual PWG+OpenPrinting virtual meetup where the news and
statuses from the current printing development are discussed.
The main points are:
- cups-filters 2.0 betas and release candidates are released and present
in Fedora 38
- since new cups-filters are in Fedora 38, nothing stands in the way of
packaging pappl-retrofit and printer applications based on it into
Fedora as RPMs - any volunteers are welcome!
- CUPS 2.4.x, CUPS 2.5 and CUPS 3.0 are delayed:
- 2.4.x - there are several regressions I haven't able to tackle
yet, but I hope there is a new version in a month
- 2.5 - OAuth support took lot of time to implement
- 3.0 - libcups (its version 3.0) has a beta which developers which
uses libcups 2.0 can compile and link their applications and see what
changed between major release
- GTK (its version 4) has merged support for Common Print Dialog
Backends - universal print dialog, which can work not only with cups,
but with other possible backends (like google cloud print)
- WIP on Printer Setup Tool for GNOME Control Center - full support for
driverless printers and printers via printer applications
The full report is attached.
Zdenek
--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
10 months
Re: cups-2.4.2-11.fc39.src.rpm depends on autoconf-2.71 or newer,
not mentioned in .spec file, fails build
by Jan Pazdziora
On Sun, Mar 26, 2023 at 02:44:34PM +0300, ijaaskelainen(a)outlook.com wrote:
> Kind regards, The Improvement Skeleton.
Please show the exact steps you use to build the cups package and the
exact error message you get.
Technically you are correct because configure.ac has AC_PREREQ([2.71]).
But autoconf is pulled in by the automake which is listed as BuildRequires
in cups.spec file, and since Fedora rawhide only has
autoconf-2.71-5.fc38.noarch, there really is not an older autoconf around
to ruin your day.
--
Jan Pazdziora | Sr. Principal Software Engineer | Red Hat
10 months
Orphaning packages (was LibreOffice packages)
by Bastien Nocera
Hello,
As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team.
While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining.
Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore:
apfs-fuse
bluez
codespell
eosrei-emojione-fonts
geocode-glib
gnome-bluetooth
gnome-epub-thumbnailer
gnome-kra-ora-thumbnailer
gnome-user-share
gom
grilo
grilo-plugins
ifuse
iio-sensor-proxy
libfprint
libglib-testing
libimobiledevice
libpeas
libplist
libportal
libusbmuxd
low-memory-monitor
malcontent
power-profiles-daemon
sloccount
switcheroo-control
totem
totem-pl-parser
umockdev
usbmuxd
Regards
10 months
LibreOffice packages
by Matthias Clasen
Hey,
as you've probably seen, the LibreOffice RPMS have recently been orphaned, and I thought it would be good to explain the reasons
behind this.
The Red Hat Display Systems team (the team behind most of Red Hat’s desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.
The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.
We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.
Any community member is of course free to take over maintenance, both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Matthias
10 months, 1 week
F39 Change Proposal: No custom Qt theming for Fedora Workstation
(Self Contained)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/NoCustomQtThemingForWorkstation
This is a proposed Change for Fedora Linux.
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 ==
Fedora Workstation has been using
[https://github.com/FedoraQt/QGnomePlatform QGnomePlatform] and
[https://github.com/FedoraQt/adwaita-qt Adwaita-qt] projects to apply
GNOME-like configuration and styling to Qt applications to match the
environment. These projects are now in a state where they are outdated
and semi-occasionally broken for some applications and it would be
better to default to what Qt upstream has to offer.
== Owner ==
* Name: [[User:jgrulich| Jan Grulich]]
* Email: jgrulich(a)redhat.com
== Detailed Description ==
[https://github.com/FedoraQt/QGnomePlatform QGnomePlatform] project is
a Qt Platform Theme plugin. It reads GNOME configuration, like fonts
or icons and applies this configuration to Qt applications. It also
provides implementation of Client-Side Window Decorations or native
dialogs. This project partially overlaps with Qt's default GTK
Platform Theme plugin, but there are some additions that are existing
only in QGnomePlatform, like Client-Side Window Decorations.
[https://github.com/FedoraQt/adwaita-qt Adwaita-qt] project is a Qt
Style plugin. It implements widget styling (e.g. buttons, checkboxes)
to match GNOME's Adwaita style. There is no equivalent of such style
in Qt, but given the complexity of Qt Style plugins, this project is
now outdated and doesn't match the current Adwaita (GTK4) style. It is
also responsible for the most of the issues users are facing while
using our custom styling.
Some additional information about these projects and issues:
* [https://jgrulich.cz/2023/03/08/explained-qgnomeplatform-and-adwaita-qt/
Detailed explanation of QGnomePlatform and Adwaita-qt]
* [https://theevilskeleton.gitlab.io/2022/12/06/where-fedora-linux-could-imp...
Adwaita-qt issues on examples]
* [https://pagure.io/fedora-workstation/issue/351 Fedora Workstation
bug to reconsider use of Adwaita-qt]
With this change we would like to stop shipping and using these
projects by default on Fedora Workstation and default to Qt default
theming and styling. Also, because the GTK Platform Theme in Qt
doesn't support everything we have support for in QGnomePlatform, we
would like to contribute it to Qt instead. With this work, there
shouldn't be any drawbacks when using Qt's GTK Platform Theme and we
believe we would even get broader usage and more contributors for
things like Client-Side Window Decorations. For Adwaita-qt
replacement, we would default to
[https://doc.qt.io/qt-6/qtquickcontrols-fusion.html Fusion] style or
possibly to Breeze style for KDE apps. Both styles have benefit of
active upstream and broader usage than our custom style that is only
used by Fedora Workstation and not tested by developers.
== Feedback ==
== Benefit to Fedora ==
We will be using more reliable and tested Qt theming/styling instead
of our custom solution, which is only used by Fedora Workstation. This
brings us closer to upstream with benefit of upstream support for
theming and styling issues. This will also eliminate all the issues
our users have been experiencing in the past when using Qt
applications with Adwaita-qt style on Fedora Workstation.
== Scope ==
* Proposal owners:
# Drop QGnomePlatform and Adwaita-qt from Fedora Workstation compose.
# Drop our custom patches making Qt to use QGnomePlatform by default.
# Upstream some of the QGnomePlatform features to Qt upstream and
backport them to Fedora packages (until released upstream).
* Other developers: [OPTIONAL] Packagers blacklisting either
QGnomePlatform or Adwaita-qt in their packages can stop doing that.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
We will make QGnomePlatform to not be used by default even when
installed. Users will still be able to use it by using a Qt env
variable or passing an option specifying what platform theme should be
used. For this reason there shouldn't be any extra work needed to be
done by the users who upgraded to Fedora 39.
== User Experience ==
The user experience should remain the same or be actually better in
case Qt apps they were using were not working properly with
QGnomePlatform or Adwaita-qt.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
10 months, 1 week
Intent to retire OpenCOLLADA
by Richard Shaw
For anyone who didn't see discussion on the list OpenCOLLADA upstream
hasn't seen a commit since 2018 and no one has stepped up to port it to
pcre2.
I tried to convert it to use the bundled pcre as a stop gap to keep it
going a bit further but it installs the library instead of building
statically.
Anyone good with CMake could fix this but at this point I think it's just
time to retire it.
If anyone wants to take it over let me know otherwise I plan to retire
early next week.
Thanks,
Richard
10 months, 1 week