We don't need to pin the package version from hackage anywhere anymore
since stackage-nightly has arrived at the version we want. The
tasty-discover override is still necessary, but can be applied to the
plain hnix-store-core attribute.
Since the hnix-store-core_0_4_1_0 attribute no longer exists a few
intermittent eval errors where caused by the package set regeneration.
Usually we ensure using the mapAttrs call wrapping the license set that
every license has an associated shortName. A change related to legacy
aliases most likely introduced the removal of the shortName attribute
for all the legacy license names by splitting the set into two sets
connected by a record update operator -- leading to mapAttrs only
affecting the first set.
Since it used to be a valid assumption to have that every license had a
shortName attribute, we reintroduce this attribute for the legacy
aliases as well.
My understanding of the line that is removed is, that the logic is
wrong. According to the setup.py file[0] it says that:
> To exclude certain options in the cmake config use --no:
> for example:
> --no USE_AVX_INSTRUCTIONS: will set -DUSE_AVX_INSTRUCTIONS=no
This means, that a true value of `avxSupport` will deactivate it in the
setup, which is not what we want.
[0]: https://github.com/davisking/dlib/blob/v19.21/setup.py#L22
The BGRT theme is probably a close as to "FlickerFree" we can
get without https://github.com/NixOS/nixpkgs/pull/74842.
It's more agnostic than the Breeze theme.
We also install all of themes provided by the packages, as it's possible
that one theme needs the ImageDir of another, and they're small files
anyways.
Lastly, how plymouth handles logo and header files is
a total mess, so hopefully when they have an actual release
we won't need to do all this symlinking.
A vulnerability was discovered in how wpa_supplicant processes P2P
(Wi-Fi Direct) provision discovery requests. Under a corner case
condition, an invalid Provision Discovery Request frame could end up
reaching a state where the oldest peer entry needs to be removed. With
a suitably constructed invalid frame, this could result in use
(read+write) of freed memory. This can result in an attacker within
radio range of the device running P2P discovery being able to cause
unexpected behavior, including termination of the wpa_supplicant process
and potentially code execution.
https://w1.fi/security/2021-1/
nick black