Conversation
Nix modifies binaries after they are installed, which results in the wrong signature. There is no easy way to avoid these modifications, so the best fix is to simply regenerate the signatures after the fixup phase.
Qt QML is a language for designing user interfaces. QML (and related JavaScript) source files are compiled into bytecode at runtime before execution. To save time, this bytecode is cached on disk. The cache is keyed primarily off the application name and mtime of the source file. Since application names rarely change, source files that have passed through the store have their mtimes fixed at 1, and SOURCE_DATE_EPOCH is also set to 1 during builds, compiled bytecode in this cache for Qt programs built by Nix is rarely or never invalidated. This results in programs running with QML bytecode that does not match their source code, which manifests as a constant source of random and unreproducible glitches, oddities, and crashes in Qt applications when they are upgraded. For applications like SDDM and Plasma, the user may be left with a completely broken system, and sometimes even rolling back doesn't fix the issue. This patch resolves the issue by simply patching Qt's QML module in all supported versions to disable the disk cache by default as if the environment variable QML_DISABLE_DISK_CACHE were always 1. Patching the code ensures consistent behavior for all Qt applications in all environments, including non-NixOS uses. Simple benchmarking suggests an approximate 10% CPU time penalty when launching QML-heavy applications, and no measurable penalty to booting into Plasma. This is considerably more benign than the earlier behavior. For testing or the performance conscious, use of the cache can be re-enabled after understanding the risks by setting the environment variable QML_FORCE_DISK_CACHE to 1. This can be done system-wide using e.g. the `environment.sessionVariables` NixOS option. Future work could change the cache key through source code changes or automatic generation of an appropriate SOURCE_DATE_EPOCH. Until then, this is a simple change which removes a large class of user frustration and headache for little penalty.
https://gitlab.gnome.org/GNOME/glib/-/compare/2.74.0...2.74.1 - Docs no longer can be generated in static builds. - Drop merged patches. - Add a comment to an undocumented patch. - Drop huge with statement. - Drop meson override not needed since a4a300d Changelog-Reviewed-By: Jan Tojnar <jtojnar@gmail.com>
https://gitlab.gnome.org/GNOME/tracker/-/compare/3.4.0...3.4.1 Changelog-Reviewed-By: Jan Tojnar <jtojnar@gmail.com>
cc-wrapper: adding a cc-wrapper-hook to the cc-wrapper
python310Packages.build: 0.8.0 -> 0.9.0
python310Packages.psutil: 5.9.2 -> 5.9.3
More GNOME updates (staging)
...into staging-next
Member
Author
|
I see only one instance of the warning where *equality* of strings
is tested and char signedness differs. That one seems perfectly safe.
```
../libvirt-gconfig/libvirt-gconfig-domain-capabilities-os.c: In function 'search_firmwares':
../libvirt-gconfig/libvirt-gconfig-domain-capabilities-os.c:70:26: warning: pointer targets in passing argument 1 of 'strcmp' differ in signedness [-Wpointer-sign]
70 | if (!g_str_equal(node->name, "enum"))
/nix/store/fmqcm52w0p5jmzdbjjskwjiwyj9kqic9-glib-2.74.1-dev/include/glib-2.0/glib/ghash.h:165:39: note: in definition of macro 'g_str_equal'
165 | #define g_str_equal(v1, v2) (strcmp ((v1), (v2)) == 0)
| ^~
```
Member
Author
|
Nothing blocking here, I think: https://hydra.nixos.org/eval/1785087?compare=1785072 |
Thanks to bobby285271 for suggesting this patch.
github-actions
bot
added
the
6.topic: GNOME
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
https://hydra.nixos.org/job/nixpkgs/staging-next/unstable#tabs-constituents
https://hydra.nixos.org/job/nixos/staging-next-small/tested
https://hydra.nixos.org/jobset/nixpkgs/staging-next
https://hydra.nixos.org/jobset/nixos/staging-next-small
Note: this is the last
staging-nextthat will be in 22.11 and at the same time can contain breaking changes (but DEs have exception). You can see this in the schedule: #193585EDIT: note that another
staging-nextwithout breaking changes is planned afterwards.