| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
The "install arg in configure_file" from 0.50.0 was still being used in
other places. Make sure to remove its use completely to support meson
0.49.0 as required in the top-level meson.build.
WARNING: Project specifies a minimum meson_version '>= 0.49.0' but uses features which were added in newer versions:
* 0.50.0: {'install arg in configure_file'}
Follow-up on b6c23eb2b378942e746676cb69f210ec0cb1eeb6
|
| |
|
|
|
|
|
|
|
|
|
| |
The move to use Restart=on-abnormal happened because gsd-xsettings would
die if Xwayland shuts down. However, since gnome-shell commit 01a927f388
and related changes, we should be waiting for gsd-xsettings to shut down
gracefully before Xwayland is stopped.
As such, we should only hit an exit failure if from gsd-xsettings if
Xwayland crashes. If gnome-shell follows up with a stop of the services
within 100ms, then such a restart will not even be attempted.
|
| | |
|
| |
|
|
|
| |
colord has become completely dependent on udev, not available on
non-Linux, so make the color plugin optional to fix build there.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The symlinks need to be installed into DESTDIR, use a shell to do this
correctly. Also, doing this on debug builds is not very helpful,
instead, do it by testing whether we are installing into the same prefix
that systemd is coming from.
This assumes that we will run using the same systemd instance as we are
picking up the pkgconfig file from, but that seems like a reasonable
assumption (i.e. it is unlikely anyone has systemd in their prefix and
doesn't bother to set things up correctly).
|
| |
|
|
| |
This shouldn't be enabled on distro builds which should use plain buildtype
|
| |
|
|
|
|
|
| |
We need to both reliably shutdown and notify gnome-shell that we are
ready. The gnome-session-x11-services.target does the first (we order
ourselves After= to ensure this works) and the -ready.target is our flag
to tell gnome-shell it may release the X11 socket for clients.
|
| |
|
|
|
|
| |
This means we cannot accidentally start the old targets in case they
exist on the host system. It is solely useful when using jhbuild to run
a test session and is disabled on release builds for that reason.
|
| |
|
|
|
| |
This means the .desktop and the systemd unit files are named
consistently.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than having per-plugin units, generate them from the meson build
file using a common template.
The unit layout is changed somewhat. The .target file now is solely a
flag on whether the service is requested for the session type. The
variosu requirements are all moved into the .service file.
Instead of using an OnFailure and trying to contain the dependency
errors in a separate unit, we now use ExecStopPost. It seems that the
current approach has never worked anyway.
The Conflict entries on certain session types are gone now. This is
instead handled outside of gnome-settings-daemon.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is to generate a gsd-X-gate.target intermediate unit which
has a requisite on all units listed in plugin_gate_units.
i.e. for most services we are going to have:
* gsd-X.target: marker on whether services should run in the session
* gsd-X.service: actual service that is started
This changes for units that should only run under certain conditions
(e.g. X11 or smartcard). In that case we add
+ gsd-X-gate.target
which has a proper requisite on all required units and ensures that the
servie will only start if all dependencies are met. This gate unit is
primarily needed so that we can still have an OnFailure target in the
.service file without issues.
|
| |
|
|
|
| |
Some indentation was wrong, and 4 space indentation is overall more
readable.
|
| |
|
|
|
|
| |
It seems sensible to use a more human readable description for the
.desktop file rather than just the plugin name. Hopefully this is more
useful to anyone expecting the file.
|
| |
|
|
|
| |
These can be consumed by the build system to generate nicer
.desktop/.service/.target files.
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently we have no plugin that uses special flags or similar to start
only under certain conditions. So just generate all of them from two
template files rather than shipping seperate templates for each plugin.
The idea here is to handle any possible future difference also during
generation. This might e.g. be that we again start certain services only
if a GSettings key is set, which would likely need to be mirrored e.g.
in the systemd path.
|
| |
|
|
|
|
|
|
|
|
| |
There is no need to have two places for desktop file generation for
services that can be disabled. Instead, integrate the logic into the
main plugin loop and simply use a different template file as the input.
To implement this, create a list of disabled modules that can be tested
to skip the generation of the systemd units and inclusion of the plugin
directory.
|
| |
|
|
|
|
| |
It is not really worth it to use a loop just to set the log domain using
the cflags. Explicitly name the common subdirectory rather than
including it in the plugin loop.
|
| |
|
|
|
|
| |
With GNOME 3.36 we are going to move the definition about the systemd
services that should be running to be per-session type. This means we
need to stop installing those wants entries in g-s-d.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds the ability to make use of UBSGuard to disable new USB
devices while the lockscreen is on. Note that USBGuard as of 0.7.5 is
needed.
In order to make use of this feature, you need to enable it first,
e,g, through gsettings set org.gnome.desktop.privacy usb-protection true.
And you need to have USBGuard installed, of course. Beware though: With the
default configuration the user is likely to be locked out of their
system. We encourage downstreams to change the default configuration
value s.t. USB devices are enabled unless a rule explicitly blocks them.
We take some care about users in that we allow keyboards and hardwired
devices, though.
The intended behaviour is: If the lockscreen is on, newly inserted USB
devices will not be accepted. A notification is given to the user that
they have to unlock the session and re-plug the device.
Ludovico de Nittis <denittis@gnome.org> did most of the work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There's some changes in how this service is started:
- Instead of it being part of the gnome-session target initialization
chain, it now depends on a new gnome-session-x11-services target.
Initialization of this target is left up in the air here, and may
happen during startup or at any random point during the running
session. The same analogous behavior will be seen at shutdown.
- The Restart condition has been softened to on-abnormal, as unclean
exits are somewhat unavoidable on Xwayland restart scenarios. Other
crashes or abnormal signals should still be intercepted as usual,
and lead to the fail whale.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the facility added in the previous commit, we can add systemd user
service files for all plugins and know when they have started up.
This is roughly based on the work previously done by Iain Lane
<iain@orangesquash.org.uk> and Bastien Nocera hadess@hadess.net>.
For each g-s-d process we have a service and a target file. This
separation only exists to contain dependency failures which would cause
an OnFailure action to trigger and is needed so that we can use
OnFailure for the gnome-session fail-whale
(gnome-session-failed.target).
In general, the approach taken is that we start g-s-d processes after
gnome-session-initialized.target and before gnome-session.target.
We want to be able to selectively start the services only when one or
more dependencies are there, or even mask out services under some
conditions. The approach taken is the following:
* To mask a service, use a Conflicts entry. This is e.g. used to not
start certain services in GDM using
Conflicts=gnome-session@gnome-login.target
* To depend on multiple targets to be up and running to start, we set
each of these targets in Requisite/After/PartOf/WantedBy. We always
do this for gnome-session-initialized.target but this method is
extensible to any number of further targets (e.g. bluetooth.target)
|
| |
|
|
|
|
|
| |
The plugins are about to switch to being activated by systemd. We need a
way for them to signal to systemd when they are ready. We'd like to
avoid linking to libsystemd, so sd_notify() is out - let's have the
plugins claim a name on the bus and then we can create Type=dbus units.
|
| |
|
|
|
|
|
|
| |
Heavily based on code from nm-applet.
Follow-Ups:
- Allow to store SIM in keyring
- Handle PUKs? (or do that in g-c-c)
|
| |
|
|
|
|
| |
This responsibility was taken over by mutter, where it can be made to work
both on Wayland and X11. This clipboard manager implementation becomes
superfluous then.
|
| |
|
|
|
|
|
|
|
|
|
| |
There is nothing left in the mouse plugin but the settings migration,
which occurred more than 3 years ago in GNOME 3.14.
Remove that plugin altogether.
Note, we keep the schemas as this is still used by the XSettings plugin.
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every plugin generate an autostart desktop file, except `common`
and `dummy` that are special cases.
This desktop file generation is duplicated among the different
plugin's build files.
This code has been moved to the build file in the `plugins`
directory, avoiding any code duplication.
The downside of this is that meson is not able to generate files
in a different directory, so all the files will be generated in
the `plugin` directory, outside of the each plugin's directory.
This is something that it's worked on in a different feature and
it might be merged in the future.
See https://github.com/mesonbuild/meson/pull/2617
https://bugzilla.gnome.org/show_bug.cgi?id=793087
|
|
|
meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.
https://bugzilla.gnome.org/show_bug.cgi?id=793087
|
