You are kindly invited to the meeting:
Silverblue on 2018-09-17 from 09:00:00 to 10:00:00 US/Eastern
The meeting will be about:
Fedora Silverblue IRC meeting in #fedora-meeting-2 on Freenode. Fedora Silverblue is an rpm-ostree-based Fedora desktop edition.
I ran a dnf update of Fedora 29 today and it killed cups-pdf printer. I traced the problem to an update of ghostscript. I downgraded ghostscript returning cups-pdf to life. ghostscript-9.24-1.fc28.x86_64 and/or its associated packages is the problem. ghostscript-9.23-1.fc28.x86_64 works fine. There 3 serious ghostscript bugs on Redhat Bugzilla (1628710, 1628875 and 1628943 reported on 9/14 and 9/13). Please go back to ghostscript-9.23-1.fc28.x86_64 until the bugs are cleared.
I'm Alberto from the Marketing team, I'm asking for help to complete
the Fedora 29 Talking points.
Talking points are key highlights of the new release. There are
different types of talking points for different types of people:
general desktop users/everyone, developers, and sysadmins. They are
meant to provide a short, effective answer to the question "What cool
stuff is in the latest release of Fedora?" They are compelling, not
Alberto Rodriguez Sanchez <bt0dotninja(a)fedoraproject.org>
I'd like to invite Fedora contributors to start creating Flatpaks of
graphical applications in Fedora. We're still working on putting the final
pieces into place to have a complete story from end to end, but it's
definitely close enough to get started.
If you maintain a graphical application, please try creating a Flatpak of
it. Your experience will vary - some applications are quite easy, but if
your application, for example:
* Uses qt5-qtwebengine
* Uses many KDE libraries
* Uses many Perl or Python packages
* Uses texlive
etc, then you may want to wait - we will eventually be creating shared
builds to make bundling these easier. Also, if your application has a
system service, installs a polkit policy, or otherwise is not
self-contained, then it's not a good candidate for a Flatpak.
Or you can pick one of 280+ applications that have been identfied as easy
and assist out the application package maintainer by creating a Flatpak of
An introduction, draft tutorial and other documentation can be found at:
(The plan is to integrate this into docs.fedoraproject.org. For now, the
is at: https://github.com/owtaylor/fedora-docs-flatpak)
For help, please ask on #fedora-workstation on Freenode, or mail
a few days back I noticed that my F29 laptop is hibernated every morning
even though I suspended it the previous evening. After some digging, it
seems that there's a new "systemctl suspend-then-hibernate" command that
does exactly this (with a 3 hour delay) and gnome seems to execute it
automatically instead of the classic "systemctl suspend".
On one hand, this is absolutely awesome, and I've been wanting this for
ages. Windows can do it, general users are used to this, and are usually
very surprised when they have a Fedora laptop that drains their battery to
0% during a few days long suspend (that's the case for my wife and my
On the other hand, I'm a bit concerned that the default behavior changed
unannounced and doesn't even seem configurable. In gnome-control-center, my
power button action is configured to "suspend", yet it clearly performs
"suspend-then-hibernate". There seems to be no way to opt out of this and
use just a classic suspend. Another question is what happens if
hibernation/resuming is not configured properly (swap partition missing,
resume= argument missing, etc). Have those edge cases been covered?
So, my questions are - has this been a deliberate change or is it just some
happy coincidence of some systemd+gnome interactions? Will there be some
release notes for the users announcing the change? Do plan to make it
configurable (allowing users to select between suspend and
suspend-then-hibernate)? Should we focus on testing the corner cases?
As many of you know, I've been gone half the summer. I'm back now since
Monday though and just in time for GNOME 3.30.0 :)
We are quite a bit behind with the builds, like half of GNOME is still
at 3.28.x or at various stages of 3.29.x snapshots, so there's quite a
bit of catching up to do.
I just requested a f29-gnome side tag and will be commencing 3.30.0
builds shortly. When the builds are done, I'll try to collect all the
builds in a single Bodhi megaupdate as usual. Please use 'fedpkg build
--target f29-gnome' if you are helping with builds, and I'll pick up
anything that is tagged with f29-gnome in koji.
Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29
Beta, I guess it may be too late for that. Any opinions from QA here?
There's also a few 3.30.0 builds already submitted separately into
Bodhi. I may try to collect those to the megaupdate as well, not sure
yet. Let's see how things go :)
I have installed a fresh F29 system and I was a bit surprised that Vulkan
drivers weren't present on that system, I had to manually install them
(mesa-vulkan-drivers). Vulkan is getting pretty popular lately, there are
certain high-profile games on Linux that use Vulkan *exclusively* (you
can't run them on OpenGL), and there are many other games which have Vulkan
as an option, which might improve performance. The latest breaking news
were Valve enabling Wine-based compatibility layer in Steam, that can be
used to run many Windows-only games on Linux, and it's again relying on
Vulkan. So Vulkan is definitely getting mainstream.
In order to have Fedora Workstation appealing to general users, I believe
it should be a good choice for gaming (Christian wrote on his blog about
considering including gamemode by default, that also ties into this).
Is there any reason why Vulkan drivers are not installed by default in
Fedora Workstation? Is that something we can fix for F29?