These .desktop files set InitialPreference>1 which will override other
associations even the .desktop appears first in XDG_DATA_DIRS. This
applies to:
- org.kde.kate.desktop
- org.kde.kwrite.desktop
- kfmclient_html.desktop
- okularApplication_txt.desktop
Fixes#86137
Until recently, libusb-compat propagated libusb1 and many packages unknowingly used it to obtain libusb1.
When https://github.com/NixOS/nixpkgs/pull/82944 removed this evil propagation, it broke many packages with such incorrect assumption.
This patch trades the breakage of packages wanting libusb1 caused by the PR for a hopefully less common breakage of the packages relying on the compat library.
It was added in 4d7cc55344
without any rationale. python2.pkgs.nxt-python seems to build without it.
Maybe it for some reason uses the libusb-0.1 backend but propagating the compat library would not enable that.
The text is quite long and hard to read in hub (because it is one whole line
with no line breaks). Also simplified the language/sentence structure a bit for
non-native speakers.
https://github.com/fish-shell/fish-shell/compare/3.1.0...3.1.1
The patch we had to use for Apple SDKs was merged upstream, so it can be
dropped. I ran nixpkgs-fmt, and removed the `with stdenv.lib;` scope
expander.
Additionally, did a little bit of cleanup. I plan on refactoring this
more down the line, but this'll do for now.
I finally figured out why we use `fetchurl` for the tagged release: the
published release tarballs contain a version file, which the
`build_tools/git_version_gen.sh` script reads (and uses as the version
if it exists). The other thing it contains are pre-generated docs for
various `fish` builtins. I've expanded the comment to document this so
nobody is as confused as I was when I first saw it. (Though I plan to
change this and add sphinx as a native build input in order to build the
docs ourselves.)
The only reason to pass build inputs is to extend the unpackPhase with
custom unpack commands. Eg: add "unrar" to unpack rar sources. And those
should really be passed as native build inputs. Why? Because
nativeBuildInputs is for dependencies that are used at build time but
will not propagate as runtime dependencies. And also, cross-compilation.