nokey warning during F33->F34 upgrade (fstrm package)
by Germano Massullo
After running
dnf system-upgrade download --releasever=34
and downloading all files, I got the following warning
warning:
/var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm:
Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY
Why this package does not have a key?
Cheers
3 years
Re: KDE Autostart in F34
by Rex Dieter
Ravindra Kumar wrote:
> Hi,
>
> I hope there are some KDE experts on the list who can help me debug this -
> https://bugzilla.redhat.com/show_bug.cgi?id=1953472.
>
> It looks like KDE in Fedora 34 is not honoring open-vm-tools autostart
> script in /etc/xdg/autostart/vmware-user.desktop. GNOME seems to work
> fine.
>
> Could you please confirm if KDE supports autostart scripts from
> /etc/xdg/autostart dir? If yes, is there a regression in F34?
kde plasma on f34 uses systemd user session and systemd-xdg-autostart-
generator, so yes, autostart is supported (but this new method has some
quirks).
I commented in the bug with some debugging steps to try.
-- Rex
3 years
Re: KDE Autostart in F34
by Benjamin Berg
On Tue, 2021-04-27 at 20:03 +0000, Ravindra Kumar wrote:
> > This desktop file need to be replaced by the systemd-user unit,
> > IMO.
>
> Thanks Vitaly. We will look into converting it to systemd-user unit.
> I believe that would work for all other desktop managers as well.
Yeah, you might want to ship both a systemd unit and an XDG autostart
file for the time being. There will still be graphical desktops
environments which are not started using systemd in the foreseeable
future.
If you decide to ship both, please add X-GNOME-HiddenUnderSystemd=true
and X-systemd-hidden=true to the desktop file to prevent the service
from getting started twice.
If the ExitType= patch fixes this, then the problem is that the
generated service does not handle forking services right now and it
will work fine with systemd v249 and later.
Benjamin
3 years
Flatpak install and DNF removal
by Ian McInerney
I was just experimenting after poking at this bug http
s://bugzilla.redhat.com/show_bug.cgi?id=1847265, and I found some
interesting behavior.
This is how to reproduce it:
1) Use the Cinnamon live CD
2) Install a random flatpak (note, since this is on live you have to deal
with the space issue first)
sudo ostree --repo=/var/lib/flatpak/repo/ config set
core.min-free-space-size 0MB
sudo flatpak install org.gnome.Mahjongg
3) Remove xdg-desktop-portal-gtk
In step 3 it will also want to remove flatpak, but in step 2 I made a
conscious choice to install a flatpak - so this will then mean I lose
access to that flatpak I had installed. This can of course be prevented by
doing "dnf mark install flatpak", but that is another manual step you have
to do.
This leads to the question: how can this be handled? When a user uses
Flatpak to install a program, I would assume their expectation is that
flatpak shouldn't be removed unless the user requests it explicitly (so not
this behavior). I guess there are 2 ways to really fix this:
1) Mark flatpak as being user installed once at least one flatpak is
installed.
2) Add flatpak as an explicit program on all live CDs it is included on
right now.
The cleanest would probably be 1, but can that even be done?
-Ian
3 years
Packages in need of a new maintainer
by Johannes Lips
Dear all,
after quite some years, I would like to hand over the following packages to new maintainers. I will not orphan them if no one picks them up, but it would be great if someone with an interest in these packages could take them over.
backintime - backintime backup tool
elementary-icon-theme - Icons from the Elementary Project
elementary-xfce-icon-theme - Icons for Xfce based on the elementary Project Icon Theme
texstudio - A feature-rich editor for LaTeX documents
I am still using these, but the burden of doing package maintenance besides my day job and personal stuff is too high.
Thanks in advance for any volunteers
johannes
3 years