Turns out lot of software (including Chromium) use bundled fontconfig
so we either need to wrap every one of those, or re-introduce the global unversioned config.
The latter is easier but weakens hermetic configs. But perhaps those are not really worth the effort.
Meson allows projects to set `build_rpath` property, containing paths
that will be added during build but will be removed when installing.
When Meson removes build_rpath from `DT_RUNPATH` entry, it just writes
the shorter ␀-terminated new rpath over the old one to reduce
the risk of potentially breaking the ELF files
(when the linker does string de-duplication or something).
But this can cause much bigger problem for Nix, as it can produce
cut-in-half-by-␀ store path references.
For example, in systemd’s libudev, it was removing three `$ORIGIN`-relative paths from
$ORIGIN/../libsystemd:$ORIGIN/../basic:$ORIGIN/../shared:…␀
resulting in the following `DT_RUNPATH` entry:
…␀store/v589pqjhvxrj73g3r0xb41yr84z5pwb7-gcc-9.3.0-lib/lib␀
We previously handled this in `fix-rpath.patch` but the method we prevent
Meson from removing paths added to rpath through `NIX_LDFLAGS` was changed
during 0.55.0 update and I forgot about this second purpose of the patch.
Let’s re-add this clearing code, as it worked without issues for a long time.
Meson allows projects to set `build_rpath` property, containing paths
that will be added during build but will be removed when installing.
When Meson removes build_rpath from `DT_RUNPATH` entry, it just writes
the shorter ␀-terminated new rpath over the old one to reduce
the risk of potentially breaking the ELF files
(when the linker does string de-duplication or something).
But this can cause much bigger problem for Nix, as it can produce
cut-in-half-by-␀ store path references.
For example, in systemd’s libudev, it was removing three `$ORIGIN`-relative paths from
$ORIGIN/../libsystemd:$ORIGIN/../basic:$ORIGIN/../shared:…␀
resulting in the following `DT_RUNPATH` entry:
…␀store/v589pqjhvxrj73g3r0xb41yr84z5pwb7-gcc-9.3.0-lib/lib␀
We previously handled this in `fix-rpath.patch` but the method we prevent
Meson from removing paths added to rpath through `NIX_LDFLAGS` was changed
during 0.55.0 update and I forgot about this second purpose of the patch.
Let’s re-add this clearing code, as it worked without issues for a long time.
This was omitted in the latest update.
Only adds ~400 KB.
It required adding openssl to tests so I tacked on some cleanups.
In particular, the GI_TYPELIB_PATH was already being set in the wrapper
so we can remove it from the module (not sure why Gtk was even there).
Also switched away from using pkgconfig and docbook_xsl aliases
and reordered the expression a bit.
Flatpak’s installed tests build Flatpak runtimes, among other things.
Upstream code does this by copying some programs on `PATH`
as well as some possible dependencies from host’s /usr.
We patch the code to use `nix-store --query --requisites`
to make the dependency discovery easier.
The Flatpak’s installed tests add `socat` to `PATH` and later run
`nix-store --query --requisites` on its location but it was failing with
error: path '/nix/store/qcyf7nq5vvfw32967sv4j6z190inrbrc-socat-1.7.3.4' is not valid
The issue occurred because, while the host Nix store is bind mounted into the test VM,
the VM’s store uses its own database that only contains the packages in the VM’s closure.
Since the test commands are not actually part of the VM but only passed through PTY,
the `flatpak.installedTests` derivation was not part of the VM’s closure, so `nix-store`
in the VM could not get information about its dependency `socat`.
Let’s make the `installedTests` of the tested package part of the test VM’s closure
by passing it as a global environment variable. This will also have the added benefit
that user no longer has to type the path when running the installed tests manually in the VM;
they can just use `gnome-desktop-testing-runner -d $TESTED_PACKAGE_INSTALLED_TESTS`,
which is much more conducive to tab completion.
* Update: https://gitlab.freedesktop.org/pwithnall/malcontent/-/releases/0.8.0
* Fix the separation patch.
* Add `itstool` to ui (needed for building localized help).
* Use `pkg-config` instead of the `pkgconfig` alias.
* Fix some issues related to multiple outputs:
* Make the module pass specific output to `dbus.packages` since the `dbus` NixOS module will not generate configuration with correct interface paths otherwise.
* Change `malcontent-ui` package to primarily-a-program type derivation (`out`+`lib` instead of `bin`+`out`) since there are more and more `malcontent-control`-specific assets.
* This also fixes the issue where application data (desktop files, icons…) were installed to `out`, which is not installed by `environment.systemPackages`/`system-path.nix`’s `buildEnv` by default when `bin` output is also present.
* Make `malcontent` package install `out` output too so that `system-path.nix` links that too. It contains the AccountsService & Polkit data files.
* Split the library and PAM module out of `malcontent.out` so that they are not installed with the data files.
* This revealed a bug in the `gobject-introspection` setup hook.
* Fix regression on PS conversion.
Regression only happened on applications that are locale enabled
i.e. Okular but not pdftops, when using a quite new lcms and
the user locale uses , as decimal separator instead of .
* Add UTF16LE support to TextStringToUCS4.
Even if the standard clearly says it should be UTF16BE
The docdir flag needs to include `PROJECT_NAME` according to [GNU guidelines]. We are passing
`-DCMAKE_INSTALL_DOCDIR=${!outputDoc}/share/doc/${shareDocName}` but `$shareDocName` was unset.
The `multiple-outputs.sh` setup hook actually only defines `shareDocName` as a local variable
so it was not available for cmake setup hook. Making it global would be of limited usability,
since it primarily tries to extract the project name from configure script.
Additionally, it would not be set because the setup hook defines `setOutputFlags=`,
preventing the function defining `shareDocName` from running. And lastly, the function
would not run for single-output derivations.
Previously, we tried [not disabling `setOutputFlags`] and passing the directory flags
only for multi-output derivations that do not disable `setOutputFlags` but that meant having
two different branches of code, making it harder to check correctness. The multi-output
one did in fact not work due to aforementioned undefined `shareDocName`. It also broke
derivations that set `setOutputFlags=` like [`qtModule` function does] (probably
because some Qt modules have configure scripts incompatible with `configureFlags` defined
by `multiple-outputs.sh` setup hook). For that reason, it was [reverted], putting us back to start.
Let’s try to extract the project name from CMake in the cmake setup hook.
CMake has a `-L` flag for dumping variables but `PROJECT_NAME` did not seem to be among them
when I tested, so I had to resort to parsing the `CMakeLists.txt` file.
The extraction function is limited, it does not deal with
* project name on different line from the `project(` command opening
- that will just not get matched so we will fall back to
using the derivation name
* variable interpolation
- we will just fall back to using derivation name when the extracted
`project_name` contains a dollar character
* multiple [`project`] commands
- The command sets `PROJECT_NAME` variable anew with each call, so the
last `project` call before `include(GNUInstallDirs)` command will be used
when the included module would [cache the `CMAKE_INSTALL_DOCDIR` variable].
We will just take the first discovered `project` command for simplicity.
Hopefully, there are not many projects that use multiple `project` calls
before including `GNUInstallDirs`.
In either case, we will have some subdirectory so the conflicts will be minimized.
[GNU guidelines]: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#index-docdir
[not disabling `setOutputFlags`]: https://github.com/NixOS/nixpkgs/commit/be1b22538a60e52987d238bb11f93043682b6e9a
[`qtModule` function does]: https://github.com/NixOS/nixpkgs/pull/12740
[reverted]: https://github.com/NixOS/nixpkgs/pull/92298
[`PROJECT_NAME`]: https://cmake.org/cmake/help/v3.18/variable/PROJECT_NAME.html
[`project`]: https://cmake.org/cmake/help/v3.18/command/project.html
[cache the `CMAKE_INSTALL_DOCDIR` variable]: https://github.com/Kitware/CMake/blob/92e30d576d66ac05254bba0f0ff7d655947beb0f/Modules/GNUInstallDirs.cmake#L298-L299
It is not linked against so there is no need to include it in build inputs, much less propagate it.
This removes systemd.dev from the runtime closure of packages using pyudev.
ITS rules are used for extracting translatable strings and they have
been moved to external files in 2.13.92 so they are not needed in
the config files themselves.
Removing them also cuts down on errors/warnings produced when using
older versions of fontconfig (< 2.12.92). Now it will only complain
about the description element but that is fortunately just a warning,
not errors like the ones caused by the its attributes.
Thanks to this, we can change the config version in NixOS module
back to 2.11 allowing us to re-use the 2.13/2.14 configs for apps
built against 2.12 fontconfig.
With previous patch, we no longer load non-versioned fonts.conf file to avoid incompatibilities
but this also means fontconfig will not load system-wide installed fonts on non-NixOS systems.
As a compromise, let's hardcode the FHS font paths to the built-in config so that the system
fonts work there. Unlike with the system config we do not need to worry about compatibility as
incompatible font files will be simply ignored.
Of course there will still be disparity if the system install fonts to some other location than
these two but I am afraid this is the best we can do.
See https://github.com/NixOS/nixpkgs/pull/73795#issuecomment-635771967 for discussion.
Falling back to unversioned `/etc/fonts/conf.d` when versioned one does not exist
is problematic since it only occurs on non-NixOS systems and those are likely
to have a different version of fontconfig. When those versions use incompatible
elements in the config, apps using fontconfig will crash.
Instead, we are now falling back to the in-package `fonts.conf` file that loads
both the versioned global `conf.d` directory and the in-package `conf.d` since using
upstream settings on non-NixOS is preferable to not being able to use apps there.
In fact, we would not even need to link `fonts.conf`, as the in-package `fonts.conf`
will be always used unless someone creates the global one manually (the option is still
retained if one wants to write a custom NixOS module and to avoid unnecessary stat call on NixOS).
Additionally, since the `fonts.conf` will always load `conf.d` from the package, we no longer
need to install them to sytem `/etc` in the module. This needed some mucking with `50-user.conf`
which disables configs in user directories (a good thing IMO, NixOS module will turn it back on)
but otherwise, it is cleaner. The files are still prioritized by their name, regardless of their location.
See https://github.com/NixOS/nixpkgs/pull/73795#issuecomment-634370125 for more information.
systemd complains:
Jul 08 12:43:59 kaiser systemd[1]: /nix/store/bvfikb8v9m646m23fqm0rfnnsj6plc2k-libvirt-6.2.0/lib/systemd/system/libvirtd-admin.socket:11: ListenStream= references a path below legacy directory /var/run/, updating /var/run/libvirt/libvirt-admin-sock → /run/libvirt/libvirt-admin-sock; please update the unit file accordingly.
Jul 08 12:43:59 kaiser systemd[1]: /nix/store/bvfikb8v9m646m23fqm0rfnnsj6plc2k-libvirt-6.2.0/lib/systemd/system/libvirtd-ro.socket:11: ListenStream= references a path below legacy directory /var/run/, updating /var/run/libvirt/libvirt-sock-ro → /run/libvirt/libvirt-sock-ro; please update the unit file accordingly.
Jul 08 12:43:59 kaiser systemd[1]: /nix/store/bvfikb8v9m646m23fqm0rfnnsj6plc2k-libvirt-6.2.0/lib/systemd/system/libvirtd.socket:9: ListenStream= references a path below legacy directory /var/run/, updating /var/run/libvirt/libvirt-sock → /run/libvirt/libvirt-sock; please update the unit file accordingly.
Let's just set it correctly manually, that is what Red Hat does:
https://gitlab.com/libvirt/libvirt/-/commit/ba7592f6c17d50435582e597727fbfc51322d606
See also:
https://gitlab.com/libvirt/libvirt/-/commit/390997925a3aca1b57969526c3e083761fafe7c3
* Format with nixpkgs-format.
* Reorder the attribute to be more in line with convention.
* Use simpler git ref.
* Hardcode paths within bindings using patch (the replaced value actually changed in this version and without this clean-up, it would have gone unnoticed.)
* Let the build script install the python bindings instead of doing it manually (required the same hardcoding as above in the setup.py.)
* Use cmakeFlags attribute with placeholder instead of doing that in preConfigure.
* Move udev rules to lib since etc is meant for admins.
* License is actually lgpl2.1+.
This reverts commit be1b22538a.
The commit broke Qt modules using CMake because they disable setOutputFlags.
There is no need to have these flags limited to multiple output derivations since it
should just work. If it does not, it is a bug that should be fixed as per
https://github.com/jtojnar/cmake-snips#assuming-cmake_install_dir-is-relative-path
Likewise, having a variable to disable passing the flags is also unnecessary,
since CMake, unlike some configure scripts, ignores unknown flags. And if a person
does not like the values, they can just override them by passing the offending
flag with a different value to cmakeFlags.
In https://github.com/NixOS/nixpkgs/commit/be1b22538a60e52987d238bb11f93043682b6e9a,
CMake setup-hook started to respect setOutputFlags. Since qtModule disables it by default,
cmake no longer received the multiple-output adjusted installation directory flags when
building the qtwebkit package. This resulted in incorrect paths in generated pkg-config files
and CMake config files.
Let’s temporarily enable setOutputFlags in the qtwebkit expression, until the commit is reverted.
The E (extension) line in pygimp.interp prints the following warnings:
GIMP-Warning: Bad interpreter referenced in interpreter file /nix/store/5c91dah385gn70blsn6i5rzncqj3ks0y-gimp-with-plugins-2.10.18/lib/gimp/2.0/interpreters/pygimp.interp: python2
GIMP-Warning: Bad binary format string in interpreter file /nix/store/5c91dah385gn70blsn6i5rzncqj3ks0y-gimp-with-plugins-2.10.18/lib/gimp/2.0/interpreters/pygimp.interp
This means that the py extension will not be registered when python2 is not in PATH. To prevent this, let’s hardcode the absolute python2 path.
https://github.com/NixOS/nixpkgs/issues/60937#issuecomment-653652093
Closes: https://github.com/NixOS/nixpkgs/issues/60937
GIMP uses python interpreter specified in pygimp.interp file for running Python plug-ins,
so any Python related wrapping is useless. It will pick up and use the python from build PATH.
Let’s use a python environment containing pygtk, which is needed by many plug-ins.
Closes: https://github.com/NixOS/nixpkgs/issues/87883
Jan Tojnar