Desktop files are only useful when accompanied by the binaries they
specify. So it makes more sense to put them next to the binaries rather
than `$out` which only usually contains the binaries.
Similar to the implementation of the `%f` and `%u` field codes. In this
case the amount of arguments passed poses no problem but the position
could, at least in theory.
This finishes the implementation of all the non-deprecated field codes.
As a part of that, repetitions of field codes are left alone. Originally
all field codes were removed. Now we replace only the first occurence.
This is correct for at least `%f`, `%u`, `%F` and `%U` because at most
one of them is permitted.
Shortcomings:
1. We replace `%[cfFikuU]` patterns one at a time. This means if the
right field code appears as part of the rest of the `Exec` field or
in a field code that was substituted earlier.
2. If any field code is repeated, only the first occurence is
substituted.
`%f` and `%u` are used to signal the program only accepts a single file
or URI argument. I do not believe there's a way to signal this
information to macOS but it is possible the program really won't work if
multiple files are passed and it's possible the relative position of
`%i`, `%c` or `%k` matters. So we replace `%f` or `%u` with `$1`. That
way we only pass one file in the (possibly significant) position of the
field code.
`ls -1 "$iconsdir/"*` listed the source directory for me when the glob
had no matches. Switching to `-A` circumvents this problem and has the
added advantage that it cannot run into argument list length limits.
Checked the desktop entry spec, there's other field codes than `%[fFuU]`
and those can in fact occur more than once, hence dropping '$' and
adding `/g`.
The "Exec" key in desktop items sometimes has one of the `%f`, `%F`,
`%u` and `%U` suffixes, which specify whether the command takes a file,
multiple files or a generalized URL or URLs. Darwin application bundles
do no understand this syntax so we do the next best thing, which is
simply dropping it.
Sometimes scalable icons or icons within the thresholds from the desired
resolutions aren't available. In this case it's still nicer to end up
with a blocky scaled icon rather than the generic default.
In order to compose a `.icns` file containing multiple icon sizes I had
to pass `--toc` to `icnsutil`. This did not seem to have a negative
effect on `.icns` containing only a single icon size.
On macOS 10.13 the 48x48 icon size is not supported. It results in a
corrupted image being displayed. I suspect the image data is being
truncated to what it expects for 32x32 or maybe data is read for
128x128, which would be a buffer overflow.
As discussed in https://github.com/NixOS/nixpkgs/issues/163590, it's not really required and has a side effect of adding refeferences to packages from nativeBuildInputs that aren't really required
- Convert icons to a single .icns file; and
- Provide an opt-out via X-macOS-Squircle in the desktop item to
override the squircle behavior when the source icons look bad when
converted automatically.
Disable file globbing in --prefix/--suffix, since bash will otherwise
try to find filenames matching the the value to be prefixed/suffixed
if it contains characters considered wildcards, such as `?` and
`*`. We want the value as is, except we also want to split it on on
the separator; hence we can't quote it.
* rewrite autoPatchelfHook in python
* Update pkgs/build-support/setup-hooks/auto-patchelf.py
Co-authored-by: aszlig <aszlig@redmoonstudios.org>
* Update pkgs/build-support/setup-hooks/auto-patchelf.py
Co-authored-by: aszlig <aszlig@redmoonstudios.org>
* Apply suggestions from code review
Co-authored-by: aszlig <aszlig@redmoonstudios.org>
* Fix issues discovered during tests
* Apply suggestions from code review
Co-authored-by: aszlig <aszlig@redmoonstudios.org>
* fixup line wrapping
* autoPatchelfHook: Improve compatibility with bash version
* autoPatchelfHook: Fix symlink-reated issues
* autoPatchelfHook: Revert dubious patchelf invocation test
* autoPatchelfHook: Untangle the executable detection logic
* fixup! autoPatchelfHook: Untangle the executable detection logic
* autoPatchelfHook: Fix invalid borrow issue
* autoPatchelfHook: Handle runtimeDependencies as the bare string it is
* autoPatchelfHook: add bintools dependency
For the very rare cases where it is not included by default.
* autoPatchelfHook: replace old hook with the rewrite
* autoPatchelfHook: get rid of the old hook content
* autoPatchelfHook: fix wrong ordering of debug info
* autoPatchelfHook: persist extra search path across incovations
* autoPatchelfHook: fix wrong usage of global variables
* Update auto-patchelf.py
PEP8: ignoreMissing -> ignore_missing
* Apply suggestions from code review
Co-authored-by: aszlig <aszlig@redmoonstudios.org>
* autoPatchelfHook: remove imprecise and incorrect warning
* Apply explicit types from code review
Co-authored-by: Jörg Thalheim <Mic92@users.noreply.github.com>
* Complement and polish types and snake_casing
Co-authored-by: aszlig <aszlig@redmoonstudios.org>
Co-authored-by: Jörg Thalheim <Mic92@users.noreply.github.com>
When prefixing or suffixing list variables, check that the value or
values aren't already part of the list. If this is the case when
suffixing, the list won't be touched at all. When prefixing, however,
the last matching instance of the value will be moved to the beginning
of the list. Any remaining duplicates of the value will be left as-is.
Co-authored-by: Vincenzo Mantova <xworld21@users.sf.net>
This is for symmetry with `--suffix-each`, and also because
(in my limited experience), `--prefix-each` is more useful since it
ensures that the new entries superseded the existing `PATH` entries
autoPatchelfHook actually doesn't depend on stdenv and only needs
bintools (with its wrapper). This change uses $NIX_BINTOOLS instead of
$NIX_CC and makes the dependency on bintools explicit.
Fully enabling crossSystem support for autoPatchelfHook came with some
perhaps unintended consequences of being a bit more aggressive about
patching ELF files from architectures/ABIs that differ from the target
(previously, those files would be ignored because ldd usually couldn't
handle them).
This change adds architecture and rough OS ABI detection to the script
so that it doesn't try to blindly replace the interpreter of files that
can't possibly use that interpreter, and also makes sure it doesn't
accidentally use libraries of other architectures/ABIs.
`--enable-deterministic-archives` is a GNU specific strip flag and
causes other strip implementations (for example LLVM's, see #138013)
to fail. Since strip failures are ignored, this means that stripping
doesn't work at all in certain situation (causing unnecessary
dependencies etc.).
To fix this, no longer pass `--enable-deterministic-archives`
unconditionally, but instead add it in a GNU binutils specific strip
wrapper only.
`commonStripFlags` was only used for this flag, so we can remove
it altogether.
Future work could be to make a generic strip wrapper, with support for
nix-support/strip-flags-{before,after} and NIX_STRIP_FLAGS_{BEFORE,AFTER}.
This possibly overkill and unnecessary though -- also with the
additional challenge of incorporating the darwin strip wrapper somehow.
In #84415, autoPatchelfHook was taught to use the correct path to the
readelf binary when a crossSystem is specified. Unfortunately, the
remainder of the functionality in the script depended on ldd, which only
reads ELF files of its own architecture. It has the further unfortunate
quality of not reporting any useful error, but rather that the file is
not a dynamic executable.
This change uses patchelf to directly analyze the DT_NEEDED tags in the
target files instead, which correctly works across architectures. It
also updates the use of objdump to be prefix-aware $OBJDUMP (which would
have been required in the PR mentioned above, but we never made it that
far into the script execution).
This caused shebangs that were already store paths to be rewritten.
Introduced by ab4c359822 in #94642
Example difference:
$ echo "hello world" | tail -c+3
llo world
$ str="hello world"; echo ${str:3}
lo world
Using the full store hash as the random seed occasionally caused
reference cycles when the invocation was stored in output artifacts.
For example, cross-compiled gcc was failing due to this:
https://hydra.nixos.org/eval/1631713#tabs-now-fail
Simply truncating the hash is sufficient to avoid this.
Use "find -exec" to strip rather than "find … | xargs …". The former
ensures that stripping is attempted for each file, whereas the latter
will stop stripping at the first failure. Unstripped files can fool
runtime dependency detection and bloat closure sizes.
For example graphviz has chained symlinked manpages: dot2gxl.1 is
a symlink to gv2gxl.1 which is a symlink to gxl2gv.1
The second loop replaces each non-compressed symlink to a compressed
symlink. The target is determined with 'readlink -f', which follows
links recursively until the first name that is not a link (so either
the 'target name' or the first 'dangling' symlink).
This means that if the loop converted dot2gxl.1 before converting
gv2gxl.1 it would add a symlink `dot2gxl.1.gz->gxl2gv.1.gz`. When
it converted gv2gxl.1 first, it would then add a
`dot2gxl.1.gz->gv2gxl.1.gz` symlink.
Both are 'correct', but it's weird the result depends on the order
in which 'find' returns the files. This PR makes the behaviour
deterministic.
fixes#104708
This adds -frandom-seed to each compiler invocation in stdenv. The
object here is to make the compierl invocations produce the same output
every time they are called (for the same derivation). When the
-frandom-seed option is not set the compiler will use a combination of
random numbers (in GCC's case from /dev/urandom) and the durrent time to
produce a "random" input per file. This can (among other things) lead to
different ordering of symbols in the produced object files.
For reason of reproducibility we prefer having the same derivation
produce the exact same outputs. This is not a silver bullet but one way
to tame the compiler.
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
Teach installShellCompletion how to install completions from a named
pipe. Also add a convenience flag `--cmd NAME` that synthesizes the name
for each completion instead of requiring repeated `--name` flags.
Usage looks something like
installShellCompletion --cmd foobar \
--bash <($out/bin/foobar --bash-completion) \
--fish <($out/bin/foobar --fish-completion) \
--zsh <($out/bin/foobar --zsh-completion)
Fixes#83284
This hook moves systemd user service file from `lib/systemd/user` to
`share/systemd/user`. This is to allow systemd to find the user
services when installed into a user profile. The `lib/systemd/user`
path does not work since `lib` is not in `XDG_DATA_DIRS`.
This is supposed to shareDocName to a fallback value if it can't be
determined from looking at the configure script. But the conditional
checked whether shareDocName was set, rather than if it wasn't. This
meant that if shareDocName had been detected from a configure script,
it would be immediately overridden by the package name, and if it
couldn't be detected, shareDocName would remain unset.
This resulted in QEMU installing files like $out/share/doc/index.html,
which should of course have been in $out/share/doc/qemu/index.html.
An interesting side effect of this is that, since
9f8751528c when this code was added, the
detected package name has never actually been used for installing
documentation, because it would always be overridden. So this patch
will actually enable that for the first time, four years later.
Fixes: https://github.com/NixOS/nixpkgs/issues/90486
This adds the `validatePkgConfig` hook, which can be used to validate
pkg-config files in the output(s). Currently, this will just run
`pkg-config --validate` on all `.pc` files, capturing errors such as
the issue that was fixed in #87789.
The hook could be extended in the future with more fine-grained
checks.
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
