Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 2010608

Summary: rpm2flatpak doesn't use custom build of a dependency
Product: [Fedora] Fedora Modules Reporter: Milan Crha <mcrha>
Component: flatpak-runtimeAssignee: Kalev Lember <klember>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: klember, mark, otaylor
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-10-13 20:43:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 2010597    

Description Milan Crha 2021-10-05 07:59:16 UTC
The bug #2010597 uncovered a problem in the build of the 'evolution' package.

The evolution package in the flaptak requires a special build of the evolution-data-server, to have a specific D-Bus prefix used in the container. That's done by:

      macros: |
        %_eds_dbus_services_prefix org.gnome.Evolution

in the evolution.yaml [1]. The evolution-data-server knows of this variable [2].

I guess, and only guess, that the build re-used a plain build of the evolution-data-server, instead of the one required by the evolution. I do not have a clue where to verify it, I only know that these things work properly.

When I enter the container I see the included evolution-source-registry uses D-Bus name `org.gnome.evolution.dataserver.Sources5`, which is wrong, it should use ``. That's causing the trouble in the bug #2010597.

This used to work properly in the past. I've no idea when it broke.


Comment 1 Kalev Lember 2021-10-05 11:14:32 UTC
Hm, if I look at the build logs, it looks like the flatpak container build has indeed picked up the evolution-data-server build from flatpak-common. I guess it's because the evolution-data-server build from flatpak-common happened to have a higher release number:

evolution-data-server-3.40.4-1.module_f34+12673+4f71ea37 (flatpak-common)
evolution-data-server-3.40.4-1.module_f34+12632+5ae7e8f8 (evolution)

A quick fix should be to just drop evolution-data-server from flatpak-common to work this around for now. I'm in the process of rebuilding all flatpaks to be based on F35 flatpak runtime and I can take care of this while doing the rebuilds.

Comment 2 Kalev Lember 2021-10-05 11:21:03 UTC

I'll update the ticket once the evolution build is done.

Comment 3 Milan Crha 2021-10-05 11:56:37 UTC
> A quick fix should be to just drop evolution-data-server from flatpak-common to work this around for now.

Won't that break the other apps, which expect it being available? I think of the GNOME Calendar and such, but I do not know how they build here.

Comment 4 Kalev Lember 2021-10-05 14:44:38 UTC
Yeah, we'll have to add it to the manifest for all the other apps that need it -- I'll take care of it.

Comment 5 Fedora Update System 2021-10-05 14:45:46 UTC
FEDORA-FLATPAK-2021-c6503004da has been submitted as an update to Fedora 35 Flatpaks.

Comment 6 Fedora Update System 2021-10-05 17:08:19 UTC
FEDORA-FLATPAK-2021-c6503004da has been pushed to the Fedora 35 Flatpaks testing repository.

You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 7 Fedora Update System 2021-10-13 20:43:56 UTC
FEDORA-FLATPAK-2021-c6503004da has been pushed to the Fedora 35 Flatpaks stable repository.
If problem still persists, please make note of it in this bug report.