Qt links against GTK to be able to use native GTK file chooser
in GTK-oriented DEs. However, GTK expects a specific environment,
which means the application needs to be wrapped to prevent crashes
when file chooser is opened in some environments.
This patch bypasses the need for wrapping Qt applications with GTK-related
environment since the file chooser dialogue will now come from a separate
process (instantiated by the XDG desktop portal via D-Bus).
In the future, we could remove the GTK dependency from Qt to fix the crashes
on non-{GNOME,Pantheon} environments. Then, users would be able to choose
between non-native Qt dialogue or native one facilitated by XDG portals
(e.g. through setting `QT_QPA_PLATFORMTHEME` to either `qgnomeplatform`,
or `xdgdesktopportal`).
One disadvantage is adding a Qt dependency to GNOME, even for people
who might not use any Qt apps. But they can easily just add `qt5.enable = false;`
to their NixOS configuration.
The configuration is also presumably less battle tested than plain Qt
with its first-party GTK integration. But it is backed by Fedora
and used by Manjaro GNOME so it cannot be that bad.
Lastly, I worry about ABI compatibility of the platform modules
with apps installed from different Nixpkgs revision.
* nixos/airsonic: make path to war file and jre configurable
* Apply suggestions from code review
Co-authored-by: Sumner Evans <me@sumnerevans.com>
Co-authored-by: Sumner Evans <me@sumnerevans.com>
This error occurs if `nextcloud-occ maintenance:install` fails and the
`upgrade` command is attempted to be executed afterwards.
Due to the nature of the installer we can't do much about it, so I guess
it makes sense to add some notes about it. The other notes in the
`Pitfalls`-section are semantically a list of different topics, so I
changed that accordingly now.
Closes#111175
These are all packages that I stopped using and hence just create noise
in my inbox for each change affecting them and let's face it, while I
still enjoy contributing to nixpkgs, it doesn't really make sense to be
listed there if I can't do much anyways.
Each of these packages can be taken over by someone or removed if
people think that's reasonable.
Of course, if other maintainers face issues, I can answer some questions
if needed & possible.
This doesn't work anymore and thus breaks the installation leaving a
broken `/var/lib/nextcloud`.
It isn't a big deal since we set this value in the override config
before, so the correct table-prefix is still used. In order to confirm
that, I decided to add a custom prefix to the basic test.
Having a disks object with a dictionary of all the disks and their
properties makes it easier to process multi-disk images.
Note the rename of `label` to `system_label` is because `$label`i
is something of a special token to jq.
Introduce an AWS EC2 AMI which supports aarch64 and x86_64 with a ZFS
root.
This uses `make-zfs-image` which implies two EBS volumes are needed
inside EC2, one for boot, one for root. It should not matter which
is identified `xvda` and which is `xvdb`, though I have always
uploaded `boot` as `xvda`.
This is a private interface for internal NixOS use. It is similar
to `make-disk-image` except it is much more opinionated about what
kind of disk image it'll make.
Specifically, it will always create *two* disks:
1. a `boot` disk formatted with FAT in a hybrid GPT mode.
2. a `root` disk which is completely owned by a single zpool.
The partitioning and FAT decisions should make the resulting images
bootable under EFI or BIOS, with systemd-boot or grub.
The root disk's zpools options are highly customizable, including
fully customizable datasets and their options.
Because the boot disk and partition are highly opinionated, it is
expected that the `boot` disk will be mounted at `/boot`. It is
always labeled ESP even on BIOS boot systems.
In order for the datasets to be mounted properly, the `datasets`
passed in to `make-zfs-image` are turned in to NixOS configuration
stored at /etc/nixos/configuration.nix inside the VM.
NOTE: The function accepts a system configuration in the `config`
argument. The *caller* must manually configure the system
in `config` to have each specified `dataset` be represented
by a corresponding `fileSystems` entry.
One way to test the resulting images is with qemu:
```sh
boot=$(find ./result/ -name '*.boot.*');
root=$(find ./result/ -name '*.root.*');
echo '`Ctrl-a h` to get help on the monitor';
echo '`Ctrl-a x` to exit';
qemu-kvm \
-nographic \
-cpu max \
-m 16G \
-drive file=$boot,snapshot=on,index=0,media=disk \
-drive file=$root,snapshot=on,index=1,media=disk \
-boot c \
-net user \
-net nic \
-msg timestamp=on
```
The way `(lib.formats.yaml {}).generate` generates YAML is compliant
because on YAML 1.2 spec JSON is a subset of YAML but it bugs people's
minds and can lead to problems with software that is not compatible with
YAML 1.2.
This commit also changes the test of the generation function. Data
validation/typing remains the same.
See #133802.
Signed-off-by: lucasew <lucas59356@gmail.com>
This addresses #120263 in part, by allowing users to override the
github-runner derivation that is bound to turn non-functional via the
self-update mechanism. (And it'll allow using a buildFHSUserEnv-based
derivation, if someone ends up building that!)
Printers are usually connected over USB to serial interfaces that are
mounted as tty character devices owned by the dialout group. Add our
octoprint service to this group at runtime to allow access to these
printers.
5.7+ comes with a native exfat implementation, exfatprogs should be used instead.
The exfat package puts a "mount.exfat" binary in the path, which causes
mount to prefer the FUSE version to the non-fuse one. There's no way to
disable the binary, so switch to exfatprogs.
twisted is used in matrix-synapse for smtp handling.
Mostly this is used for password resets, but also notifications
are delivered that way.
older versions of twisted require the e-mail server to
have TLS1.0 enabled.
Obviously, quite a lot of servers have this disabled which means
synapse won't be able to deliver mails using such servers.
matrix-synapse issue:
https://github.com/matrix-org/synapse/issues/6211
