webify needs a bump in the cabal file. As the last upstream commit is
two years ago, I think it makes sense to not wait for upstream to merge
the PR [0] and release a new version.
[0] https://github.com/ananthakumaran/webify/pull/27
This is an backward incompatible change from upstream dhcpcd [0], as
this could have easily locked me out of my box.
As dhcpcd doesn't allow to use only a blacklist (denyinterfaces in
dhcpcd.conf) of devices and use all remaining devices, while explicitly
allowing some interfaces like bridges, I think the best option would be
to not change anything about it and just educate the users here about
that edge case and how to solve it.
[0] https://roy.marples.name/archives/dhcpcd-discuss/0002621.html
(cherry picked from commit eeeb2bf8035b309a636d596de6a3b1d52ca427b1)
- Init libuninameslist at 20190701 as it is a new dependency to fontforge
- Remove gnulib, as it is not used anymore
- Remove a non-applying patch
- Add myself as maintainer
This fixes a regression from bb649d96b0.
There were permission problems, when the preStart script tried to copy
the smokeping.fcgi file over the old file.
This is essentially the same as done in
65f2b0a2a3.
For spidermonkey_38 I set --enable-posix-nspr-emulation, as it would
otherwise complain about a wrong NSPR version and that trick seemed to
be successful in spidermonkey_60 anyway.
In case of the gem type 'git', nix-bundle-install.rb was called with
wrong path to the git checkout.
${src} does contain the sources, but not the newly generated .git dir,
which is created in the buildPhase of pkgs/development/ruby-modules/gem/default.nix
In some rare cases, this .git dir is needed at installPhase.
tlslite has a test failure on Python 3.7 [0]. @tomato42, a commiter of
tlslite and author of tlslite-ng said, that tlslite is abandoned (last
commit 2015) and tlslite-ng should be used as a drop in replacement.
[0] https://github.com/trevp/tlslite/issues/121
By setting useRealVendorConfig explicitly to true, the actual (slightly
modified) config generated by cargo-vendor is used.
This solves a problem, where the static vendor config in
pkgs/build-support/rust/default.nix would not sufficiently replace all
crates Cargo is looking for.
As useRealVendorConfig (and writeVendorConfig in fetchcargo) default to
false, there should be no breakage in existing cargoSha256 hashes.
Nethertheless, imho using this new feature should become standard. A
possible deprecation path could be:
- introduce this patch
- set useRealVendorConfig explicitly to false whereever cargoSha256 is
set but migration is not wanted yet.
- after some time, let writeVendorConfig default to true
- when useRealVendorConfig is true everywhere cargoSha256 is set and
enough time is passed, `assert cargoVendorDir == null ->
useRealVendorConfig;`, remove old behaviour
- after some time, remove all appearences of useRealVendorConfig and the
parameter itself
From the release notes [1]:
* Fix a vulnerability caused by Cross-Origin Resource Sharing (CORS)
in the JSONRPC interface. Previous versions of Electrum are
vulnerable to port scanning and deanonimization attacks from
malicious websites. Wallets that are not password-protected are
vulnerable to theft.
See this [2] for explanation.
[1] https://github.com/spesmilo/electrum/blob/3.0.4/RELEASE-NOTES
[2] https://github.com/spesmilo/electrum/issues/3374
Also moved the expression from python-packages.nix to ./pkgs/development/python-modules/future/default.nix due to discussion in #26220
Used fetchPypi insted of fetchurl.
Updated, as the old package is not compatible with current InfluxDB versions.
Changed buildInputs as following:
* requests -> requests2 as it is newer
* added dateutil as it is needed
* added tytz as it is needed
* added six as it is needed
Justin Humm