The clickhouse program links to LLVM and to the clickhouse library, that also
links to LLVM. When the library is shared but LLVM is static, LLVM gets linked
into the program twice (once via the library and once directly), which causes
this error when running clickhouse:
: CommandLine Error: Option 'x86-use-base-pointer' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
A common LLVM installation provides static component libraries and a shared
libLLVM. Linking to libLLVM when libclickhouse is shared solves this issue.
Upstream pull request: https://github.com/yandex/ClickHouse/pull/3989
Symlinking works for most plugins and themes, but Avada, for instance, fails to
understand the symlink, causing its file path stripping to fail. This results in
requests that look like:
https://example.com/wp-content//nix/store/...plugin/path/some-file.js
Since hard linking directories is not allowed, copying is the next best thing.
I now no longer use an nvidia card commonly, so it would be harder for
me to test at least a bit. And I'm overcommited anyway.
Hopefully someone else can be found.
This makes it possible to swap out the (wrapped) neovim without
recompiling neovim-qt. In particular, the user can use `neovim.override`
to configure their neovim and then use that same configuration for
neovim-qt, without having to give up binary caching.
Runtime doesn't work:
ModuleNotFoundError: No module named 'PyQt5.QtWebEngineWidgets'
This is probably because qtwebengine is broken on darwin, but doesn't
fail the build (#40149)
The package doesn't exist anymore (even the deprecation notice is gone
[0]) and the build is currently broken:
Collecting google-apputils==0.4.1 (from gcutil==1.16.1)
Could not find a version that satisfies the requirement
google-apputils==0.4.1 (from gcutil==1.16.1) (from versions: )
No matching distribution found for google-apputils==0.4.1 (from
gcutil==1.16.1)
[0]: https://download.huihoo.com/google/gdgdevkit/DVD1/developers.google.com/compute/docs/gcutil.1.html
> "Warning: gcutil is deprecated. We encourage you to transition to
> using gcloud compute ."
Hydra has been trying to build it on aarch64-linux, but never succeeded:
https://hydra.nixos.org/job/nixpkgs/trunk/obs-studio.aarch64-linux/all
(It tries to feed compiler x86-specific options.)
I didn't test i686-linux, due to a transitive dependency not building
(libupnp), but there it might likely work.
PyPI links to a source tarball at PythonHosted that has an empty
ldap3/protocol/sasl/digestMd5.py
while the linked egg file has a non-empty file (and the upstream GitHub
repository has a non-empty file that hasn't even had a non-comment
change for some time.
