The output file is found and handled by thelounge itself [1], leaving
the user free to override THELOUNGE_HOME in the environment if they
choose, but having a sensible default to make `thelounge` generally
usable in most cases.
This solution follows discussion on #70318.
[1] 9ef5c6c67e/src/command-line/utils.js (L56)
gappsWrapperArgsHook tries to collect GI_TYPELIB_PATH environment variable so if we want it to see the path giDiscoverSelf adds, we need to force the order.
Also passthrough the meta of the package to have description,
homepage, license, maintainers and other metadata passed through to
the commonly used attribute.
With the default configuration, the libraries are generated with a
-2_4.24.dylib suffix, and linking with -l...-2_4 doesn't work. Pass
the configure option to turn off the suffix.
Instead of using two different php packages in php-packages.nix, one
wrapper and one unwrapped, simply use the wrapper and use its
"unwrapped" attribute when necessary. Also, get rid of the packages
and extensions attributes from the base package, since they're no
longer needed.
Since the introduction of php.unwrapped there's no real need for the
phpXXbase attributes, so let's remove them to lessen potential
confusion and clutter. Also update the docs to make it clear how to
get hold of an unwrapped PHP if needed.
The old `CC=.. CXX= .. meson ...` env var hack I removed in
3c00ca03a2 had a side effect of ensuring
that Meson always had access to a native C compiler, which unforunately
it expects in most cases. Thankfully, that will be fixed soon.
"Real" xcodebuild allows using `xcodebuild -version -sdk` without
an sdk version argument, which will dump sdk info for all the
installed sdks.
Bazel"s "xcode cc toolchain setup on mac" process uses this
to determine which SDK version is actually installed. This
change allows using a nix-supplied pinned compiler and build
system under bazel.
* treewide Drop unneeded go 1.12 overrides
* Fix packr to be go module compatible.
I updated to version 2.8.0 which is the latest on master.
Then due to the 2 different sets of go modules which are used, I split
the build into two different derivations, then merged them togethor
using symlinkJoin to have the same output structure as the existing derivation.
* Remove consul dependency on go1.12
I updated the consul version to 1.7.2 and flipped it to building using
modules.
* Remove go1.12 from perkeep.
Update the version to the latest unstable on master.
* Update scaleway-cli to not be pinned to go1.12
Switched the version to 1.20
* Update prometheus-varnish-exporter to not depend on go1.12
* Update lnd to build with go1.12
Updated the version
Forced only building subpackages with main to prevent panics over
multiple modules in one repo
* Remove go1.12 from openshift
Had to update the version to 4.1.0 and do a bit of munging to get this
to work
* Remove go1.12 completely.
These are no longer needed.
* Update bazel-watcher and make it build with go 1.14
It appears that the autotools based build isn't supported on Darwin.
Just use the stdenv-builtin cmake build everywhere, as it works just
fine and is simpler.
The gstreamer plugin provides support for additional common
file/tagging formats like id3 tags in mp3 files. In addition, it
e.g. exposes more tags than the FLAC plugin for FLAC files.
Increase of closure size: 86.71 MB (52.8%)
Fixes: CVE-2020-12243
In filter.c in slapd in OpenLDAP before 2.4.50, LDAP search filters
with nested boolean expressions can result in denial of service
(daemon crash).
The cross file is added in the `mkDerivation`. It isn't nice putting
build tool-specific stuff here, but our current architecture gives us
little alternative.
See comment in code and the PR it references,
https://github.com/mesonbuild/meson/pull/6827, for details.
We can remove entries from the cross file because they will be gotten
from env vars now.
From the release notes:
* Require OCaml 4.03 and handle stdlib deprecations.
* Drop result depency.
* Drop ocb-stubblr dependency
The library has also been re-licensed from BSD3 to ISC.
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.
