A few weeks ago I installed F32-KDE fresh on a workstation (a disk drive failed). All of a sudden last night Portal service was started (whatever that is). I did nothing that I know of to trigger this. Furthermore, since updating after installing this system, that service has never been started until now.
Directly after the Portal service started, I see error messages coming from pipewire (whatever that is).
Can anyone tell me what this is all about and why it happens now?
(I'm especially concerned about why it started.)
Jul 16 00:20:59 vfr systemd[1168]: Starting Portal service... Jul 16 00:20:59 vfr systemd[1168]: Starting flatpak document portal service... Jul 16 00:20:59 vfr systemd[1168]: Starting sandboxed app permission store... Jul 16 00:20:59 vfr systemd[1168]: Started sandboxed app permission store. Jul 16 00:20:59 vfr systemd[1168]: Started flatpak document portal service. Jul 16 00:20:59 vfr systemd[1168]: Starting Portal service (GTK+/GNOME implementation)... Jul 16 00:20:59 vfr systemd[1168]: Started Portal service (GTK+/GNOME implementation). Jul 16 00:20:59 vfr systemd[1168]: Created slice dbus\x2d:1.2\x2dorg.freedesktop.impl.portal.desktop.kde.slice. Jul 16 00:20:59 vfr systemd[1168]: Started dbus-:1.2-org.freedesktop.impl.portal.desktop.kde@0.service. Jul 16 00:20:59 vfr systemd[1168]: Started Multimedia Service. Jul 16 00:20:59 vfr systemd[1168]: Created slice dbus\x2d:1.2\x2dorg.freedesktop.secrets.slice. Jul 16 00:20:59 vfr systemd[1168]: Started dbus-:1.2-org.freedesktop.secrets@0.service. Jul 16 00:20:59 vfr rtkit-daemon[910]: Successfully made thread 199490 of process 199489 (/usr/bin/pipewire) owned by '1000' RT at priority 20. Jul 16 00:20:59 vfr gnome-keyring-daemon[199496]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory Jul 16 00:20:59 vfr gnome-keyring-d[199496]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory Jul 16 00:20:59 vfr systemd[1168]: Started Portal service. Jul 16 00:20:59 vfr pipewire[199489]: [E][000458567.198429][pipewire.c:118 open_plugin()] can't load /usr/lib64/spa-0.2/jack/libspa-jack.so: /usr/lib64/spa-0.2/jack/libspa-jack.so: cannot open shared object file: No such file or directory Jul 16 00:20:59 vfr pipewire[199489]: [E][000458567.198439][pipewire.c:254 pw_load_spa_handle()] can't load 'jack/libspa-jack': No such file or directory Jul 16 00:20:59 vfr pipewire[199489]: [E][000458567.198442][spa-device.c:144 pw_spa_device_load()] can't load device handle: No such file or directory Jul 16 00:20:59 vfr pipewire[199489]: [E][000458567.198444][module-device-factory.c:167 create_object()] can't create device: No such file or directory Jul 16 00:20:59 vfr pipewire[199489]: [E][000458567.198446][private.h:241 pw_core_resource_errorv()] resource 0x563498cde520: id:4 seq:4 res:-2 (No such file or directory) msg:"can't create device: No such file or directory" Jul 16 00:20:59 vfr pipewire[199492]: [E][000458567.198572][core.c:71 core_event_error()] core 0x559e4a521e00: proxy 0x559e4a54dbb0 id:4: seq:4 res:-2 (No such file or directory) msg:"can't create device: No such file or directory" Jul 16 00:20:59 vfr pipewire[199492]: [E][000458567.198579][media-session.c:1647 core_error()] error id:4 seq:4 res:-2 (No such file or directory): can't create device: No such file or directory Jul 16 00:20:59 vfr pipewire[199489]: [E][000458567.202044][alsa-pcm.c:33 spa_alsa_open()] hw:0,0: open failed: Device or resource busy Jul 16 00:20:59 vfr pipewire[199489]: [W][000458567.202053][adapter.c:175 find_format()] adapter 0x563498d30c90: can't get format: Device or resource busy Jul 16 00:20:59 vfr pipewire[199489]: [E][000458567.202056][module-adapter.c:231 create_object()] can't create node: Device or resource busy Jul 16 00:20:59 vfr pipewire[199489]: [E][000458567.202059][private.h:241 pw_core_resource_errorv()] resource 0x563498cde520: id:20 seq:74 res:-16 (Device or resource busy) msg:"can't create node: Device or resource busy" Jul 16 00:20:59 vfr pipewire[199492]: [E][000458567.218111][core.c:71 core_event_error()] core 0x559e4a521e00: proxy 0x559e4a56d5b0 id:20: seq:74 res:-16 (Device or resource busy) msg:"can't create node: Device or resource busy" Jul 16 00:20:59 vfr pipewire[199492]: [E][000458567.218124][media-session.c:1647 core_error()] error id:20 seq:74 res:-16 (Device or resource busy): can't create node: Device or resource busy Jul 16 00:21:29 vfr xdg-desktop-por[199455]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list
On Thu, 16 Jul 2020 11:53:41 -0400 "Garry T. Williams" gtwilliams@gmail.com wrote:
A few weeks ago I installed F32-KDE fresh on a workstation (a disk drive failed). All of a sudden last night Portal service was started (whatever that is). I did nothing that I know of to trigger this. Furthermore, since updating after installing this system, that service has never been started until now.
Directly after the Portal service started, I see error messages coming from pipewire (whatever that is).
xdg-desktop-portal.x86_64 : Portal frontend service to flatpak
Summary : Media Sharing Server Description : PipeWire is a multimedia server for Linux and other Unix like operating systems.
Can anyone tell me what this is all about and why it happens now?
I don't know for sure, but it looks like Portal monitors sites (like flathub) on the web, and when there are updates, launches itself and pipewire. There is probably a default conf file somewhere that controls its behavior.
Since it is a systemd service (from your output), you should be able to mask it if you never want it to run. That will probably take care of pipewire starting as well.
It seems that a lot of dependencies were not installed with it, as all the failures attest. If you want to use it, you should probably reinstall it so the necessary dependencies for it to function are pulled in.
On Thursday, July 16, 2020 1:22:59 PM EDT stan via users wrote:
On Thu, 16 Jul 2020 11:53:41 -0400 "Garry T. Williams" gtwilliams@gmail.com wrote:
A few weeks ago I installed F32-KDE fresh on a workstation (a disk drive failed). All of a sudden last night Portal service was started (whatever that is). I did nothing that I know of to trigger this. Furthermore, since updating after installing this system, that service has never been started until now.
Directly after the Portal service started, I see error messages coming from pipewire (whatever that is).
xdg-desktop-portal.x86_64 : Portal frontend service to flatpak
Summary : Media Sharing Server Description : PipeWire is a multimedia server for Linux and other Unix like operating systems.
Thank you, Stan. Of course, those descriptions do very little to allow me to understand what this stuff is. Web searches (which I did do after seeing the log messages) indicate that this stuff is about *sharing* desktops. I cannot imagine why this stuff starts up a little after midnight local time, when I did not do anything to indicate that I wanted to share my desktop. And with whom?! Very strange, indeed.
Can anyone tell me what this is all about and why it happens now?
I don't know for sure, but it looks like Portal monitors sites (like flathub) on the web, and when there are updates, launches itself and pipewire. There is probably a default conf file somewhere that controls its behavior.
Hmmm. I used to be in charge of what got updated and when it got updated on my own machine. You indicate that there's another path with which to install software that I am no longer in charge of. That's alarming. Especially since I didn't ask for it.
Since it is a systemd service (from your output), you should be able to mask it if you never want it to run. That will probably take care of pipewire starting as well.
I knew how to do do that, but thank you.
I went one better and simply removed those two packages from my system. If, for any reason it turns out I later need them, I can reinstall them.
Erasing xdg-desktop-portal offered to erase a bunch of leaves no longer needed, including flatpak. My system's 150 MB smaller now. :-)
It seems that a lot of dependencies were not installed with it, as all the failures attest. If you want to use it, you should probably reinstall it so the necessary dependencies for it to function are pulled in.
Well, there's the odd thing, isn't it. Before, dnf would always solve dependencies and install them when a package was installed. Now there seems to be another path used for software installation and it doesn't know how to handle dependencies. I don't guess I need this stuff, for sure.
Thanks again for the reply.
On Thu, 16 Jul 2020 14:15:01 -0400 "Garry T. Williams" gtwilliams@gmail.com wrote:
Hmmm. I used to be in charge of what got updated and when it got updated on my own machine. You indicate that there's another path with which to install software that I am no longer in charge of. That's alarming. Especially since I didn't ask for it.
I think Gnome is moving to a multi update source model. They use binary rpms, modules, and flatpaks. I'm not convinced this is a step forward, but they do the work, so they make the rules. :-)
Well, there's the odd thing, isn't it. Before, dnf would always solve dependencies and install them when a package was installed. Now there seems to be another path used for software installation and it doesn't know how to handle dependencies. I don't guess I need this stuff, for sure.
Yes, that is why I have restricted all updates on my system to binary rpm only. I'll wait to see how things shake out, but this new system seems to leave conflicts in coverage, and opportunities for security breakage.
I think these new methods are a mitigation for a lack of package maintainers. By using flatpaks, they hope to offload the maintenance of those programs to someone else. Outsourcing if you will. I'm not sure what being a distribution means under that model. My experience is that the people who package software in Fedora are exceptional, and that is part of what I think of as the distribution of Fedora.
On Fri, 17 Jul 2020 at 11:14, stan via users users@lists.fedoraproject.org wrote:
On Thu, 16 Jul 2020 14:15:01 -0400 "Garry T. Williams" gtwilliams@gmail.com wrote:
Hmmm. I used to be in charge of what got updated and when it got updated on my own machine. You indicate that there's another path with which to install software that I am no longer in charge of. That's alarming. Especially since I didn't ask for it.
I think Gnome is moving to a multi update source model. They use binary rpms, modules, and flatpaks. I'm not convinced this is a step forward, but they do the work, so they make the rules. :-)
Well, there's the odd thing, isn't it. Before, dnf would always solve dependencies and install them when a package was installed. Now there seems to be another path used for software installation and it doesn't know how to handle dependencies. I don't guess I need this stuff, for sure.
Yes, that is why I have restricted all updates on my system to binary rpm only. I'll wait to see how things shake out, but this new system seems to leave conflicts in coverage, and opportunities for security breakage.
I think these new methods are a mitigation for a lack of package maintainers. By using flatpaks, they hope to offload the maintenance of those programs to someone else. Outsourcing if you will. I'm not sure what being a distribution means under that model. My experience is that the people who package software in Fedora are exceptional, and that is part of what I think of as the distribution of Fedora.
There is a worldwide shortage of exceptional people, so you want them focusing on the core system and services. Many workgroups now ( and even before COVID-19) consist of people with physical locations scattered across the globe and subject to varying enterprise IT policies. Flatpaks (when they work) offer consistency across distributions. Conda is another approach driven by the need to provide consistent environments across distros and even for Windows.
I'm not sure the model holds up well for all use cases. Certainly there are problems with apps that use audio or video input devices that rely on binary blobs and/or have licenses that aren't universally acceptable to all distos.
Conda is another approach
On Friday, July 17, 2020 10:13:10 AM EDT stan via users wrote:
I think Gnome is moving to a multi update source model. They use binary rpms, modules, and flatpaks.
[snip]
Apparently KDE, too.
Yes, that is why I have restricted all updates on my system to binary rpm only. I'll wait to see how things shake out, but this new system seems to leave conflicts in coverage, and opportunities for security breakage.
I knew how to disable the modular repository, although I didn't get around to doing it on this new install until now.
How do I shut off flatpak?
(That seems to be the vector for this unwanted daemon.)
On July 18, 2020 11:45:54 AM EDT, "Garry T. Williams" gtwilliams@gmail.com wrote:
How do I shut off flatpak?
(That seems to be the vector for this unwanted daemon.)
No, they were brought in a few days ago as weak deps of webkit2gtk3.
IIRC. AFK today.
On Sat, 18 Jul 2020 11:45:54 -0400 "Garry T. Williams" gtwilliams@gmail.com wrote:
I knew how to disable the modular repository, although I didn't get around to doing it on this new install until now.
How do I shut off flatpak?
(That seems to be the vector for this unwanted daemon.)
I don't know. But, as it seems to be a Gnomism, I would suspect that masking packagekit, the Gnome package manager, would do it. However, that means that all updates have to be done with dnf, and you will no longer get notices of updates in the Gnome desktop. That is, you lose functionality.
On Sunday, July 19, 2020 9:34:00 AM EDT stan via users wrote:
On Sat, 18 Jul 2020 11:45:54 -0400 "Garry T. Williams" gtwilliams@gmail.com wrote:
I knew how to disable the modular repository, although I didn't get around to doing it on this new install until now.
How do I shut off flatpak?
(That seems to be the vector for this unwanted daemon.)
I don't know. But, as it seems to be a Gnomism, I would suspect that masking packagekit, the Gnome package manager, would do it. However, that means that all updates have to be done with dnf, and you will no longer get notices of updates in the Gnome desktop. That is, you lose functionality.
I don't use Gnome -- I run KDE. And I already erased PackageKit. I never let that run on my systems.
On Saturday, July 18, 2020 12:44:03 PM EDT Tony Nelson wrote:
On July 18, 2020 11:45:54 AM EDT, "Garry T. Williams" gtwilliams@gmail.com wrote:
How do I shut off flatpak?
(That seems to be the vector for this unwanted daemon.)
No, they were brought in a few days ago as weak deps of webkit2gtk3.
I looked at the dnf logs and spotted this.
Upgrading webkit2gtk3 caused flatpak to be installed (along with xdg-desktop-portal-kde):
Installing weak dependencies: flatpak x86_64 1.6.4-1.fc32 updates 1.5 M p11-kit-server x86_64 0.23.20-1.fc32 fedora 189 k xdg-desktop-portal-kde x86_64 5.18.5-2.fc32 updates 191 k
I added excludepkgs to my dnf.conf file.
Problem solved.
2020-07-19 16:14 UTC+02:00, Garry T. Williams gtwilliams@gmail.com:
I looked at the dnf logs and spotted this.
Upgrading webkit2gtk3 caused flatpak to be installed (along with xdg-desktop-portal-kde):
Installing weak dependencies: flatpak x86_64 1.6.4-1.fc32 updates 1.5 M p11-kit-server x86_64 0.23.20-1.fc32 fedora 189 k xdg-desktop-portal-kde x86_64 5.18.5-2.fc32 updates 191 k
I added excludepkgs to my dnf.conf file.
Problem solved.
For the time being.
-
Andras Simon -
Garry T. Williams -
George N. White III -
stan -
Tony Nelson