"bazel fetch" will, by default, fetch everything that _might_ be used,
including things that will later be discarded due to the way the build
is configured.
Concretely, this means that for some builds of Java packages, this will
avoid failures where the builder tries to retrieve the JDK from /usr/share/java
(or equivalent).
This also means that for most packages we can fetch _fewer_ dependencies,
since the standard tree pruning for artifacts to fetch will take effect.
fetchConfigured is disabled by default since it changes the fetch hashes
of tensorflow/tensorflow2 (since it ends up fetching less).
This change was preceded by the idea of adding a pronoun field to the
file, which we determined to be a bad idea:
* maintainers-list: add pronoun to the optional fields
I often do not know how to address maintainers, so giving them the
ability to specify their pronouns is helpful for communication
purposes.
* maintainers-list: add pronoun for Profpatsch
maintainers-list: make the pronoun field into a list
Some people have a set of pronouns they are fine with, so let’s make
that possible.
Based on feedback by somebody With An Idea™ of the topic.
* maintainers-list: remove the pronouns field
The discussion around the field raised a good point, quoting:
> What you are proposing here is keeping an irrevocable permanent
> history of people’s pronouns. It makes anybody would want to do bad
> things with it one small script away from a list of which Nixpkgs
> contributors are trans. Even looking at the history of name
> changes (which we probably also shouldn’t store) wouldn’t be nearly
> as reliable a source. While it might be tempting to say that
> participating in this would be optional, it would be establishing a
> de facto standard location for this information, that might make
> people feel compelled to participate or accept having the wrong
> pronoun used. Compounding this is the fact that the people who will
> be most comfortable using this field are the people who have never
> changed their pronouns. If they decide to in future, they now have
> to choose between permanently marking themselves as somebody who
> changed or deleted their pronouns (which is dangerous) or leaving
> the wrong pronouns up. Because of this, I think that over time this
> list would probably result in even more people being referred to by
> the wrong pronouns, because of outdated entries that are dangerous
> to correct.
>
> **This idea is extremely dangerous**. If somebody wants to publish
> their pronouns, they can already do that on their website or GitHub
> profile, without having to include that information in a large
> public dataset with history tracking.
So let’s remove it again.
Preserving existing behavior: the bash completion was not executable,
the zsh completion was; according to lukegb the fish completion does
not have to be executable.
###### Motivation for this change
Update to latest upstream version
###### Things done
* [ ] Tested using sandboxing ([nix.useSandbox](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option `sandbox` in [`nix.conf`](http://nixos.org/nix/manual/#sec-conf-file) on non-NixOS linux)
* Built on platform(s)
* [x] NixOS
* [ ] macOS
* [ ] other Linux distributions
* [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
* [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nix-review --run "nix-review wip"`
* [x] Tested execution of all binary files (usually in `./result/bin/`)
* [ ] Determined the impact on package closure size (by running `nix path-info -S` before and after)
* [ ] Ensured that relevant documentation is up to date
* [x] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
###### Notify maintainers
cc @blitz @Ma27 @tfc @worldofpeace
- Begin a new chapter "GPU Acceleration", this should also cover
VA-API, OpenGL, Vulkan, etc.
- Add a general blurb about OpenCL and how to check whether OpenCL
devices are found.
- Add a section about enabling OpenCL for AMD GPUs specifically.
This utility reports information about AMD GPUs that are supported by
the ROCm stack. It also exposes functionality for clock and
temperature management.
