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.
* Update to 4.4.2
4.4.0 increased the ZScript version number, GZDoom 4.4.1 and 4.4.2 have some bugfixes.
* Fix bad checksum
Old hash was done without `--unpack` option, resulting in a mismatch.
* Fetch submodules
This fixes the issue with `zmusic` not being brought in as a dependency.
* Add zmusic derivation
Since zmusic isn't actually a submodule, we have to derive it ourselves and pass it as a buildInput.
* Semicolon.
* Semicolon in the *right* place this time.
* Merge the zmusic source into the gzdoom source.
Apparently this is how they expect zmusic to be added. Why this isn't a submodule, I don't know.
* Fix bad path editing
Credit to Open Skies for fixing this. Turns out the paths edited in the `gzdoom` derivation were for zmusic, which needs these edits to be made so that it looks in nix-friendly places for its stuff.
The OpenCL compiler does not properly support -I flags to include the
kernel paths, breaking relative includes. Simply replace the included
files by absolute paths.
OpenCL kernels verified to compile and work on an RX 580.
Credits for the fix go to nixos-rocm.
