After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784535 - Won't launch from desktop entry
Won't launch from desktop entry
Status: RESOLVED FIXED
Product: recipes
Classification: Other
Component: general
1.0.x
Other Linux
: Normal major
: ---
Assigned To: Recipes maintainer(s)
Recipes maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-07-05 03:50 UTC by Tristan Partin
Modified: 2017-07-05 19:13 UTC
See Also:
GNOME target: ---
GNOME version: 3.23/3.24


Attachments
data: Configure D-BUS service file to use the full binary path (1.86 KB, patch)
2017-07-05 16:06 UTC, Ikey Doherty
committed Details | Review

Description Tristan Partin 2017-07-05 03:50:54 UTC
I am trying to package this software on Solus. I have it building, but I can't launch the program from its desktop entry. Launching from terminal gives no error but does launch the program. The exec line in the .desktop is 'gnome-recipes %f'. Any idea how I can fix this this? Just for giggles I also deleted the %f from the exec line, but to no avail.
Comment 1 Tristan Partin 2017-07-05 03:57:20 UTC
More info: I am using the Budgie desktop environment.
Comment 2 Tristan Partin 2017-07-05 04:20:12 UTC
Update: If I set the value of DBusActivatable to false the program will run. Seems like this could be Budgie specific because from what I understand, Josh Strobl was able to launch the program just fine under GNOME. I am no dbus expert, but what could this mean. Any helpful info would be appreciated so that I can take it back to the Budgie team.
Comment 3 Joshua Strobl 2017-07-05 04:33:13 UTC
This is completely inaccurate (and the opposite) of what I stated. It doesn't work under GNOME Shell under Solus.
Comment 4 Tristan Partin 2017-07-05 04:34:47 UTC
Sorry. Bad at English apparently.
Comment 5 Matthias Clasen 2017-07-05 14:29:17 UTC
why not just use the flatpak ?
Comment 6 Tristan Partin 2017-07-05 14:52:39 UTC
I feel like that is just avoiding the issue.
Comment 7 Ikey Doherty 2017-07-05 15:00:53 UTC
Disclaimer: I don't know the internals of this bug but I will comment on "why flatpak".

@Matthias Solus will employ Flatpak for otherwise unobtainable/undistributable software, such as Chrome, etc, in future. GNOME Recipes is open source.

For open source software, we package and integrate them in accordance with our stack, so we'd use the 3.24.x packages for GNOME suite applications. There is no sense in us using a Flatpak for something we can build from source, and ensure is shipped to our users in an integrated fashion.

This way we ship a cohesive integrated system with a logical update pattern as a full OS, not a collection of random bits from here, there, and everywhere.
Comment 8 Matthias Clasen 2017-07-05 15:13:33 UTC
I'm sure you can work out the packaging issues, then.
Comment 9 Ikey Doherty 2017-07-05 15:14:43 UTC
So you've no interest in helping Tristan fix the issue with your software and make it available to more users?
Comment 10 Matthias Clasen 2017-07-05 15:22:32 UTC
I don't think it is an issue with my software.
Comment 11 Ikey Doherty 2017-07-05 15:30:15 UTC
Your D-BUS service file is not using an absolute PATH, so dbus will struggle

gedit:

[D-BUS Service]
Name=org.gnome.gedit
Exec=/usr/bin/gedit --gapplication-service


gnome-recipes:

[D-BUS Service]
Name=org.gnome.Recipes
Exec=gnome-recipes --gapplication-service

Changing this to:
Exec=/usr/bin/gnome-recipes --gapplication-service

It then launches fine. Other GNOME applications configure a template file before writing it to include the absolute path (D-BUS does not like you relying on PATH or environments) - a simple fix here is during your meson build to actually configure the real path to the binary into the dbus session file.

Perhaps flatpak environment is doing something differently than normal distros, but this one-line change is enough to make GNOME Recipes launch with: gapplication launch org.gnome.Recipes                 

I would say that this no longer qualifies as "NOTGNOME", and I'm frankly kinda annoyed that you dismissed it instantly because it's not Flatpak, which is an incredibly narrow world view to hold.

It took me all of 3 minutes to figure that out myself because I was willing to help Tristan, yet you were not. I'll give Tristan the patch on our own tracker as it's very apparent that GNOME is enforcing Flatpak at the detriment of Linux distributions.
Comment 12 Matthias Clasen 2017-07-05 15:50:57 UTC
a patch for that would be welcome, of course.
Comment 13 Ikey Doherty 2017-07-05 16:06:04 UTC
Created attachment 354938 [details] [review]
data: Configure D-BUS service file to use the full binary path

Added patch to ensure dbus service file is correctly configured
Comment 14 Matthias Clasen 2017-07-05 16:09:47 UTC
> Perhaps flatpak environment is doing something differently than normal distros, 

flatpak is rewriting the exec line to:

Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=/app/bin/gnome-recipes org.gnome.Recipes --gapplication-service
Comment 15 Ikey Doherty 2017-07-05 16:10:48 UTC
Yeah so you have the benefit of magically-working-paths with flatpak then it seems.
Comment 16 Matthias Clasen 2017-07-05 16:50:29 UTC
Attachment 354938 [details] pushed as 431d507 - data: Configure D-BUS service file to use the full binary path
Comment 17 Tristan Partin 2017-07-05 19:13:43 UTC
Thank you for the assistance Matthias and Ikey.