The new command will take an extension directory set up
with `meson-build --sysext` inside a toolbox, and turn
it into a merged system extension on the host.
Namely it will
1. copy the extension directory from the container to the host
2. set up the extension-release file expected by systemd-sysext
3. compile gsettings schemas if necessary (using the merged
schemas directory)
4. install the extension to either runtime or system
5. merge the extension
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
While the toolbox image itself has all necessary dependencies to
build and run the shell, we still need them in the destdir when
building a system extension.
Achieve this by running .gitlab-ci/install-common-dependencies.sh
if it exists, which is the script that is used both for gnome-os
system extensions and mutter's CI image.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
When specified, the project is installed to a separate destdir
inside the container instead of the container's root filesystem.
This can be used to install several projects into a common extension
directory:
```
$ (cd mutter; meson-build.sh --sysext) &&
(cd gnome-shell; meson-build.sh --sysext)
```
We will later add a separate command to extract the directory
from the container and turn it into a system extension suitable
for use with systemd-sysext.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
The dist command only needs an up-to-date build directory, it
does not require the project to be installed first.
While the install step is generally quick, leaving the container
file system alone can save a rebuild after the dist is done
(for instance when testing a branch, then temporarily switching
to the release branch for dist).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3497>
Handing the various options to different meson commands in meson-build
gets a bit tedious. Instead of handling them all on the toplevel,
split out *_command() functions that generate the commandline for
the corresponding meson command.
That way, options are handled locally where they matter, which
makes future changes and additions a bit easier.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3497>
The main use of the --dist flag is as a fallback when the CI
dist job doesn't work for some reason. The gnome-shell tarball
now needs the --include-subprojects flag, and it doesn't hurt
for mutter/gnome-shell-extensions, so just add it when --dist
is specified.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3164>
It's useful when the existing build directory became invalid,
for instance after a meson update, and exposing it directly
from the wrapper script is more convenient than removing the
directory or entering the toolbox manually to invoke meson.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3113>
Unlike the other scripts, meson-build currently doesn't set
the `-e` option. The script is mainly a wrapper around a single
toolbox call, but it means that any errors during option parsing
print a warning, but are otherwise ignored.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3113>
Now that we have a collection of scripts around the toolbox
workflow, it makes sense to add a brief overview over the
available tools.
For now it's just located in the corresponding tools folder,
but it gives us something to point to once we overhaul the
toplevel documentation as part of the wiki migration.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3040>
As useful as the custom jhbuild setup was at the time, it has been
superseded by jhbuild proper (which gained the ability to install
system dependencies since) or alternatives like containers.
Given that the script hasn't been meaningfully updated for almost
10 years, its list of dependencies is hopelessly outdated, and it's
therefore more likely to confuse newcomers than being of actual
help.
As much as I have fond memories of the script when starting out,
it's finally time to retire.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3040>
Wrapping the gnome-shell call with `dbus-run-session` is *mostly*
enough for testing, but not quite.
When running without gnome-session, the wayland display is not
propagated to the D-Bus daemon, so any app that is D-Bus activated
still opens in the host session.
This can be worked around by using a specific wayland-display name
and exporting it to the `dbus-run-session` environment up-front.
At this point the invocation is finicky enough to justify another
convenience script. This also gives us a place to expose some
useful features for testing, like forcing a right-to-left layout
or simulating the greeter.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2935>
We don't require any build steps other than the standard meson
commands, but entering a toolbox and running 2-3 meson commands
still adds some friction.
Add a small convencience script that
- finds the toplevel source directory (similar to `jhbuild make`)
- enters the speficied toolbox (or the configured default)
- automatically picks a build directory based on the toolbox name
- builds and installs the project to /usr (inside the toolbox)
It also allows specifying meson -D options to change the build
configuration, and to optionally run `meson dist`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2935>
Setting up more than one gnome-shell toolbox is uncommon, and users
shouldn't have to specify --set-default for other tools to pick the
right default.
It would be possible to detect the number of containers that were
created from the shell toolbox image, but the far easier option is
to just set up the first container as default.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2935>
Out of the box, the container images only support US English. It
can sometimes be necessary to use a different locale, so add
a convenience flag to enable support for additional locales.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The container is useless for building or running gnome-shell unless
it includes the correct mutter version, so building it by default
makes sense.
However a manual build can be significantly faster when there's an
existing build dir, so add an option to skip the automatic build.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
A toolbox created by the script can be used as the base of a pet
container that is manually updated with new dependencies over time
and accumalates additional packages; or it can be used as a deposable
container that is recreated each time the dependencies change.
To make the latter case more convenient, add a --replace option
that deletes an existing toolbox before creating the new one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The script is a thin wrapper around `toolbox create`, mainly to
avoid the tedious image names. In addition, it allows us to
ensure that the container includes a matching mutter version.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The tool was added in 2018 to migrate to per-desktop overrides from the
old overrides system.
5 years later, everyone who’s going to migrate probably has migrated, so
we can delete the script and remove a process running on every login.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2611>
While the new per-desktop overrides in GIO are easier to use for
both developers and users, it is still inconvenient for everyone
who changed the defaults using the old overrides hack to lose
their settings. Address this by running a small script on startup
that migrates existing settings.
https://bugzilla.gnome.org/show_bug.cgi?id=786496
The script was used by a distcheck hook to check for files that are
in git, but not the distributed tarball. We dropped autotools support,
so the script is no longer used - in fact, it isn't useful anymore,
as `ninja dist` generates tarballs from git itself rather than from
a separately maintained list of files ...
gnome-shell-build-setup.sh is generally useful for working on GNOME.
If moving on from hacking on gnome-shell to some other module,
having the checkout location be ~/gnome-shell is a little odd and
cumbersome, so start out checking things out into ~/gnome/source
and installing them into ~/gnome/install.
Add a warning if the old ~/gnome-shell exists to avoid unnecessary
checking out of every module again.
https://bugzilla.gnome.org/show_bug.cgi?id=685355
Someone starting gnome-shell development work needs git-bz set up.
Install it into the user account much like we install jhbuild.
(Getting git-bz packaged into distributions would be better, but
this improves thing easily.)
https://bugzilla.gnome.org/show_bug.cgi?id=685354
Adding ignore_suggests = True avoids building some large modules like
evolution speeding the build. But more importantly, it removes
gnome-disk-utility from the build. gnome-disk-utility has a hard
dependency on udisks-1.99, which is not found on anything but the
latest systems.
https://bugzilla.gnome.org/show_bug.cgi?id=685353
