| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
|
| |\| | | | | |
|
| | | | | | | |
|
| | |/ / / / |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Fixes build on staging-next.
|
| |\| | | | |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
Xfce updates 2023-11-01
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
https://gitlab.xfce.org/thunar-plugins/thunar-archive-plugin/-/compare/thunar-archive-plugin-0.5.1...thunar-archive-plugin-0.5.2
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
https://gitlab.xfce.org/xfce/xfconf/-/compare/xfconf-4.18.2...xfconf-4.18.3
|
| |\| | | | | |
|
| | |/ / / / |
|
| |\| | | | |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
xfce.xfconf: fix xfwm4 segfaults after update to 4.18.2
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
xfconf 4.18.2 suffers a bug in its cache
handling that causes regular segfaults in xfwm:
https://gitlab.xfce.org/xfce/xfconf/-/issues/35
The commit at hand introduces a patch
which will also be part of the next relese.
|
| |\| | | | |
| |_|_|/ /
|/| | | | |
|
| | | | | | |
|
| |\| | | | |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
pantheon-tweaks: 1.1.0 -> 1.1.1
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
https://github.com/pantheon-tweaks/pantheon-tweaks/compare/1.1.0...1.1.1
|
| |\| | | | | |
|
| | |\ \ \ \ \
| | |_|/ / /
| |/| | | | |
xfce.thunar: 4.18.7 -> 4.18.8
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
https://gitlab.xfce.org/xfce/thunar/-/compare/thunar-4.18.7...thunar-4.18.8
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
|
| | |\ \ \ \ \
| | | |/ / /
| | |/| | | |
|
| | |\ \ \ \ \ |
|
| | |\ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \
| | | |_|_|_|_|_|/
| | |/| | | | | | |
|
| | |\ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
Conflicts:
pkgs/top-level/linux-kernels.nix
|
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
When specifying the `builder` attribute in `stdenv.mkDerivation`, this
will be effectively transformed into
builtins.derivation {
builder = stdenv.shell;
args = [ "-e" builder ];
}
This also means that `default-builder.sh` is never sourced and as a
result it's not guaranteed that `$NIX_ATTRS_SH_FILE` is set to a correct
location[1].
Also, we need to source `.attrs.sh` to source `$stdenv`. So, the
following is done now:
* If `$NIX_ATTRS_SH_FILE` points to a correct location, then use it.
Directly using `.attrs.sh` is problematic for `nix-shell(1)` usage
(see previous commit for more context), so prefer the environment
variable if possible.
* Otherwise, if `.attrs.sh` exists, then use it. See [1] for when this
can happen.
* If neither applies, it can be assumed that `__structuredAttrs` is
turned off and thus nothing needs to be done.
[1] It's possible that it doesn't exist at all - in case of Nix 2.3 or
it can point to a wrong location on older Nix versions with a bug in
`__structuredAttrs`.
|
| | | | | | | | | | | | | | | | | | | | | | | |
|