As people who have followed the work on sandboxed applications know, we have promised a developer preview for GNOME 3.16. Well, 3.16 has now been released, so the time is now!
I spent last week setting up an build system on the GNOME infrastructure, and the output of this is finally available at:
This repository contains the gnome 3.16 runtimes, org.gnome.Platform, as well as a smaller one that is useful for less integrated apps (like games) called org.freedesktop.Platform. It also has corresponding develoment runtimes (org.gnome.Sdk and org.freedesktop.Sdk) that you can use to create applications for the platforms.
This is a developer preview, so consider these builds weakly supported. This means I will try to keep them somewhat updated if there are major issues and that I will keep them API and ABI stable. I will probably also pick up at least some 3.16.x minor releases as they are released.
I also did the first official release of xdg-app. For easy testing this is available for Fedora 21 and 22 as a copr repo.
Testing the SDK
Using the repo above makes it really easy to test this. Just install the xdg-app package from copr, log out+in (needed update the environment for the session), then follow these instructions (as a regular user):
- Install the Gnome SDK public key into /usr/share/ostree/trusted.gpg.d, (or alternatively, use –no-gpg-verify when you add the remote below).
- Install the basic Gnome and freedesktop runtimes:
$ xdg-app add-remote --user gnome-sdk http://sdk.gnome.org/repo/ $ xdg-app install-runtime --user gnome-sdk org.gnome.Platform 3.16 $ xdg-app install-runtime --user gnome-sdk org.freedesktop.Platform 1.0
- Optionally install some locale packs:
$ xdg-app install-runtime --user gnome-sdk org.gnome.Platform.Locale.se 3.16 $ xdg-app install-runtime --user gnome-sdk org.freedesktop.Platform.Locale.se 1.0
- Install some apps from my repository of test apps:
$ xdg-app add-remote --user --no-gpg-verify test-apps https://people.gnome.org/~alexl/test-apps/repo/ $ xdg-app install-app --user test-apps org.gnome.gedit $ xdg-app install-app --user test-apps org.freedesktop.glxgears
- Run the apps! You should find gedit listed among the regular applications in the shell as it exports a desktop file. But you can also run them manually like this:
$ xdg-app run org.gnome.gedit $ xdg-app run org.freedesktop.glxgears
- I also packaged the latest gnome builder from git. It requires the full sdk which takes a bit longer to download:
$ xdg-app install-runtime --user gnome-sdk org.gnome.Sdk 3.16 $ xdg-app install-app --user test-apps org.gnome.Builder
All the above install the apps into your home-directory (in ~/.local/share/xdg-app) . You can also run the commands as root and skip the –user arguments to do system-wide application installs.
Future work
With the basics now laid down to run current applications in a minimally isolated environment the next step is to work on the sandboxing aspects more. This will require lots of work, both in the system side (things like kdbus), the desktop (add sandbox aware APIs, make pulseaudio protect clients from each other, etc) and in modifying applications.
If you’re interested in this, you can follow the work on the wiki.
Building your own apps
If you download the SDKs you have enough tooling to build your own applications. There are some documentations on how to do this here.
I also created a git repository with the scripts I used to build the test applications above. It uses the gnome-sdk-bundles repostory which has some tooling and specfiles to easily bundle dependencies with the application.
Building the SDK
If you ever want to build the SDK yourself, it is available at:
https://git.gnome.org/browse/gnome-sdk-images
This repository contains the desktop specific parts of the SDK, which is layered on a core Yocto layer. When you build the SDK this will be automatically checked out and built from:
https://git.gnome.org/browse/freedesktop-sdk-base
However, if you don’t want to build all of this you can download the pre-build images from http://sdk.gnome.org/images/x86_64/ and put them in the freedesktop-sdk-base/images/x86_64 subdirectory of gnome-sdk-images. This can save you a lot of time and space.
Wow, this is really awesome news! Thanks Alexander!
Great work, thank you!
When I start Builder using
xdg-app run org.gnome.Builder
nothing happens. Where to start digging?
lzap:
Do the other apps work?
To debug, run something like:
xdg-app run –command=sh org.gnome.Builder
This will give you a shell in the “sandbox”. From there you can try manually starting /self/bin/gnome-builder and see what happens.
Yes, gedit worked just fine.
It looks like it coredumps for me 🙁
[lzap@lzapx ~]$ xdg-app run -–command=sh org.gnome.Buildererror: Unknown option -–command=sh
[lzap@lzapx ~]$ xdg-app run –command=sh org.gnome.Builder
error: '–command=sh' is not a valid application name
[lzap@lzapx ~]$ xdg-app run –command=sh
error: '–command=sh' is not a valid application name
[lzap@lzapx ~]$ xdg-app run --help
Usage:
xdg-app run [OPTION...] APP [args...] - Run an app
Help Options:
-h, --help Show help options
Application Options:
--arch=ARCH Arch to use
--command=COMMAND Command to run
--branch=BRANCH Branch to use
-d, --devel Use development runtime
--runtime=RUNTIME Runtime to use
--allow=KEY Environment options to set to true
--forbid=KEY Environment options to set to false
-v, --verbose Print debug information during command processing
--version Print version information and exit
[lzap@lzapx ~]$ coredumpctl dump
PID: 2 (kthreadd)
UID: 1000 (lzap)
GID: 1000 (lzap)
Signal: 11 (SEGV)
Timestamp: Wed 2015-04-01 09:31:29 CEST (1min 54s ago)
Control Group: /
Boot ID: 9ba46bac99374655b870c94d5705f8e2
Machine ID: e50c4b1558464065bb34c1d31d6ae9d4
Hostname: lzapx.brq.redhat.com
Coredump: /var/lib/systemd/coredump/core.kthreadd.1000.9ba46bac99374655b870c94d5705f8e2.2.1427873489000000.xz
Message: Process 2 (kthreadd) of user 1000 dumped core.
Stack trace of thread 5:
#0 0x00007fe356b8d17a n/a (n/a)
Looks like you have some weird dash in ‘-–command=sh’, just use two regular minus signs.
Same problem here. It’s a SIGSEGV. backtrace:
#0 __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:30
#1 0x00007ffff107bd79 in g_str_equal () from /lib/libglib-2.0.so.0
#2 0x00007ffff7b82535 in is_special_directory (directory=directory@entry=0x882b00)
at libide/tasks/ide-load-directory-task.c:77
#3 0x00007ffff7b826e8 in ide_load_directory_task_load_directory (self=self@entry=0x7c8760, directory=0x882b00,
error=error@entry=0x7fffdd4b1c78) at libide/tasks/ide-load-directory-task.c:169
#4 0x00007ffff7b82c61 in ide_load_directory_task_worker (task=, source_object=,
task_data=0x7c8760, cancellable=0x0) at libide/tasks/ide-load-directory-task.c:339
#5 0x00007ffff22a4695 in ?? () from /lib/libgio-2.0.so.0
#6 0x00007ffff10b2428 in ?? () from /lib/libglib-2.0.so.0
#7 0x00007ffff10b1aa5 in ?? () from /lib/libglib-2.0.so.0
#8 0x00007ffff0c2a234 in start_thread (arg=0x7fffdd4b2700) at pthread_create.c:313
#9 0x00007fffeeee8bdd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
I have experimented some similar issues in Rawhide with Builder related to the XDG special folders (in a docker rawhide). I need do create (mkdir) and define the folders with
xdg-user-dirs-update --set DOCUMENTS ~/Documents(for example). I don’t know if it’s an environment bug or a GLib bug or a Builder bug. The problem is in is_special_directory function (in this line https://github.com/chergert/gnome-builder/blob/866b6a825db39642b6f10af613f973084e81ccbc/libide/tasks/ide-load-directory-task.c#L76)Ah, so that is more of a bug to report to gnome-builder upstream.
I just built latest from git. When its fixed I can do an update to the app repo.
Sorry about the weird UTF character 😉
Thanks, regular updates would be awesome.
Should be fixed in master (the g_str_equal() issue). Ideally, we don’t want to hit the “fallback directory VCS” and instead load a project with git, but we need the project selector in place first. Until then, you’ll have much better luck running gnome-builder from within your project tree.
However, I hope to have the project selector ready for 3.16.1.
API/ABI stability? is there some sort of plan on how runtimes will be introduced?
and thanks on your work, this is probably single most important step that is happening right now
someone: The API/ABI stability is done by not changing the runtime much. This is not a problem overall, because you can parallel install newer runtimes for apps that need them.
Note:
I just pushed a change that slightly modified how the xdg-app build-init command works. All the docs and example code is updated, but this means that if you want to experiment with building apps you need to build xdg-app from git (or wait for the next version after 0.1).
Hi there, I am designing a GameEngine like Godot Engine http://www.godotengine.org/wp/ just for fun, on this engine everything is a Node. However there are vala binding for gthree? or should I use genie for this? Another question gtk apps runs on android?
sorry for post the question here but, the Gthree post does not admit more comments
Regards
Miguel: I’ve not made any vala or genie bindings for gthree. Also, gtk does not run on androind atm.
Ok but the opengl support is in a special gtk widget right?, also are there plans for made Gtk available on android?
1. Yes, Gthree uses GtkGLArea
2. There are no OpenGL bindings for Vala (or Genie) that are both maintained and not hopelessly out of date with regards to the OpenGL API coverage
3. There are no plans for a GTK+ port on Android, unless somebody wants to work on it
Thanks Emmanuele, did you consider a good idea to integrate graphene in my game engine? or do you have any suggestions.
thanks in advice.
Hi Alex,
great project! Do I understand right that one of the advantages of this project is that I can newer apps on my older system? For example: run Apps for Gnome 3.16 on my System with Gnome 3.14 without needing to upgrade?
Emanuel: Yes, that is one of the advantages.
Cool, thanks. Keep it up!
Hi Alex
I recently tried building against the gnome-sdk and it works great, except the application cannot run because of a missing python module.
I would love to report this but I am unsure where. Also I am not a true developer, so do not expect too much of me.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
What module? In general you would need to bundle everything that is not in the runtime.
According to the application I am attempting to start, the ctypes module is missing.
To be more precise there is a file “/usr/lib/python3.4/lib-dynload/_ctypes.cpython-34m-x86_64-linux-gnu.so” that is not present in the runtime. Not sure if this is intended or not, but it is included by default with both the Arch and Debian/Ubuntu packages of python3.4.
I am aware I need to bundle some dependencies myself and understand how I accomplish this. It is a lot as it is though, and I would prefer not having to bundle python3.4 as well when it is included in the runtime already.
I belive the bundled python (from yocto) is 3.3 not 3.4.
Oh, my mistake. I don’t know where I got that from. 3.3 is indeed the bundled version.
I have access to my test machine again and could now share the error in more detail:
import ctypes
File “/usr/lib/python3.3/ctypes/__init__.py”, line 7, in
from _ctypes import Union, Structure, Array
ImportError: No module named ‘_ctypes’
Even so, I feel it may now be more appropriate if I put this as an issue on the app bug tracker, as was my initial instinct.
I have problems with running apps. Gedit requires to run it with different DISPLAY variable, so I have to run it in this way:
xdg-app run –command=/bin/bash org.gnome.gedit -c ‘DISPLAY=’$DISPLAY’ /self/bin/gedit’
Different situation I have with glxgears, It can’t connect to X Server even I change the DISPLAY variable.
nintyfan:
It is meant to automatically pick up the X socket, but this seems to have issues for some people.
See https://github.com/alexlarsson/xdg-app/issues/68 for trying to track down why this fails.