public/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge master into staging-next

Browse Source
This commit is contained in:
github-actions[bot] 2020-12-08 06:17:44 +00:00 committed by GitHub
commit e539b57990
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
47 changed files with 1094 additions and 913 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/Makefile
View File

@ -87,24 +87,12 @@ functions/library/generated: doc-support/result
ln -rfs ./doc-support/result/function-docs functions/library/generated
%.section.xml: %.section.md
pandoc $^ -w docbook \
pandoc $^ -t docbook \
-f markdown+smart \
| sed -e 's|<ulink url=|<link xlink:href=|' \
-e 's|</ulink>|</link>|' \
-e 's|<sect. id=|<section xml:id=|' \
-e 's|</sect[0-9]>|</section>|' \
-e '1s| id=| xml:id=|' \
-e '1s|\(<[^ ]* \)|\1xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" |' \
| cat > $@
%.chapter.xml: %.chapter.md
pandoc $^ -w docbook \
pandoc $^ -t docbook \
--top-level-division=chapter \
-f markdown+smart \
| sed -e 's|<ulink url=|<link xlink:href=|' \
-e 's|</ulink>|</link>|' \
-e 's|<sect. id=|<section xml:id=|' \
-e 's|</sect[0-9]>|</section>|' \
-e '1s| id=| xml:id=|' \
-e '1s|\(<[^ ]* \)|\1|' \
| cat > $@

198
doc/contributing/submitting-changes.chapter.md Normal file
View File

@ -0,0 +1,198 @@
# Submitting changes {#chap-submitting-changes}
## Making patches {#submitting-changes-making-patches}
- Read [Manual (How to write packages for Nix)](https://nixos.org/nixpkgs/manual/).
- Fork [the Nixpkgs repository](https://github.com/nixos/nixpkgs/) on GitHub.
- Create a branch for your future fix.
- You can make branch from a commit of your local `nixos-version`. That will help you to avoid additional local compilations. Because you will receive packages from binary cache. For example
```ShellSession
$ nixos-version --hash
0998212
$ git checkout 0998212
$ git checkout -b 'fix/pkg-name-update'
```
- Please avoid working directly on the `master` branch.
- Make commits of logical units.
- If you removed pkgs or made some major NixOS changes, write about it in the release notes for the next stable release. For example `nixos/doc/manual/release-notes/rl-2003.xml`.
- Check for unnecessary whitespace with `git diff --check` before committing.
- Format the commit in a following way:
```
(pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
Additional information.
```
- Examples:
- `nginx: init at 2.0.1`
- `firefox: 54.0.1 -> 55.0`
- `nixos/hydra: add bazBaz option`
- `nixos/nginx: refactor config generation`
- Test your changes. If you work with
- nixpkgs:
- update pkg
- `nix-env -i pkg-name -f <path to your local nixpkgs folder>`
- add pkg
- Make sure it’s in `pkgs/top-level/all-packages.nix`
- `nix-env -i pkg-name -f <path to your local nixpkgs folder>`
- _If you don’t want to install pkg in you profile_.
- `nix-build -A pkg-attribute-name <path to your local nixpkgs folder>/default.nix` and check results in the folder `result`. It will appear in the same directory where you did `nix-build`.
- If you did `nix-env -i pkg-name` you can do `nix-env -e pkg-name` to uninstall it from your system.
- NixOS and its modules:
- You can add new module to your NixOS configuration file (usually it’s `/etc/nixos/configuration.nix`). And do `sudo nixos-rebuild test -I nixpkgs=<path to your local nixpkgs folder> --fast`.
- If you have commits `pkg-name: oh, forgot to insert whitespace`: squash commits in this case. Use `git rebase -i`.
- [Rebase](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) your branch against current `master`.
## Submitting changes {#submitting-changes-submitting-changes}
- Push your changes to your fork of nixpkgs.
- Create the pull request
- Follow [the contribution guidelines](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md#submitting-changes).
## Submitting security fixes {#submitting-changes-submitting-security-fixes}
Security fixes are submitted in the same way as other changes and thus the same guidelines apply.
If the security fix comes in the form of a patch and a CVE is available, then the name of the patch should be the CVE identifier, so e.g. `CVE-2019-13636.patch` in the case of a patch that is included in the Nixpkgs tree. If a patch is fetched the name needs to be set as well, e.g.:
```nix
(fetchpatch {
name = "CVE-2019-11068.patch";
url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
})
```
If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch.
Critical security fixes may by-pass the staging branches and be delivered directly to release branches such as `master` and `release-*`.
## Pull Request Template {#submitting-changes-pull-request-template}
The pull request template helps determine what steps have been made for a contribution so far, and will help guide maintainers on the status of a change. The motivation section of the PR should include any extra details the title does not address and link any existing issues related to the pull request.
When a PR is created, it will be pre-populated with some checkboxes detailed below:
### Tested using sandboxing {#submitting-changes-tested-with-sandbox}
When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of `fetch*` functions and files outside the Nix store. Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see [sandbox](https://nixos.org/nix/manual/#conf-sandbox) in Nix manual for details.
Sandboxing is not enabled by default in Nix due to a small performance hit on each build. In pull requests for [nixpkgs](https://github.com/NixOS/nixpkgs/) people are asked to test builds with sandboxing enabled (see `Tested using sandboxing` in the pull request template) because in<https://nixos.org/hydra/> sandboxing is also used.
Depending if you use NixOS or other platforms you can use one of the following methods to enable sandboxing **before** building the package:
- **Globally enable sandboxing on NixOS**: add the following to `configuration.nix`
```nix
nix.useSandbox = true;
```
- **Globally enable sandboxing on non-NixOS platforms**: add the following to: `/etc/nix/nix.conf`
```ini
sandbox = true
```
### Built on platform(s) {#submitting-changes-platform-diversity}
Many Nix packages are designed to run on multiple platforms. As such, it’s important to let the maintainer know which platforms your changes have been tested on. It’s not always practical to test a change on all platforms, and is not required for a pull request to be merged. Only check the systems you tested the build on in this section.
### Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests) {#submitting-changes-nixos-tests}
Packages with automated tests are much more likely to be merged in a timely fashion because it doesn’t require as much manual testing by the maintainer to verify the functionality of the package. If there are existing tests for the package, they should be run to verify your changes do not break the tests. Tests only apply to packages with NixOS modules defined and can only be run on Linux. For more details on writing and running tests, see the [section in the NixOS manual](https://nixos.org/nixos/manual/index.html#sec-nixos-tests).
### Tested compilation of all pkgs that depend on this change using `nixpkgs-review` {#submitting-changes-tested-compilation}
If you are updating a package’s version, you can use nixpkgs-review to make sure all packages that depend on the updated package still compile correctly. The `nixpkgs-review` utility can look for and build all dependencies either based on uncommited changes with the `wip` option or specifying a github pull request number.
review changes from pull request number 12345:
```ShellSession
nix run nixpkgs.nixpkgs-review -c nixpkgs-review pr 12345
```
review uncommitted changes:
```ShellSession
nix run nixpkgs.nixpkgs-review -c nixpkgs-review wip
```
review changes from last commit:
```ShellSession
nix run nixpkgs.nixpkgs-review -c nixpkgs-review rev HEAD
```
### Tested execution of all binary files (usually in `./result/bin/`) {#submitting-changes-tested-execution}
It’s important to test any executables generated by a build when you change or create a package in nixpkgs. This can be done by looking in `./result/bin` and running any files in there, or at a minimum, the main executable for the package. For example, if you make a change to texlive, you probably would only check the binaries associated with the change you made rather than testing all of them.
### Meets Nixpkgs contribution standards {#submitting-changes-contribution-standards}
The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc\... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
## Hotfixing pull requests {#submitting-changes-hotfixing-pull-requests}
- Make the appropriate changes in you branch.
- Don’t create additional commits, do
- `git rebase -i`
- `git push --force` to your branch.
## Commit policy {#submitting-changes-commit-policy}
- Commits must be sufficiently tested before being merged, both for the master and staging branches.
- Hydra builds for master and staging should not be used as testing platform, it’s a build farm for changes that have been already tested.
- When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people’s installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from \@edolstra.
### Master branch {#submitting-changes-master-branch}
The `master` branch is the main development branch. It should only see non-breaking commits that do not cause mass rebuilds.
### Staging branch {#submitting-changes-staging-branch}
The `staging` branch is a development branch where mass-rebuilds go. It should only see non-breaking mass-rebuild commits. That means it is not to be used for testing, and changes must have been well tested already. If the branch is already in a broken state, please refrain from adding extra new breakages.
### Staging-next branch {#submitting-changes-staging-next-branch}
The `staging-next` branch is for stabilizing mass-rebuilds submitted to the `staging` branch prior to merging them into `master`. Mass-rebuilds should go via the `staging` branch. It should only see non-breaking commits that are fixing issues blocking it from being merged into the `master ` branch.
If the branch is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days and then merge into master.
### Stable release branches {#submitting-changes-stable-release-branches}
For cherry-picking a commit to a stable release branch (“backporting”), use `git cherry-pick -x <original commit>` so that the original commit id is included in the commit.
Add a reason for the backport by using `git cherry-pick -xe <original commit>` instead when it is not obvious from the original commit message. It is not needed when it's a minor version update that includes security and bug fixes but don't add new features or when the commit fixes an otherwise broken package.
Here is an example of a cherry-picked commit message with good reason description:
```
zfs: Keep trying root import until it works
Works around #11003.
(cherry picked from commit 98b213a11041af39b39473906b595290e2a4e2f9)
Reason: several people cannot boot with ZFS on NVMe
```
Other examples of reasons are:
- Previously the build would fail due to, e.g., `getaddrinfo` not being defined
- The previous download links were all broken
- Crash when starting on some X11 systems

455
doc/contributing/submitting-changes.xml
View File

@ -1,455 +0,0 @@
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="chap-submitting-changes">
<title>Submitting changes</title>
<section xml:id="submitting-changes-making-patches">
<title>Making patches</title>
<itemizedlist>
<listitem>
<para>
Read <link xlink:href="https://nixos.org/nixpkgs/manual/">Manual (How to write packages for Nix)</link>.
</para>
</listitem>
<listitem>
<para>
Fork <link xlink:href="https://github.com/nixos/nixpkgs/">the Nixpkgs repository</link> on GitHub.
</para>
</listitem>
<listitem>
<para>
Create a branch for your future fix.
<itemizedlist>
<listitem>
<para>
You can make branch from a commit of your local <command>nixos-version</command>. That will help you to avoid additional local compilations. Because you will receive packages from binary cache. For example
<screen>
<prompt>$ </prompt>nixos-version --hash
0998212
<prompt>$ </prompt>git checkout 0998212
<prompt>$ </prompt>git checkout -b 'fix/pkg-name-update'
</screen>
</para>
</listitem>
<listitem>
<para>
Please avoid working directly on the <command>master</command> branch.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
Make commits of logical units.
</para>
</listitem>
<listitem>
<para>
If you removed pkgs or made some major NixOS changes, write about it in the release notes for the next stable release. For example <command>nixos/doc/manual/release-notes/rl-2003.xml</command>.
</para>
</listitem>
<listitem>
<para>
Check for unnecessary whitespace with <command>git diff --check</command> before committing.
</para>
</listitem>
<listitem>
<para>
Format the commit in a following way:
</para>
<programlisting>
(pkg-name | nixos/&lt;module>): (from -> to | init at version | refactor | etc)
Additional information.
</programlisting>
<itemizedlist>
<listitem>
<para>
Examples:
<itemizedlist>
<listitem>
<para>
<command>nginx: init at 2.0.1</command>
</para>
</listitem>
<listitem>
<para>
<command>firefox: 54.0.1 -> 55.0</command>
</para>
</listitem>
<listitem>
<para>
<command>nixos/hydra: add bazBaz option</command>
</para>
</listitem>
<listitem>
<para>
<command>nixos/nginx: refactor config generation</command>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
Test your changes. If you work with
<itemizedlist>
<listitem>
<para>
nixpkgs:
<itemizedlist>
<listitem>
<para>
update pkg ->
<itemizedlist>
<listitem>
<para>
<command>nix-env -i pkg-name -f &lt;path to your local nixpkgs folder&gt;</command>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
add pkg ->
<itemizedlist>
<listitem>
<para>
Make sure it's in <command>pkgs/top-level/all-packages.nix</command>
</para>
</listitem>
<listitem>
<para>
<command>nix-env -i pkg-name -f &lt;path to your local nixpkgs folder&gt;</command>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
<emphasis>If you don't want to install pkg in you profile</emphasis>.
<itemizedlist>
<listitem>
<para>
<command>nix-build -A pkg-attribute-name &lt;path to your local nixpkgs folder&gt;/default.nix</command> and check results in the folder <command>result</command>. It will appear in the same directory where you did <command>nix-build</command>.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
If you did <command>nix-env -i pkg-name</command> you can do <command>nix-env -e pkg-name</command> to uninstall it from your system.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
NixOS and its modules:
<itemizedlist>
<listitem>
<para>
You can add new module to your NixOS configuration file (usually it's <command>/etc/nixos/configuration.nix</command>). And do <command>sudo nixos-rebuild test -I nixpkgs=&lt;path to your local nixpkgs folder&gt; --fast</command>.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
If you have commits <command>pkg-name: oh, forgot to insert whitespace</command>: squash commits in this case. Use <command>git rebase -i</command>.
</para>
</listitem>
<listitem>
<para>
<link xlink:href="https://git-scm.com/book/en/v2/Git-Branching-Rebasing">Rebase</link> your branch against current <command>master</command>.
</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="submitting-changes-submitting-changes">
<title>Submitting changes</title>
<itemizedlist>
<listitem>
<para>
Push your changes to your fork of nixpkgs.
</para>
</listitem>
<listitem>
<para>
Create the pull request
</para>
</listitem>
<listitem>
<para>
Follow <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md#submitting-changes">the contribution guidelines</link>.
</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="submitting-changes-submitting-security-fixes">
<title>Submitting security fixes</title>
<para>
Security fixes are submitted in the same way as other changes and thus the same guidelines apply.
</para>
<para>
If the security fix comes in the form of a patch and a CVE is available, then the name of the patch should be the CVE identifier, so e.g. <literal>CVE-2019-13636.patch</literal> in the case of a patch that is included in the Nixpkgs tree. If a patch is fetched the name needs to be set as well, e.g.:
</para>
<programlisting>
(fetchpatch {
name = "CVE-2019-11068.patch";
url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
})
</programlisting>
<para>
If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch.
</para>
<para>
Critical security fixes may by-pass the staging branches and be delivered directly to release branches such as <literal>master</literal> and <literal>release-*</literal>.
</para>
</section>
<section xml:id="submitting-changes-pull-request-template">
<title>Pull Request Template</title>
<para>
The pull request template helps determine what steps have been made for a contribution so far, and will help guide maintainers on the status of a change. The motivation section of the PR should include any extra details the title does not address and link any existing issues related to the pull request.
</para>
<para>
When a PR is created, it will be pre-populated with some checkboxes detailed below:
</para>
<section xml:id="submitting-changes-tested-with-sandbox">
<title>Tested using sandboxing</title>
<para>
When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of <function>fetch*</function> functions and files outside the Nix store. Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see <link
xlink:href="https://nixos.org/nix/manual/#conf-sandbox">sandbox</link> in Nix manual for details.
</para>
<para>
Sandboxing is not enabled by default in Nix due to a small performance hit on each build. In pull requests for <link
xlink:href="https://github.com/NixOS/nixpkgs/">nixpkgs</link> people are asked to test builds with sandboxing enabled (see <literal>Tested using sandboxing</literal> in the pull request template) because in<link
xlink:href="https://nixos.org/hydra/">https://nixos.org/hydra/</link> sandboxing is also used.
</para>
<para>
Depending if you use NixOS or other platforms you can use one of the following methods to enable sandboxing <emphasis role="bold">before</emphasis> building the package:
<itemizedlist>
<listitem>
<para>
<emphasis role="bold">Globally enable sandboxing on NixOS</emphasis>: add the following to <filename>configuration.nix</filename>
<screen>nix.useSandbox = true;</screen>
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">Globally enable sandboxing on non-NixOS platforms</emphasis>: add the following to: <filename>/etc/nix/nix.conf</filename>
<screen>sandbox = true</screen>
</para>
</listitem>
</itemizedlist>
</para>
</section>
<section xml:id="submitting-changes-platform-diversity">
<title>Built on platform(s)</title>
<para>
Many Nix packages are designed to run on multiple platforms. As such, it's important to let the maintainer know which platforms your changes have been tested on. It's not always practical to test a change on all platforms, and is not required for a pull request to be merged. Only check the systems you tested the build on in this section.
</para>
</section>
<section xml:id="submitting-changes-nixos-tests">
<title>Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)</title>
<para>
Packages with automated tests are much more likely to be merged in a timely fashion because it doesn't require as much manual testing by the maintainer to verify the functionality of the package. If there are existing tests for the package, they should be run to verify your changes do not break the tests. Tests only apply to packages with NixOS modules defined and can only be run on Linux. For more details on writing and running tests, see the <link
xlink:href="https://nixos.org/nixos/manual/index.html#sec-nixos-tests">section in the NixOS manual</link>.
</para>
</section>
<section xml:id="submitting-changes-tested-compilation">
<title>Tested compilation of all pkgs that depend on this change using <command>nixpkgs-review</command></title>
<para>
If you are updating a package's version, you can use nixpkgs-review to make sure all packages that depend on the updated package still compile correctly. The <command>nixpkgs-review</command> utility can look for and build all dependencies either based on uncommited changes with the <literal>wip</literal> option or specifying a github pull request number.
</para>
<para>
review changes from pull request number 12345:
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review pr 12345</screen>
</para>
<para>
review uncommitted changes:
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review wip</screen>
</para>
<para>
review changes from last commit:
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review rev HEAD</screen>
</para>
</section>
<section xml:id="submitting-changes-tested-execution">
<title>Tested execution of all binary files (usually in <filename>./result/bin/</filename>)</title>
<para>
It's important to test any executables generated by a build when you change or create a package in nixpkgs. This can be done by looking in <filename>./result/bin</filename> and running any files in there, or at a minimum, the main executable for the package. For example, if you make a change to <package>texlive</package>, you probably would only check the binaries associated with the change you made rather than testing all of them.
</para>
</section>
<section xml:id="submitting-changes-contribution-standards">
<title>Meets Nixpkgs contribution standards</title>
<para>
The last checkbox is fits <link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md">CONTRIBUTING.md</link>. The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
</para>
</section>
</section>
<section xml:id="submitting-changes-hotfixing-pull-requests">
<title>Hotfixing pull requests</title>
<itemizedlist>
<listitem>
<para>
Make the appropriate changes in you branch.
</para>
</listitem>
<listitem>
<para>
Don't create additional commits, do
<itemizedlist>
<listitem>
<para>
<command>git rebase -i</command>
</para>
</listitem>
<listitem>
<para>
<command>git push --force</command> to your branch.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="submitting-changes-commit-policy">
<title>Commit policy</title>
<itemizedlist>
<listitem>
<para>
Commits must be sufficiently tested before being merged, both for the master and staging branches.
</para>
</listitem>
<listitem>
<para>
Hydra builds for master and staging should not be used as testing platform, it's a build farm for changes that have been already tested.
</para>
</listitem>
<listitem>
<para>
When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people's installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from @edolstra.
</para>
</listitem>
</itemizedlist>
<section xml:id="submitting-changes-master-branch">
<title>Master branch</title>
<para>
The <literal>master</literal> branch is the main development branch.
It should only see non-breaking commits that do not cause mass rebuilds.
</para>
</section>
<section xml:id="submitting-changes-staging-branch">
<title>Staging branch</title>
<para>
The <literal>staging</literal> branch is a development branch where mass-rebuilds go.
It should only see non-breaking mass-rebuild commits.
That means it is not to be used for testing, and changes must have been well tested already.
If the branch is already in a broken state, please refrain from adding extra new breakages.
</para>
</section>
<section xml:id="submitting-changes-staging-next-branch">
<title>Staging-next branch</title>
<para>
The <literal>staging-next</literal> branch is for stabilizing mass-rebuilds submitted to the <literal>staging</literal> branch prior to merging them into <literal>master</literal>.
Mass-rebuilds should go via the <literal>staging</literal> branch.
It should only see non-breaking commits that are fixing issues blocking it from being merged into the <literal>master </literal> branch.
</para>
<para>
If the branch is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days and then merge into master.
</para>
</section>
<section xml:id="submitting-changes-stable-release-branches">
<title>Stable release branches</title>
<para>
For cherry-picking a commit to a stable release branch (<quote>backporting</quote>), use <literal>git cherry-pick -x &lt;original commit&gt;</literal> so that the original commit id is included in the commit.
</para>
<para>
Add a reason for the backport by using <literal>git cherry-pick -xe &lt;original commit&gt;</literal> instead when it is not obvious from the original commit message. It is not needed when it’s a minor version update that includes security and bug fixes but don’t add new features or when the commit fixes an otherwise broken package.
</para>
<para>
Here is an example of a cherry-picked commit message with good reason description:
</para>
<screen>
zfs: Keep trying root import until it works
Works around #11003.
(cherry picked from commit 98b213a11041af39b39473906b595290e2a4e2f9)
Reason: several people cannot boot with ZFS on NVMe
</screen>
<para>
Other examples of reasons are:
</para>
<itemizedlist spacing="compact">
<listitem>
<para>
Previously the build would fail due to, e.g., <literal>getaddrinfo</literal> not being defined
</para>
</listitem>
<listitem>
<para>
The previous download links were all broken
</para>
</listitem>
<listitem>
<para>
Crash when starting on some X11 systems
</para>
</listitem>
</itemizedlist>
</section>
</section>
</chapter>

186
doc/languages-frameworks/gnome.section.md Normal file
View File

@ -0,0 +1,186 @@
# GNOME {#sec-language-gnome}
## Packaging GNOME applications {#ssec-gnome-packaging}
Programs in the GNOME universe are written in various languages but they all use GObject-based libraries like GLib, GTK or GStreamer. These libraries are often modular, relying on looking into certain directories to find their modules. However, due to Nix’s specific file system organization, this will fail without our intervention. Fortunately, the libraries usually allow overriding the directories through environment variables, either natively or thanks to a patch in nixpkgs. [Wrapping](#fun-wrapProgram) the executables to ensure correct paths are available to the application constitutes a significant part of packaging a modern desktop application. In this section, we will describe various modules needed by such applications, environment variables needed to make the modules load, and finally a script that will do the work for us.
### Settings {#ssec-gnome-settings}
[GSettings](https://developer.gnome.org/gio/stable/GSettings.html) API is often used for storing settings. GSettings schemas are required, to know the type and other metadata of the stored values. GLib looks for `glib-2.0/schemas/gschemas.compiled` files inside the directories of `XDG_DATA_DIRS`.
On Linux, GSettings API is implemented using [dconf](https://wiki.gnome.org/Projects/dconf) backend. You will need to add `dconf` GIO module to `GIO_EXTRA_MODULES` variable, otherwise the `memory` backend will be used and the saved settings will not be persistent.
Last you will need the dconf database D-Bus service itself. You can enable it using `programs.dconf.enable`.
Some applications will also require `gsettings-desktop-schemas` for things like reading proxy configuration or user interface customization. This dependency is often not mentioned by upstream, you should grep for `org.gnome.desktop` and `org.gnome.system` to see if the schemas are needed.
### GdkPixbuf loaders {#ssec-gnome-gdk-pixbuf-loaders}
GTK applications typically use [GdkPixbuf](https://developer.gnome.org/gdk-pixbuf/stable/) to load images. But `gdk-pixbuf` package only supports basic bitmap formats like JPEG, PNG or TIFF, requiring to use third-party loader modules for other formats. This is especially painful since GTK itself includes SVG icons, which cannot be rendered without a loader provided by `librsvg`.
Unlike other libraries mentioned in this section, GdkPixbuf only supports a single value in its controlling environment variable `GDK_PIXBUF_MODULE_FILE`. It is supposed to point to a cache file containing information about the available loaders. Each loader package will contain a `lib/gdk-pixbuf-2.0/2.10.0/loaders.cache` file describing the default loaders in `gdk-pixbuf` package plus the loader contained in the package itself. If you want to use multiple third-party loaders, you will need to create your own cache file manually. Fortunately, this is pretty rare as [not many loaders exist](https://gitlab.gnome.org/federico/gdk-pixbuf-survey/blob/master/src/modules.md).
`gdk-pixbuf` contains [a setup hook](#ssec-gnome-hooks-gdk-pixbuf) that sets `GDK_PIXBUF_MODULE_FILE` from dependencies but as mentioned in further section, it is pretty limited. Loaders should propagate this setup hook.
### Icons {#ssec-gnome-icons}
When an application uses icons, an icon theme should be available in `XDG_DATA_DIRS` during runtime. The package for the default, icon-less [hicolor-icon-theme](https://www.freedesktop.org/wiki/Software/icon-theme/) (should be propagated by every icon theme) contains [a setup hook](#ssec-gnome-hooks-hicolor-icon-theme) that will pick up icon themes from `buildInputs` and pass it to our wrapper. Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed.
To avoid costly file system access when locating icons, GTK, [as well as Qt](https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html), can rely on `icon-theme.cache` files from the themes' top-level directories. These files are generated using `gtk-update-icon-cache`, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into `hicolor` theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, `gtk3` provides a [setup hook](#ssec-gnome-hooks-gtk-drop-icon-theme-cache) that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using `gtk.iconCache.enable` option if your desktop environment does not already do that.
### Packaging icon themes {#ssec-icon-theme-packaging}
Icon themes may inherit from other icon themes. The inheritance is specified using the `Inherits` key in the `index.theme` file distributed with the icon theme. According to the [icon theme specification](https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html), icons not provided by the theme are looked for in its parent icon themes. Therefore the parent themes should be installed as dependencies for a more complete experience regarding the icon sets used.
The package `hicolor-icon-theme` provides a setup hook which makes symbolic links for the parent themes into the directory `share/icons` of the current theme directory in the nix store, making sure they can be found at runtime. For that to work the packages providing parent icon themes should be listed as propagated build dependencies, together with `hicolor-icon-theme`.
Also make sure that `icon-theme.cache` is installed for each theme provided by the package, and set `dontDropIconThemeCache` to `true` so that the cache file is not removed by the `gtk3` setup hook.
### GTK Themes {#ssec-gnome-themes}
Previously, a GTK theme needed to be in `XDG_DATA_DIRS`. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for [elementary HIG](https://elementary.io/docs/human-interface-guidelines#human-interface-guidelines)) might require a special theme like `pantheon.elementary-gtk-theme`.
### GObject introspection typelibs {#ssec-gnome-typelibs}
[GObject introspection](https://wiki.gnome.org/Projects/GObjectIntrospection) allows applications to use C libraries in other languages easily. It does this through `typelib` files searched in `GI_TYPELIB_PATH`.
### Various plug-ins {#ssec-gnome-plugins}
If your application uses [GStreamer](https://gstreamer.freedesktop.org/) or [Grilo](https://wiki.gnome.org/Projects/Grilo), you should set `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH`, respectively.
## Onto `wrapGAppsHook` {#ssec-gnome-hooks}
Given the requirements above, the package expression would become messy quickly:
```nix
preFixup = ''
for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
wrapProgram "$f" \
--prefix GIO_EXTRA_MODULES : "${getLib dconf}/lib/gio/modules" \
--prefix XDG_DATA_DIRS : "$out/share" \
--prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
--prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
--prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share" \
--prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}"
done
'';
```
Fortunately, there is [`wrapGAppsHook`]{#ssec-gnome-hooks-wrapgappshook}. It works in conjunction with other setup hooks that populate environment variables, and it will then wrap all executables in `bin` and `libexec` directories using said variables.
For convenience, it also adds `dconf.lib` for a GIO module implementing a GSettings backend using `dconf`, `gtk3` for GSettings schemas, and `librsvg` for GdkPixbuf loader to the closure. In case you are packaging a program without a graphical interface, you might want to use [`wrapGAppsNoGuiHook`]{#ssec-gnome-hooks-wrapgappsnoguihook}, which runs the same script as `wrapGAppsHook` but does not bring `gtk3` and `librsvg` into the closure.
- `wrapGAppsHook` itself will add the package’s `share` directory to `XDG_DATA_DIRS`.
- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGAppsHook` will prepend it to `XDG_DATA_DIRS`.
- []{#ssec-gnome-hooks-gdk-pixbuf} `gdk-pixbuf` setup hook will populate `GDK_PIXBUF_MODULE_FILE` with the path to biggest `loaders.cache` file from the dependencies containing [GdkPixbuf loaders](ssec-gnome-gdk-pixbuf-loaders). This works fine when there are only two packages containing loaders (`gdk-pixbuf` and e.g. `librsvg`) – it will choose the second one, reasonably expecting that it will be bigger since it describes extra loader in addition to the default ones. But when there are more than two loader packages, this logic will break. One possible solution would be constructing a custom cache file for each package containing a program like `services/x11/gdk-pixbuf.nix` NixOS module does. `wrapGAppsHook` copies the `GDK_PIXBUF_MODULE_FILE` environment variable into the produced wrapper.
- []{#ssec-gnome-hooks-gtk-drop-icon-theme-cache} One of `gtk3`’s setup hooks will remove `icon-theme.cache` files from package’s icon theme directories to avoid conflicts. Icon theme packages should prevent this with `dontDropIconThemeCache = true;`.
- []{#ssec-gnome-hooks-dconf} `dconf.lib` is a dependency of `wrapGAppsHook`, which then also adds it to the `GIO_EXTRA_MODULES` variable.
- []{#ssec-gnome-hooks-hicolor-icon-theme} `hicolor-icon-theme`’s setup hook will add icon themes to `XDG_ICON_DIRS` which is prepended to `XDG_DATA_DIRS` by `wrapGAppsHook`.
- []{#ssec-gnome-hooks-gobject-introspection} `gobject-introspection` setup hook populates `GI_TYPELIB_PATH` variable with `lib/girepository-1.0` directories of dependencies, which is then added to wrapper by `wrapGAppsHook`. It also adds `share` directories of dependencies to `XDG_DATA_DIRS`, which is intended to promote GIR files but it also [pollutes the closures](https://github.com/NixOS/nixpkgs/issues/32790) of packages using `wrapGAppsHook`.
::: warning
The setup hook [currently](https://github.com/NixOS/nixpkgs/issues/56943) does not work in expressions with `strictDeps` enabled, like Python packages. In those cases, you will need to disable it with `strictDeps = false;`.
:::
- []{#ssec-gnome-hooks-gst-grl-plugins} Setup hooks of `gst_all_1.gstreamer` and `gnome3.grilo` will populate the `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH` variables, respectively, which will then be added to the wrapper by `wrapGAppsHook`.
You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs` in `preFixup` hook:
```nix
preFixup = ''
gappsWrapperArgs+=(
# Thumbnailers
--prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
--prefix XDG_DATA_DIRS : "${librsvg}/share"
--prefix XDG_DATA_DIRS : "${shared-mime-info}/share"
)
'';
```
## Updating GNOME packages {#ssec-gnome-updating}
Most GNOME package offer [`updateScript`](#var-passthru-updateScript), it is therefore possible to update to latest source tarball by running `nix-shell maintainers/scripts/update.nix --argstr package gnome3.nautilus` or even en masse with `nix-shell maintainers/scripts/update.nix --argstr path gnome3`. Read the package’s `NEWS` file to see what changed.
## Frequently encountered issues {#ssec-gnome-common-issues}
#### `GLib-GIO-ERROR **: 06:04:50.903: No GSettings schemas are installed on the system` {#ssec-gnome-common-issues-no-schemas}
There are no schemas available in `XDG_DATA_DIRS`. Temporarily add a random package containing schemas like `gsettings-desktop-schemas` to `buildInputs`. [`glib`](#ssec-gnome-hooks-glib) and [`wrapGAppsHook`](#ssec-gnome-hooks-wrapgappshook) setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the [next error](#ssec-gnome-common-issues-missing-schema). Or you can try looking through the source code for the actual schemas used.
#### `GLib-GIO-ERROR **: 06:04:50.903: Settings schema ‘org.gnome.foo’ is not installed` {#ssec-gnome-common-issues-missing-schema}
Package is missing some GSettings schemas. You can find out the package containing the schema with `nix-locate org.gnome.foo.gschema.xml` and let the hooks handle the wrapping as [above](#ssec-gnome-common-issues-no-schemas).
#### When using `wrapGAppsHook` with special derivers you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
This is because derivers like `python.pkgs.buildPythonApplication` or `qt5.mkDerivation` have setup-hooks automatically added that produce wrappers with makeWrapper. The simplest way to workaround that is to disable the `wrapGAppsHook` automatic wrapping with `dontWrapGApps = true;` and pass the arguments it intended to pass to makeWrapper to another.
In the case of a Python application it could look like:
```nix
python3.pkgs.buildPythonApplication {
pname = "gnome-music";
version = "3.32.2";
nativeBuildInputs = [
wrapGAppsHook
gobject-introspection
...
];
dontWrapGApps = true;
# Arguments to be passed to `makeWrapper`, only used by buildPython*
preFixup = ''
makeWrapperArgs+=("''${gappsWrapperArgs[@]}")
'';
}
```
And for a QT app like:
```nix
mkDerivation {
pname = "calibre";
version = "3.47.0";
nativeBuildInputs = [
wrapGAppsHook
qmake
...
];
dontWrapGApps = true;
# Arguments to be passed to `makeWrapper`, only used by qt5’s mkDerivation
preFixup = ''
qtWrapperArgs+=("''${gappsWrapperArgs[@]}")
'';
}
```
#### I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension. {#ssec-gnome-common-issues-unwrappable-package}
You can rely on applications depending on the library setting the necessary environment variables but that is often easy to miss. Instead we recommend to patch the paths in the source code whenever possible. Here are some examples:
- []{#ssec-gnome-common-issues-unwrappable-package-gnome-shell-ext} [Replacing a `GI_TYPELIB_PATH` in GNOME Shell extension](https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/gnome-3/core/gnome-shell-extensions/default.nix#L21-L24) – we are using `substituteAll` to include the path to a typelib into a patch.
- []{#ssec-gnome-common-issues-unwrappable-package-gsettings} The following examples are hardcoding GSettings schema paths. To get the schema paths we use the functions
* `glib.getSchemaPath` Takes a nix package attribute as an argument.
* `glib.makeSchemaPath` Takes a package output like `$out` and a derivation name. You should use this if the schemas you need to hardcode are in the same derivation.
[]{#ssec-gnome-common-issues-unwrappable-package-gsettings-vala} [Hard-coding GSettings schema path in Vala plug-in (dynamically loaded library)](https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/pantheon/apps/elementary-files/default.nix#L78-L86) – here, `substituteAll` cannot be used since the schema comes from the same package preventing us from pass its path to the function, probably due to a [Nix bug](https://github.com/NixOS/nix/issues/1846).
[]{#ssec-gnome-common-issues-unwrappable-package-gsettings-c} [Hard-coding GSettings schema path in C library](https://github.com/NixOS/nixpkgs/blob/29c120c065d03b000224872251bed93932d42412/pkgs/development/libraries/glib-networking/default.nix#L31-L34) – nothing special other than using [Coccinelle patch](https://github.com/NixOS/nixpkgs/pull/67957#issuecomment-527717467) to generate the patch itself.
#### I need to wrap a binary outside `bin` and `libexec` directories. {#ssec-gnome-common-issues-weird-location}
You can manually trigger the wrapping with `wrapGApp` in `preFixup` phase. It takes a path to a program as a first argument; the remaining arguments are passed directly to [`wrapProgram`](#fun-wrapProgram) function.

327
doc/languages-frameworks/gnome.xml
View File

@ -1,327 +0,0 @@
<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-language-gnome">
<title>GNOME</title>
<section xml:id="ssec-gnome-packaging">
<title>Packaging GNOME applications</title>
<para>
Programs in the GNOME universe are written in various languages but they all use GObject-based libraries like GLib, GTK or GStreamer. These libraries are often modular, relying on looking into certain directories to find their modules. However, due to Nix’s specific file system organization, this will fail without our intervention. Fortunately, the libraries usually allow overriding the directories through environment variables, either natively or thanks to a patch in nixpkgs. <link xlink:href="#fun-wrapProgram">Wrapping</link> the executables to ensure correct paths are available to the application constitutes a significant part of packaging a modern desktop application. In this section, we will describe various modules needed by such applications, environment variables needed to make the modules load, and finally a script that will do the work for us.
</para>
<section xml:id="ssec-gnome-settings">
<title>Settings</title>
<para>
<link xlink:href="https://developer.gnome.org/gio/stable/GSettings.html">GSettings</link> API is often used for storing settings. GSettings schemas are required, to know the type and other metadata of the stored values. GLib looks for <filename>glib-2.0/schemas/gschemas.compiled</filename> files inside the directories of <envar>XDG_DATA_DIRS</envar>.
</para>
<para>
On Linux, GSettings API is implemented using <link xlink:href="https://wiki.gnome.org/Projects/dconf">dconf</link> backend. You will need to add <literal>dconf</literal> GIO module to <envar>GIO_EXTRA_MODULES</envar> variable, otherwise the <literal>memory</literal> backend will be used and the saved settings will not be persistent.
</para>
<para>
Last you will need the dconf database D-Bus service itself. You can enable it using <option>programs.dconf.enable</option>.
</para>
<para>
Some applications will also require <package>gsettings-desktop-schemas</package> for things like reading proxy configuration or user interface customization. This dependency is often not mentioned by upstream, you should grep for <literal>org.gnome.desktop</literal> and <literal>org.gnome.system</literal> to see if the schemas are needed.
</para>
</section>
<section xml:id="ssec-gnome-gdk-pixbuf-loaders">
<title>GdkPixbuf loaders</title>
<para>
GTK applications typically use <link xlink:href="https://developer.gnome.org/gdk-pixbuf/stable/">GdkPixbuf</link> to load images. But <package>gdk-pixbuf</package> package only supports basic bitmap formats like JPEG, PNG or TIFF, requiring to use third-party loader modules for other formats. This is especially painful since GTK itself includes SVG icons, which cannot be rendered without a loader provided by <package>librsvg</package>.
</para>
<para>
Unlike other libraries mentioned in this section, GdkPixbuf only supports a single value in its controlling environment variable <envar>GDK_PIXBUF_MODULE_FILE</envar>. It is supposed to point to a cache file containing information about the available loaders. Each loader package will contain a <filename>lib/gdk-pixbuf-2.0/2.10.0/loaders.cache</filename> file describing the default loaders in <package>gdk-pixbuf</package> package plus the loader contained in the package itself. If you want to use multiple third-party loaders, you will need to create your own cache file manually. Fortunately, this is pretty rare as <link xlink:href="https://gitlab.gnome.org/federico/gdk-pixbuf-survey/blob/master/src/modules.md">not many loaders exist</link>.
</para>
<para>
<package>gdk-pixbuf</package> contains <link linkend="ssec-gnome-hooks-gdk-pixbuf">a setup hook</link> that sets <envar>GDK_PIXBUF_MODULE_FILE</envar> from dependencies but as mentioned in further section, it is pretty limited. Loaders should propagate this setup hook.
</para>
</section>
<section xml:id="ssec-gnome-icons">
<title>Icons</title>
<para>
When an application uses icons, an icon theme should be available in <envar>XDG_DATA_DIRS</envar> during runtime. The package for the default, icon-less <link xlink:href="https://www.freedesktop.org/wiki/Software/icon-theme/">hicolor-icon-theme</link> (should be propagated by every icon theme) contains <link linkend="ssec-gnome-hooks-hicolor-icon-theme">a setup hook</link> that will pick up icon themes from <literal>buildInputs</literal> and pass it to our wrapper. Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed.
</para>
<para>
To avoid costly file system access when locating icons, GTK, <link xlink:href="https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html">as well as Qt</link>, can rely on <filename>icon-theme.cache</filename> files from the themes’ top-level directories. These files are generated using <command>gtk-update-icon-cache</command>, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into <literal>hicolor</literal> theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, <package>gtk3</package> provides a <link xlink:href="#ssec-gnome-hooks-gtk-drop-icon-theme-cache">setup hook</link> that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using <option>gtk.iconCache.enable</option> option if your desktop environment does not already do that.
</para>
</section>
<section xml:id="ssec-icon-theme-packaging">
<title>Packaging icon themes</title>
<para>
Icon themes may inherit from other icon themes. The inheritance is specified using the <literal>Inherits</literal> key in the <filename>index.theme</filename> file distributed with the icon theme. According to the <link xlink:href="https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html">icon theme specification</link>, icons not provided by the theme are looked for in its parent icon themes. Therefore the parent themes should be installed as dependencies for a more complete experience regarding the icon sets used.
</para>
<para>
The package <package>hicolor-icon-theme</package> provides a setup hook which makes symbolic links for the parent themes into the directory <filename>share/icons</filename> of the current theme directory in the nix store, making sure they can be found at runtime. For that to work the packages providing parent icon themes should be listed as propagated build dependencies, together with <package>hicolor-icon-theme</package>.
</para>
<para>
Also make sure that <filename>icon-theme.cache</filename> is installed for each theme provided by the package, and set <code>dontDropIconThemeCache</code> to <code>true</code> so that the cache file is not removed by the <package>gtk3</package> setup hook.
</para>
</section>
<section xml:id="ssec-gnome-themes">
<title>GTK Themes</title>
<para>
Previously, a GTK theme needed to be in <envar>XDG_DATA_DIRS</envar>. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for <link xlink:href="https://elementary.io/docs/human-interface-guidelines#human-interface-guidelines">elementary HIG</link>) might require a special theme like <package>pantheon.elementary-gtk-theme</package>.
</para>
</section>
<section xml:id="ssec-gnome-typelibs">
<title>GObject introspection typelibs</title>
<para>
<link xlink:href="https://wiki.gnome.org/Projects/GObjectIntrospection">GObject introspection</link> allows applications to use C libraries in other languages easily. It does this through <literal>typelib</literal> files searched in <envar>GI_TYPELIB_PATH</envar>.
</para>
</section>
<section xml:id="ssec-gnome-plugins">
<title>Various plug-ins</title>
<para>
If your application uses <link xlink:href="https://gstreamer.freedesktop.org/">GStreamer</link> or <link xlink:href="https://wiki.gnome.org/Projects/Grilo">Grilo</link>, you should set <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> and <envar>GRL_PLUGIN_PATH</envar>, respectively.
</para>
</section>
</section>
<section xml:id="ssec-gnome-hooks">
<title>Onto <package>wrapGAppsHook</package></title>
<para>
Given the requirements above, the package expression would become messy quickly:
<programlisting>
preFixup = ''
for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
wrapProgram "$f" \
--prefix GIO_EXTRA_MODULES : "${getLib dconf}/lib/gio/modules" \
--prefix XDG_DATA_DIRS : "$out/share" \
--prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
--prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
--prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share" \
--prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}"
done
'';
</programlisting>
</para>
<para>
Fortunately, there is <package xml:id="ssec-gnome-hooks-wrapgappshook">wrapGAppsHook</package>. It works in conjunction with other setup hooks that populate environment variables, and it will then wrap all executables in <filename>bin</filename> and <filename>libexec</filename> directories using said variables.
</para>
<para>
For convenience, it also adds <package>dconf.lib</package> for a GIO module implementing a GSettings backend using <package>dconf</package>, <package>gtk3</package> for GSettings schemas, and <package>librsvg</package> for GdkPixbuf loader to the closure. In case you are packaging a program without a graphical interface, you might want to use <package xml:id="ssec-gnome-hooks-wrapgappsnoguihook">wrapGAppsNoGuiHook</package>, which runs the same script as <package>wrapGAppsHook</package> but does not bring <package>gtk3</package> and <package>librsvg</package> into the closure.
</para>
<para>
<itemizedlist>
<listitem>
<para>
<package>wrapGAppsHook</package> itself will add the package’s <filename>share</filename> directory to <envar>XDG_DATA_DIRS</envar>.
</para>
</listitem>
<listitem xml:id="ssec-gnome-hooks-glib">
<para>
<package>glib</package> setup hook will populate <envar>GSETTINGS_SCHEMAS_PATH</envar> and then <package>wrapGAppsHook</package> will prepend it to <envar>XDG_DATA_DIRS</envar>.
</para>
</listitem>
<listitem xml:id="ssec-gnome-hooks-gdk-pixbuf">
<para>
<package>gdk-pixbuf</package> setup hook will populate <envar>GDK_PIXBUF_MODULE_FILE</envar> with the path to biggest <filename>loaders.cache</filename> file from the dependencies containing <link xlink:href="ssec-gnome-gdk-pixbuf-loaders">GdkPixbuf loaders</link>. This works fine when there are only two packages containing loaders (<package>gdk-pixbuf</package> and e.g. <package>librsvg</package>) – it will choose the second one, reasonably expecting that it will be bigger since it describes extra loader in addition to the default ones. But when there are more than two loader packages, this logic will break. One possible solution would be constructing a custom cache file for each package containing a program like <filename>services/x11/gdk-pixbuf.nix</filename> NixOS module does. <package>wrapGAppsHook</package> copies the <envar>GDK_PIXBUF_MODULE_FILE</envar> environment variable into the produced wrapper.
</para>
</listitem>
<listitem xml:id="ssec-gnome-hooks-gtk-drop-icon-theme-cache">
<para>
One of <package>gtk3</package>’s setup hooks will remove <filename>icon-theme.cache</filename> files from package’s icon theme directories to avoid conflicts. Icon theme packages should prevent this with <code>dontDropIconThemeCache = true;</code>.
</para>
</listitem>
<listitem xml:id="ssec-gnome-hooks-dconf">
<para>
<package>dconf.lib</package> is a dependency of <package>wrapGAppsHook</package>, which then also adds it to the <envar>GIO_EXTRA_MODULES</envar> variable.
</para>
</listitem>
<listitem xml:id="ssec-gnome-hooks-hicolor-icon-theme">
<para>
<package>hicolor-icon-theme</package>’s setup hook will add icon themes to <envar>XDG_ICON_DIRS</envar> which is prepended to <envar>XDG_DATA_DIRS</envar> by <package>wrapGAppsHook</package>.
</para>
</listitem>
<listitem xml:id="ssec-gnome-hooks-gobject-introspection">
<para>
<package>gobject-introspection</package> setup hook populates <envar>GI_TYPELIB_PATH</envar> variable with <filename>lib/girepository-1.0</filename> directories of dependencies, which is then added to wrapper by <package>wrapGAppsHook</package>. It also adds <filename>share</filename> directories of dependencies to <envar>XDG_DATA_DIRS</envar>, which is intended to promote GIR files but it also <link xlink:href="https://github.com/NixOS/nixpkgs/issues/32790">pollutes the closures</link> of packages using <package>wrapGAppsHook</package>.
</para>
<warning>
<para>
The setup hook <link xlink:href="https://github.com/NixOS/nixpkgs/issues/56943">currently</link> does not work in expressions with <literal>strictDeps</literal> enabled, like Python packages. In those cases, you will need to disable it with <code>strictDeps = false;</code>.
</para>
</warning>
</listitem>
<listitem xml:id="ssec-gnome-hooks-gst-grl-plugins">
<para>
Setup hooks of <package>gst_all_1.gstreamer</package> and <package>gnome3.grilo</package> will populate the <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> and <envar>GRL_PLUGIN_PATH</envar> variables, respectively, which will then be added to the wrapper by <literal>wrapGAppsHook</literal>.
</para>
</listitem>
</itemizedlist>
</para>
<para>
You can also pass additional arguments to <literal>makeWrapper</literal> using <literal>gappsWrapperArgs</literal> in <literal>preFixup</literal> hook:
<programlisting>
preFixup = ''
gappsWrapperArgs+=(
# Thumbnailers
--prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
--prefix XDG_DATA_DIRS : "${librsvg}/share"
--prefix XDG_DATA_DIRS : "${shared-mime-info}/share"
)
'';
</programlisting>
</para>
</section>
<section xml:id="ssec-gnome-updating">
<title>Updating GNOME packages</title>
<para>
Most GNOME package offer <link linkend="var-passthru-updateScript"><literal>updateScript</literal></link>, it is therefore possible to update to latest source tarball by running <command>nix-shell maintainers/scripts/update.nix --argstr package gnome3.nautilus</command> or even en masse with <command>nix-shell maintainers/scripts/update.nix --argstr path gnome3</command>. Read the package’s <filename>NEWS</filename> file to see what changed.
</para>
</section>
<section xml:id="ssec-gnome-common-issues">
<title>Frequently encountered issues</title>
<variablelist>
<varlistentry xml:id="ssec-gnome-common-issues-no-schemas">
<term>
<computeroutput>GLib-GIO-ERROR **: <replaceable>06:04:50.903</replaceable>: No GSettings schemas are installed on the system</computeroutput>
</term>
<listitem>
<para>
There are no schemas available in <envar>XDG_DATA_DIRS</envar>. Temporarily add a random package containing schemas like <package>gsettings-desktop-schemas</package> to <literal>buildInputs</literal>. <link linkend="ssec-gnome-hooks-glib"><package>glib</package></link> and <link linkend="ssec-gnome-hooks-wrapgappshook"><package>wrapGAppsHook</package></link> setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the <link linkend="ssec-gnome-common-issues-missing-schema">next error</link>. Or you can try looking through the source code for the actual schemas used.
</para>
</listitem>
</varlistentry>
<varlistentry xml:id="ssec-gnome-common-issues-missing-schema">
<term>
<computeroutput>GLib-GIO-ERROR **: <replaceable>06:04:50.903</replaceable>: Settings schema ‘<replaceable>org.gnome.foo</replaceable>’ is not installed</computeroutput>
</term>
<listitem>
<para>
Package is missing some GSettings schemas. You can find out the package containing the schema with <command>nix-locate <replaceable>org.gnome.foo</replaceable>.gschema.xml</command> and let the hooks handle the wrapping as <link linkend="ssec-gnome-common-issues-no-schemas">above</link>.
</para>
</listitem>
</varlistentry>
<varlistentry xml:id="ssec-gnome-common-issues-double-wrapped">
<term>
When using <package>wrapGAppsHook</package> with special derivers you can end up with double wrapped binaries.
</term>
<listitem>
<para>
This is because derivers like <function>python.pkgs.buildPythonApplication</function> or <function>qt5.mkDerivation</function> have setup-hooks automatically added that produce wrappers with <package>makeWrapper</package>. The simplest way to workaround that is to disable the <package>wrapGAppsHook</package> automatic wrapping with <code>dontWrapGApps = true;</code> and pass the arguments it intended to pass to <package>makeWrapper</package> to another.
</para>
<para>
In the case of a Python application it could look like:
<programlisting>
python3.pkgs.buildPythonApplication {
pname = "gnome-music";
version = "3.32.2";
nativeBuildInputs = [
wrapGAppsHook
gobject-introspection
...
];
dontWrapGApps = true;
# Arguments to be passed to `makeWrapper`, only used by buildPython*
preFixup = ''
makeWrapperArgs+=("''${gappsWrapperArgs[@]}")
'';
}
</programlisting>
And for a QT app like:
<programlisting>
mkDerivation {
pname = "calibre";
version = "3.47.0";
nativeBuildInputs = [
wrapGAppsHook
qmake
...
];
dontWrapGApps = true;
# Arguments to be passed to `makeWrapper`, only used by qt5’s mkDerivation
preFixup = ''
qtWrapperArgs+=("''${gappsWrapperArgs[@]}")
'';
}
</programlisting>
</para>
</listitem>
</varlistentry>
<varlistentry xml:id="ssec-gnome-common-issues-unwrappable-package">
<term>
I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension.
</term>
<listitem>
<para>
You can rely on applications depending on the library setting the necessary environment variables but that is often easy to miss. Instead we recommend to patch the paths in the source code whenever possible. Here are some examples:
<itemizedlist>
<listitem xml:id="ssec-gnome-common-issues-unwrappable-package-gnome-shell-ext">
<para>
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/gnome-3/core/gnome-shell-extensions/default.nix#L21-L24">Replacing a <envar>GI_TYPELIB_PATH</envar> in GNOME Shell extension</link> – we are using <function>substituteAll</function> to include the path to a typelib into a patch.
</para>
</listitem>
<listitem xml:id="ssec-gnome-common-issues-unwrappable-package-gsettings">
<para>
The following examples are hardcoding GSettings schema paths. To get the schema paths we use the functions
<itemizedlist>
<listitem>
<para>
<function>glib.getSchemaPath</function> Takes a nix package attribute as an argument.
</para>
</listitem>
<listitem>
<para>
<function>glib.makeSchemaPath</function> Takes a package output like <literal>$out</literal> and a derivation name. You should use this if the schemas you need to hardcode are in the same derivation.
</para>
</listitem>
</itemizedlist>
</para>
<para xml:id="ssec-gnome-common-issues-unwrappable-package-gsettings-vala">
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/pantheon/apps/elementary-files/default.nix#L78-L86">Hard-coding GSettings schema path in Vala plug-in (dynamically loaded library)</link> – here, <function>substituteAll</function> cannot be used since the schema comes from the same package preventing us from pass its path to the function, probably due to a <link xlink:href="https://github.com/NixOS/nix/issues/1846">Nix bug</link>.
</para>
<para xml:id="ssec-gnome-common-issues-unwrappable-package-gsettings-c">
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/29c120c065d03b000224872251bed93932d42412/pkgs/development/libraries/glib-networking/default.nix#L31-L34">Hard-coding GSettings schema path in C library</link> – nothing special other than using <link xlink:href="https://github.com/NixOS/nixpkgs/pull/67957#issuecomment-527717467">Coccinelle patch</link> to generate the patch itself.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</varlistentry>
<varlistentry xml:id="ssec-gnome-common-issues-weird-location">
<term>
I need to wrap a binary outside <filename>bin</filename> and <filename>libexec</filename> directories.
</term>
<listitem>
<para>
You can manually trigger the wrapping with <function>wrapGApp</function> in <literal>preFixup</literal> phase. It takes a path to a program as a first argument; the remaining arguments are passed directly to <function xlink:href="#fun-wrapProgram">wrapProgram</function> function.
</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>

2
doc/languages-frameworks/index.xml
View File

@ -12,7 +12,7 @@
<xi:include href="coq.section.xml" />
<xi:include href="crystal.section.xml" />
<xi:include href="emscripten.section.xml" />
<xi:include href="gnome.xml" />
<xi:include href="gnome.section.xml" />
<xi:include href="go.section.xml" />
<xi:include href="haskell.section.xml" />
<xi:include href="idris.section.xml" />

2
doc/manual.xml
View File

@ -34,7 +34,7 @@
<title>Contributing to Nixpkgs</title>
<xi:include href="contributing/quick-start.xml" />
<xi:include href="contributing/coding-conventions.xml" />
<xi:include href="contributing/submitting-changes.xml" />
<xi:include href="contributing/submitting-changes.chapter.xml" />
<xi:include href="contributing/reviewing-contributions.xml" />
<xi:include href="contributing/contributing-to-documentation.xml" />
</part>

2
doc/stdenv/stdenv.xml
View File

@ -1989,7 +1989,7 @@ addEnvHooks "$hostOffset" myBashFunction
</term>
<listitem>
<para>
Exports <envar>GDK_PIXBUF_MODULE_FILE</envar> environment variable to the builder. Add librsvg package to <varname>buildInputs</varname> to get svg support. See also <xref linkend="ssec-gnome-hooks-gdk-pixbuf" />.
Exports <envar>GDK_PIXBUF_MODULE_FILE</envar> environment variable to the builder. Add librsvg package to <varname>buildInputs</varname> to get svg support. See also the <link linkend="ssec-gnome-hooks-gdk-pixbuf">setup hook description in GNOME platform docs</link>.
</para>
</listitem>
</varlistentry>

5
lib/licenses.nix
View File

@ -18,6 +18,11 @@ lib.mapAttrs (n: v: v // { shortName = n; }) {
fullName = "Abstyles License";
};
afl20 = spdx {
spdxId = "AFL-2.0";
fullName = "Academic Free License v2.0";
};
afl21 = spdx {
spdxId = "AFL-2.1";
fullName = "Academic Free License v2.1";

4
pkgs/applications/audio/musikcube/default.nix
View File

@ -17,13 +17,13 @@
stdenv.mkDerivation rec {
pname = "musikcube";
version = "0.95.0";
version = "0.96.1";
src = fetchFromGitHub {
owner = "clangen";
repo = pname;
rev = version;
sha256 = "16ksr4yjkg88bpij1i49dzi07ffhqq8b36r090y4fq5czrc420rc";
sha256 = "0gpyr25q6g9b8f9hi6jx3p4ijl7xrrjc78vw1fyjd59a7690d7kr";
};
nativeBuildInputs = [

55
pkgs/applications/editors/spacevim/default.nix Normal file
View File

@ -0,0 +1,55 @@
{ ripgrep, gitAndTools, fzf, makeWrapper, vim_configurable, vimPlugins, fetchFromGitHub, writeTextDir
, stdenv, runCommandNoCC, remarshal, formats, spacevim_config ? import ./init.nix }:
with stdenv;
let
format = formats.toml {};
vim-customized = vim_configurable.customize {
name = "vim";
# Not clear at the moment how to import plugins such that
# SpaceVim finds them and does not auto download them to
# ~/.cache/vimfiles/repos
vimrcConfig.packages.myVimPackage = with vimPlugins; { start = [ ]; };
};
spacevimdir = format.generate "init.toml" spacevim_config;
in mkDerivation rec {
pname = "spacevim";
version = "1.5.0";
src = fetchFromGitHub {
owner = "SpaceVim";
repo = "SpaceVim";
rev = "v${version}";
sha256 = "1xw4l262x7wzs1m65bddwqf3qx4254ykddsw3c3p844pb3mzqhh7";
};
nativeBuildInputs = [ makeWrapper vim-customized];
buildInputs = [ vim-customized ];
buildPhase = ''
# generate the helptags
vim -u NONE -c "helptags $(pwd)/doc" -c q
'';
patches = [ ./helptags.patch ];
installPhase = ''
mkdir -p $out/bin
cp -r $(pwd) $out/SpaceVim
# trailing slash very important for SPACEVIMDIR
makeWrapper "${vim-customized}/bin/vim" "$out/bin/spacevim" \
--add-flags "-u $out/SpaceVim/vimrc" --set SPACEVIMDIR "${spacevimdir}/" \
--prefix PATH : ${lib.makeBinPath [ fzf gitAndTools.git ripgrep]}
'';
meta = with stdenv.lib; {
description = "Modern Vim distribution";
longDescription = ''
SpaceVim is a distribution of the Vim editor that’s inspired by spacemacs.
'';
homepage = "https://spacevim.org/";
license = licenses.gpl3Plus;
maintainers = [ maintainers.fzakaria ];
platforms = platforms.all;
};
}

18
pkgs/applications/editors/spacevim/helptags.patch Normal file
View File

@ -0,0 +1,18 @@
diff --git a/autoload/SpaceVim.vim b/autoload/SpaceVim.vim
index 16688680..fcafd6f7 100644
--- a/autoload/SpaceVim.vim
+++ b/autoload/SpaceVim.vim
@@ -1255,13 +1255,6 @@ function! SpaceVim#end() abort
let &helplang = 'jp'
endif
""
- " generate tags for SpaceVim
- let help = fnamemodify(g:_spacevim_root_dir, ':p:h') . '/doc'
- try
- exe 'helptags ' . help
- catch
- call SpaceVim#logger#warn('Failed to generate helptags for SpaceVim')
- endtry
""
" set language

46
pkgs/applications/editors/spacevim/init.nix Normal file
View File

@ -0,0 +1,46 @@
# The Nix expression is a 1:1 mapping of the spacevim toml config which you can find on their website: spacevim.org/quick-start-guide/#configuration
{
custom_plugins = [{
merged = false;
name = "lilydjwg/colorizer";
}];
layers = [
{ name = "default"; }
{
enable = true;
name = "colorscheme";
}
{ name = "fzf"; }
{
default_height = 30;
default_position = "top";
name = "shell";
}
{ name = "edit"; }
{ name = "VersionControl"; }
{ name = "git"; }
{
auto-completion-return-key-behavior = "complete";
auto-completion-tab-key-behavior = "cycle";
autocomplete_method = "coc";
name = "autocomplete";
}
{ name = "lang#ruby"; }
{ name = "lang#nix"; }
{ name = "lang#java"; }
{ name = "lang#kotlin"; }
{ name = "lang#sh"; }
{ name = "lang#html"; }
];
options = {
buffer_index_type = 4;
colorscheme = "gruvbox";
colorscheme_bg = "dark";
enable_guicolors = true;
enable_statusline_mode = true;
enable_tabline_filetype_icon = true;
statusline_separator = "fire";
timeoutlen = 500;
};
}

22
pkgs/applications/graphics/img-cat/default.nix Normal file
View File

@ -0,0 +1,22 @@
{ lib, buildGoModule, fetchFromGitHub }:
buildGoModule rec {
pname = "imgcat";
version = "1.2.0";
src = fetchFromGitHub {
owner = "trashhalo";
repo = "imgcat";
rev = "v${version}";
sha256 = "0x7a1izsbrbfph7wa9ny9r4a8lp6z15qpb6jf8wsxshiwnkjyrig";
};
vendorSha256 = "191gi4c5jk8p9xvbm1cdhk5yi8q2cp2jvjq1sgxqw1ad0lppwhg2";
meta = with lib; {
description = "A tool to output images as RGB ANSI graphics on the terminal";
homepage = "https://github.com/trashhalo/imgcat";
license = licenses.mit;
maintainers = with maintainers; [ penguwin ];
};
}

6
pkgs/applications/graphics/odafileconverter/default.nix
View File

@ -4,7 +4,7 @@ let
# To obtain the version you will need to run the following command:
#
# dpkg-deb -I ${odafileconverter.src} | grep Version
version = "21.7.0.0";
version = "21.11.0.0";
rpath = "$ORIGIN:${lib.makeLibraryPath [ stdenv.cc.cc qtbase ]}";
in mkDerivation {
@ -14,8 +14,8 @@ in mkDerivation {
src = fetchurl {
# NB: this URL is not stable (i.e. the underlying file and the corresponding version will change over time)
url = "https://download.opendesign.com/guestfiles/ODAFileConverter/ODAFileConverter_QT5_lnxX64_7.2dll.deb";
sha256 = "0sa21nnwzqb6g7gl0z43smqgcd9h3xipj3cq2cl7ybfh3cvcxfi9";
url = "http://web.archive.org/web/20201206221727if_/https://download.opendesign.com/guestfiles/Demo/ODAFileConverter_QT5_lnxX64_7.2dll_21.11.deb";
sha256 = "10027a3ab18efd04ca75aa699ff550eca3bdfe6f7084460d3c00001bffb50070";
};
unpackPhase = ''

4
pkgs/applications/networking/browsers/chromium/plugins.nix
View File

@ -44,11 +44,11 @@ let
flash = stdenv.mkDerivation rec {
pname = "flashplayer-ppapi";
version = "32.0.0.445";
version = "32.0.0.453";
src = fetchzip {
url = "https://fpdownload.adobe.com/pub/flashplayer/pdc/${version}/flash_player_ppapi_linux.x86_64.tar.gz";
sha256 = "1r9vd210d2qp501q40pjx60mzah08rg0f8jk5rpp52ddajwggalv";
sha256 = "1d0hxn6snvx15clhcwncw40z0mf5p1pw68wrp7w1l3jkkw4brsgj";
stripRoot = false;
};

10
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/default.nix
View File

@ -74,7 +74,7 @@ let
in
stdenv.mkDerivation rec {
pname = "flashplayer";
version = "32.0.0.445";
version = "32.0.0.453";
src = fetchurl {
url =
@ -85,14 +85,14 @@ stdenv.mkDerivation rec {
sha256 =
if debug then
if arch == "x86_64" then
"0jn1g8k8fkikhi0xlcsx5a43lxrj6ynwbxn55b17wacsqw20b9ii"
"0jjzx7jpaz2a4p5x5535v8286pakhfymrq6zi16skv4cfixc0q99"
else
"104af8sy0qq45agg3lpjwn1cp8lhpcjiim6gqn4cymcfp8d7ngg0"
"1ikgxl33g503bm7v1209bmwppx0j40dnlm01hddx5i2qzv7dwh2v"
else
if arch == "x86_64" then
"1dd52nhnl3f1d7r82gq28scna5qr39gpfqkgrhzd6cxd2vnhnhjn"
"0dryf849xjr767zlpvg8wsy4fh4dl8gbca4l7a1yc47lgq1ffzsq"
else
"09ayb637cyf5x06xmhvad2znss7ak7r4n8z3wq7qmn0pmjdsa5a3";
"1y0xawsm9qsk0js6p6n5g5yy24kh2kn1kbmsla59g204l6xwsla1";
};
nativeBuildInputs = [ unzip ];

6
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/standalone.nix
View File

@ -50,7 +50,7 @@
stdenv.mkDerivation {
pname = "flashplayer-standalone";
version = "32.0.0.445";
version = "32.0.0.453";
src = fetchurl {
url =
@ -60,9 +60,9 @@ stdenv.mkDerivation {
"https://fpdownload.macromedia.com/pub/flashplayer/updaters/32/flash_player_sa_linux.x86_64.tar.gz";
sha256 =
if debug then
"0iqmdd222mjsf3rdbcm4z974i5q9y4i5agnhn039k0hpydi4zdcr"
"1qnmr8y9rzb8f9j4pn0cr7nxrdfn1pqkwfrzq8rf3nw9np4lxyfv"
else
"07vz17zhwh31phccpbmwgfa3fdb2f7bnc3sf66ipsw1xcqgncpsx";
"0s0xcbha72y0wybnmalgsx7nv3b9jcwv7p3rakj6ij9l1wf73b7g";
};
nativeBuildInputs = [ unzip ];

4
pkgs/applications/networking/browsers/ungoogled-chromium/plugins.nix
View File

@ -44,11 +44,11 @@ let
flash = stdenv.mkDerivation rec {
pname = "flashplayer-ppapi";
version = "32.0.0.445";
version = "32.0.0.453";
src = fetchzip {
url = "https://fpdownload.adobe.com/pub/flashplayer/pdc/${version}/flash_player_ppapi_linux.x86_64.tar.gz";
sha256 = "1r9vd210d2qp501q40pjx60mzah08rg0f8jk5rpp52ddajwggalv";
sha256 = "1d0hxn6snvx15clhcwncw40z0mf5p1pw68wrp7w1l3jkkw4brsgj";
stripRoot = false;
};

5
pkgs/applications/networking/p2p/opentracker/default.nix
View File

@ -11,6 +11,11 @@ stdenv.mkDerivation {
buildInputs = [ libowfat zlib ];
makeFlags = [
"LIBOWFAT_HEADERS=${libowfat}/include/libowfat"
"LIBOWFAT_LIBRARY=${libowfat}/lib"
];
installPhase = ''
runHook preInstall
install -D opentracker $out/bin/opentracker

6
pkgs/applications/terminal-emulators/guake/default.nix
View File

@ -1,7 +1,7 @@
{ stdenv
, fetchFromGitHub
, python3
, gettext
, glibcLocales
, gobject-introspection
, wrapGAppsHook
, gtk3
@ -31,13 +31,13 @@ python3.pkgs.buildPythonApplication rec {
strictDeps = false;
nativeBuildInputs = [
gettext
gobject-introspection
wrapGAppsHook
python3.pkgs.pip
];
buildInputs = [
glibcLocales
gtk3
keybinder3
libnotify
@ -46,6 +46,8 @@ python3.pkgs.buildPythonApplication rec {
vte
];
makeWrapperArgs = [ "--set LOCALE_ARCHIVE ${glibcLocales}/lib/locale/locale-archive" ];
propagatedBuildInputs = with python3.pkgs; [
dbus-python
pbr

8
pkgs/desktops/gnome-3/extensions/caffeine/default.nix
View File

@ -1,14 +1,14 @@
{ stdenv, fetchFromGitHub, glib, gettext, bash, gnome3 }:
stdenv.mkDerivation rec {
pname = "gnome-shell-extension-caffeine-unstable";
version = "2020-03-13";
pname = "gnome-shell-extension-caffeine";
version = "37";
src = fetchFromGitHub {
owner = "eonpatapon";
repo = "gnome-shell-extension-caffeine";
rev = "f25fa5cd586271f080c2304d0ad1273b55e864f5";
sha256 = "12a76g1ydw677pjnj00r3vw31k4xybc63ynqzx3s4g0wi6lipng7";
rev = "v${version}";
sha256 = "1mpa0fbpmv3pblb20dxj8iykn4ayvx89qffpcs67bzlq597zsbkb";
};
uuid = "caffeine@patapon.info";

4
pkgs/development/compilers/nim/default.nix
View File

@ -4,10 +4,10 @@
, pcre, readline, boehmgc, sqlite, nim-unwrapped, nimble-unwrapped }:
let
version = "1.4.0";
version = "1.4.2";
src = fetchurl {
url = "https://nim-lang.org/download/nim-${version}.tar.xz";
sha256 = "0gf2lqkqzai6mg7mf4y04gdy1ddiavans09i8aisa88ssfza5ywx";
sha256 = "0q8i56343b69f1bh48a8vxkqman9i2kscyj0lf017n3xfy1pb903";
};
meta = with lib; {

30
pkgs/development/compilers/tvm/default.nix Normal file
View File

@ -0,0 +1,30 @@
{ stdenv, fetchFromGitHub, cmake }:
stdenv.mkDerivation rec {
pname = "tvm";
version = "0.7.0";
src = fetchFromGitHub {
owner = "apache";
repo = "incubator-tvm";
rev = "v${version}";
fetchSubmodules = true;
sha256 = "0qflpd3lw0jslyk5lqpv2v42lkqs8mkvnn6i3fdms32iskdfk6p5";
};
nativeBuildInputs = [ cmake ];
# TVM CMake build uses some sources in the project's ./src/target/opt/
# directory which errneously gets mangled by the eager `fixCmakeFiles`
# function in Nix's CMake setup-hook.sh to ./src/target/var/empty/,
# which then breaks the build. Toggling this flag instructs Nix to
# not mangle the legitimate use of the opt/ folder.
dontFixCmake = true;
meta = with stdenv.lib; {
homepage = "https://tvm.apache.org/";
description = "An End to End Deep Learning Compiler Stack for CPUs, GPUs and accelerators";
license = licenses.asl20;
platforms = platforms.all;
maintainers = with maintainers; [ adelbertc ];
};
}

68
pkgs/development/interpreters/tclreadline/default.nix Normal file
View File

@ -0,0 +1,68 @@
{ stdenv
, fetchFromGitHub
, automake
, autoconf
, libtool
, readline
, tcl
, tk
}:
stdenv.mkDerivation rec {
pname = "tclreadline";
version = "2.3.8";
src = fetchFromGitHub {
owner = "flightaware";
repo = "tclreadline";
rev = "v${version}";
sha256 = "18jl56p0hwgynxpvr0v7b5mvvzc1m64fn61c0957bgb45mc250yq";
};
nativeBuildInputs = [
automake
autoconf
libtool
];
buildInputs = [
readline
tcl
tk
];
preConfigure = "NOCONFIGURE=1 ./autogen.sh";
configureFlags = [
"--enable-tclshrl"
"--enable-wishrl"
"--with-tcl=${tcl}/lib"
"--with-tk=${tk}/lib"
"--with-readline-includes=${readline.dev}/include/readline"
"--with-libtool=${libtool}"
];
# The provided makefile leaves a wrong reference to /build/ in RPATH,
# so we fix it after checking that everything is also present in $out
preFixup = stdenv.lib.optionalString stdenv.isLinux ''
needed_libraries=$(ls .libs | grep '\.\(so\|la\)$')
for lib in $needed_libraries; do
if ! ls $out/lib | grep "$lib"; then
echo "$lib was not installed correctly"
exit 1
fi
done
for executable in $out/bin/{wishrl,tclshrl}; do
patchelf --set-rpath \
"$(patchelf --print-rpath "$executable" | sed "s@$builddir/.libs@$out/lib@")" \
"$executable"
done
'';
meta = with stdenv.lib; {
description = "GNU readline for interactive tcl shells";
homepage = "https://github.com/flightaware/tclreadline";
license = licenses.bsd3;
maintainers = with maintainers; [ fgaz ];
platforms = platforms.all;
};
}

5
pkgs/development/libraries/gnutls/default.nix
View File

@ -34,7 +34,10 @@ stdenv.mkDerivation {
patches = [ ./nix-ssl-cert-file.patch ]
# Disable native add_system_trust.
++ lib.optional (isDarwin && !withSecurity) ./no-security-framework.patch;
++ lib.optional (isDarwin && !withSecurity) ./no-security-framework.patch
# fix gnulib tests on 32-bit ARM. Included on gnutls master.
# https://lists.gnu.org/r/bug-gnulib/2020-08/msg00225.html
++ lib.optional stdenv.hostPlatform.isAarch32 ./fix-gnulib-tests-arm.patch;
# Skip some tests:
# - pkgconfig: building against the result won't work before installing (3.5.11)

45
pkgs/development/libraries/gnutls/fix-gnulib-tests-arm.patch Normal file
View File

@ -0,0 +1,45 @@
>From 175e0bc72808d564074c4adcc72aeadb74adfcc6 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 27 Aug 2020 17:52:58 -0700
Subject: [PATCH] perror, strerror_r: remove unportable tests
Problem reported by Florian Weimer in:
https://lists.gnu.org/r/bug-gnulib/2020-08/msg00220.html
* tests/test-perror2.c (main):
* tests/test-strerror_r.c (main): Omit unportable tests.
---
tests/test-perror2.c | 3 ---
tests/test-strerror_r.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/gl/tests/test-perror2.c b/gl/tests/test-perror2.c
index 1d14eda7b..c6214dd25 100644
--- a/gl/tests/test-perror2.c
+++ b/gl/tests/test-perror2.c
@@ -79,9 +79,6 @@ main (void)
errno = -5;
perror ("");
ASSERT (!ferror (stderr));
- ASSERT (msg1 == msg2 || msg1 == msg4 || STREQ (msg1, str1));
- ASSERT (msg2 == msg4 || STREQ (msg2, str2));
- ASSERT (msg3 == msg4 || STREQ (msg3, str3));
ASSERT (STREQ (msg4, str4));
free (str1);
diff --git a/gl/tests/test-strerror_r.c b/gl/tests/test-strerror_r.c
index b11d6fd9f..c1dbcf837 100644
--- a/gl/tests/test-strerror_r.c
+++ b/gl/tests/test-strerror_r.c
@@ -165,9 +165,6 @@ main (void)
strerror_r (EACCES, buf, sizeof buf);
strerror_r (-5, buf, sizeof buf);
- ASSERT (msg1 == msg2 || msg1 == msg4 || STREQ (msg1, str1));
- ASSERT (msg2 == msg4 || STREQ (msg2, str2));
- ASSERT (msg3 == msg4 || STREQ (msg3, str3));
ASSERT (STREQ (msg4, str4));
free (str1);
--
2.17.1

11
pkgs/development/libraries/libowfat/default.nix
View File

@ -8,17 +8,6 @@ stdenv.mkDerivation rec {
sha256 = "1hcqg7pvy093bxx8wk7i4gvbmgnxz2grxpyy7b4mphidjbcv7fgl";
};
# Dirty patch because 0.32 "moved headers to <libowfat/> upon install"
# but it breaks gatling-0.15 and opentracker-2018-05-26 ...
postPatch = ''
substituteInPlace GNUmakefile --replace \
'install -d $(DESTDIR)$(INCLUDEDIR)/libowfat' \
'install -d $(DESTDIR)$(INCLUDEDIR)'
substituteInPlace GNUmakefile --replace \
'install -m 644 $(INCLUDES) $(DESTDIR)$(INCLUDEDIR)/libowfat' \
'install -m 644 $(INCLUDES) $(DESTDIR)$(INCLUDEDIR)'
'';
makeFlags = [ "prefix=$(out)" ];
enableParallelBuilding = true;

13
pkgs/development/libraries/ngt/default.nix
View File

@ -1,15 +1,20 @@
{ stdenv, fetchFromGitHub, cmake }:
{ stdenv, fetchFromGitHub, cmake, llvmPackages, enableAVX ? false }:
stdenv.mkDerivation rec {
pname = "NGT";
version = "v1.8.4";
version = "v1.12.3-alpha";
nativeBuildInputs = [ cmake ];
src = fetchFromGitHub {
owner = "yahoojapan";
repo = "NGT";
rev = version;
sha256 = "f2019e7916b81f8aeabc57d682904c8447776bf9ba94525d20265b329aa43eb5";
rev = "29c88ff6cd5824d3196986d1f50b834565b6c9dd";
sha256 = "sha256-nu0MJNpaenOB4+evoSVLKmPIuZXVj1Rm9x53+TfhezY=";
};
buildInputs = [ llvmPackages.openmp ];
NIX_ENFORCE_NO_NATIVE=! enableAVX;
__AVX2__ = if enableAVX then 1 else 0;
enableParallelBuilding = true;
meta = with stdenv.lib; {

11
pkgs/development/python-modules/hjson/default.nix
View File

@ -1,6 +1,8 @@
{ stdenv
, buildPythonPackage
, fetchFromGitHub
, pythonImportsCheckHook
, makeWrapper
}:
buildPythonPackage rec {
@ -15,6 +17,15 @@ buildPythonPackage rec {
sha256 = "1jc7j790rcqnhbrfj4lhnz3f6768dc55aij840wmx16jylfqpc2n";
};
nativeBuildInputs = [ makeWrapper pythonImportsCheckHook ];
pythonImportsCheck = [ "hjson" ];
postInstall = ''
rm $out/bin/hjson.cmd
wrapProgram $out/bin/hjson --set PYTHONPATH "$PYTHONPATH"
'';
meta = with stdenv.lib; {
description = "A user interface for JSON";
homepage = "https://github.com/hjson/hjson-py";

10
pkgs/development/python-modules/poetry/default.nix
View File

@ -88,6 +88,16 @@ buildPythonPackage rec {
"test_builder_should_execute_build_scripts"
];
patches = [
# The following patch addresses a minor incompatibility with
# pytest-mock. This is addressed upstream in
# https://github.com/python-poetry/poetry/pull/3457
(fetchpatch {
url = "https://github.com/python-poetry/poetry/commit/8ddceb7c52b3b1f35412479707fa790e5d60e691.diff";
sha256 = "yHjFb9xJBLFOqkOZaJolKviTdtST9PMFwH9n8ud2Y+U=";
})
];
meta = with lib; {
homepage = "https://python-poetry.org/";
description = "Python dependency management and packaging made easy";

29
pkgs/development/python-modules/pyxdg/default.nix
View File

@ -1,30 +1,25 @@
{ stdenv
{ lib
, buildPythonPackage
, fetchPypi
, fetchpatch
, fetchFromGitLab
, nose
}:
buildPythonPackage rec {
pname = "pyxdg";
version = "0.26";
version = "0.27";
src = fetchPypi {
inherit pname version;
sha256 = "fe2928d3f532ed32b39c32a482b54136fe766d19936afc96c8f00645f9da1a06";
src = fetchFromGitLab {
domain = "gitlab.freedesktop.org";
owner = "xdg";
repo = pname;
rev = "rel-${version}";
sha256 = "1dg826vrc7ifkk4lnf648h61cqfamaqmngkn9hgmxnf9gqmkbn0k";
};
# error: invalid command 'test'
# Tests failed (errors=4, failures=4) on NixOS
doCheck = false;
patches = [
# see: https://gitlab.freedesktop.org/xdg/pyxdg/-/merge_requests/5
(fetchpatch {
url = "https://gitlab.freedesktop.org/xdg/pyxdg/-/commit/78405aaa34463db2c6f33ca28ae2293dd3bb1e91.patch";
sha256 = "17cjax546rkqv5kvwczjqjdd6vmlvcxjanz0296dlfq23j2wbx63";
})
];
meta = with stdenv.lib; {
meta = with lib; {
homepage = "http://freedesktop.org/wiki/Software/pyxdg";
description = "Contains implementations of freedesktop.org standards";
license = licenses.lgpl2;

22
pkgs/development/tools/gojsontoyaml/default.nix Normal file
View File

@ -0,0 +1,22 @@
{ stdenv, buildGoModule, fetchFromGitHub }:
buildGoModule rec {
pname = "gojsontoyaml";
version = "unstable-2020-06-02";
src = fetchFromGitHub {
owner = "brancz";
repo = "gojsontoyaml";
rev = "3697ded27e8cfea8e547eb082ebfbde36f1b5ee6";
sha256 = "07sisadpfnzbylzirs5ski8wl9fl18dm7xhbv8imw6ksxq4v467a";
};
vendorSha256 = null;
meta = with stdenv.lib; {
description = "Simply tool to convert json to yaml written in Go";
homepage = "https://github.com/brancz/gojsontoyaml";
license = licenses.mit;
maintainers = [ maintainers.bryanasdev000 ];
};
}

35
pkgs/development/tools/misc/perfect-hash/default.nix Normal file
View File

@ -0,0 +1,35 @@
{ stdenv, python3, fetchFromGitHub }:
python3.pkgs.buildPythonApplication rec {
pname = "perfect-hash";
version = "0.4.1";
# Archive on pypi does not contain examples, which are very helpful to
# understand how to use this program, so we use git source.
src = fetchFromGitHub {
owner = "ilanschnell";
repo = "perfect-hash";
rev = version;
sha256 = "0gkc3n613hl0q4jknrh2nm1n96j97p36q9jjgarb9d8yii9q7792";
};
postInstall = ''
mkdir -p $out/share/doc/perfect-hash
cp README.md $out/share/doc/perfect-hash
cp -r examples $out/share/doc/perfect-hash
'';
meta = with stdenv.lib; {
description = "Minimal perfect hash function generator";
longDescription = ''
Generate a minimal perfect hash function for a given set of keys.
A given code template is filled with parameters, such that the
output is code which implements the hash function. Templates can
easily be constructed for any programming language.
'';
license = licenses.bsd3;
maintainers = [ maintainers.kaction ];
homepage = "https://github.com/ilanschnell/perfect-hash";
platforms = platforms.unix;
};
}

26
pkgs/development/tools/pandoc/default.nix
View File

@ -1,4 +1,4 @@
{ haskellPackages, haskell, removeReferencesTo }:
{ haskellPackages, fetchpatch, haskell, removeReferencesTo }:
let
static = haskell.lib.justStaticExecutables haskellPackages.pandoc;
@ -8,6 +8,30 @@ in
configureFlags = drv.configureFlags or [] ++ ["-fembed_data_files"];
buildDepends = drv.buildDepends or [] ++ [haskellPackages.file-embed];
buildTools = (drv.buildTools or []) ++ [ removeReferencesTo ];
patches = (drv.patches or []) ++ [
# Add xmlns to top-level tags in Docbook, required for nixpkgs manual.
# https://github.com/jgm/pandoc/pull/6923
(fetchpatch {
url = "https://github.com/jgm/pandoc/commit/6f35600204132c5a0907bb7cccb2e10ffb27506a.patch";
sha256 = "gRUqc4YG4lZdCZn21fPmlcrFyZ3/VlDx71lU8GMuGSs=";
})
# Generate admonitions in DocBook, required for nixpkgs manual.
# https://github.com/jgm/pandoc/pull/6922
(fetchpatch {
url = "https://github.com/jgm/pandoc/commit/dc6856530c2cb6ca58ed82721ab895b86cfe0c1c.patch";
sha256 = "EdsUDlHzsfRscXBR4EP2Z5ZEz+NfrmFHnV7c1hJczio=";
})
# Use correct id attributes in DocBook, required for nixpkgs manual.
(fetchpatch {
url = "https://github.com/jgm/pandoc/commit/16ef87745702f69d5aa948fbe6d2101577dee8f4.patch";
sha256 = "WyWTqrO6hGsMgJ7o7QL1BNvhkm0yIO1XJOcfPBDy6ag=";
})
# Allow using admonition titles from Markdown in DocBook.
(fetchpatch {
url = "https://github.com/jgm/pandoc/commit/70c7c5703afcbd1cbf2a80c2be515e038abcd419.patch";
sha256 = "2kHQ1qy/UdDi/chwCBvMjAPA/XFH42vWFCjR46Jgt6M=";
})
];
})).overrideAttrs (drv: {
# These libraries are still referenced, because they generate

24
pkgs/development/web/kore/default.nix
View File

@ -1,19 +1,31 @@
{ stdenv, fetchFromGitHub, openssl }:
{ stdenv, fetchFromGitHub, openssl, curl, postgresql, yajl }:
stdenv.mkDerivation rec {
pname = "kore";
version = "3.3.1";
version = "4.0.1";
src = fetchFromGitHub {
owner = "jorisvink";
repo = pname;
rev = "${version}-release";
sha256 = "0jlvry9p1f7284cscfsg04ngbaq038yx3nz815jcr5s3d2jzps3h";
rev = version;
sha256 = "0186lih30zps2d4600ikafbgsml269jzpcszdggzzkdw8p628qw9";
};
buildInputs = [ openssl ];
buildInputs = [ openssl curl postgresql yajl ];
makeFlags = [ "PREFIX=${placeholder "out"}" ];
makeFlags = [
"PREFIX=${placeholder "out"}"
"ACME=1"
"CURL=1"
"TASKS=1"
"PGSQL=1"
"JSONRPC=1"
"DEBUG=1"
];
preBuild = ''
make platform.h
'';
# added to fix build w/gcc7 and clang5
NIX_CFLAGS_COMPILE = stdenv.lib.optionalString stdenv.cc.isGNU "-Wno-error=pointer-compare"

53
pkgs/games/sauerbraten/default.nix
View File

@ -1,50 +1,43 @@
{ stdenv, fetchsvn, SDL2, SDL2_image, SDL2_mixer
, zlib, runtimeShell
{ stdenv, fetchzip, SDL2, SDL2_image, SDL2_mixer
, zlib, makeWrapper
}:
stdenv.mkDerivation rec {
name = "sauerbraten-r${version}";
version = "5492";
pname = "sauerbraten";
version = "2020-12-04";
src = fetchsvn {
url = "https://svn.code.sf.net/p/sauerbraten/code";
sha256 = "0pin7ggy84fadjvran18db5v0l81qfv42faknpfaxx47xqz00l5s";
rev = version;
src = fetchzip {
url = "mirror://sourceforge/sauerbraten/sauerbraten_${builtins.replaceStrings [ "-" ] [ "_" ] version}_linux.tar.bz2";
sha256 = "1hknwpnvsakz6s7l7j1r5aqmgrzp4wcbn8yg8nxmvsddbhxdj1kc";
};
nativeBuildInputs = [
makeWrapper
];
buildInputs = [
SDL2 SDL2_mixer SDL2_image
zlib
];
preBuild = ''
export NIX_LDFLAGS="$NIX_LDFLAGS -lX11"
pushd src
'';
sourceRoot = "source/src";
installPhase = ''
popd
mkdir -p $out/bin $out/share/sauerbraten $out/share/doc/sauerbraten
cp -rv "docs/"* $out/share/doc/sauerbraten/
cp -v src/sauer_client src/sauer_server $out/share/sauerbraten/
cp -rv packages $out/share/sauerbraten/
cp -rv data $out/share/sauerbraten/
cat > $out/bin/sauerbraten_server <<EOF
#!${runtimeShell}
cd $out/share/sauerbraten
./sauer_server "\$@"
EOF
cat > $out/bin/sauerbraten_client <<EOF
#!${runtimeShell}
cd $out/share/sauerbraten
./sauer_client "\$@"
EOF
chmod a+x $out/bin/sauerbraten_*
cp -rv "../docs/"* $out/share/doc/sauerbraten/
cp -v sauer_client sauer_server $out/share/sauerbraten/
cp -rv ../packages ../data $out/share/sauerbraten/
makeWrapper $out/share/sauerbraten/sauer_server $out/bin/sauerbraten_server \
--run "cd $out/share/sauerbraten"
makeWrapper $out/share/sauerbraten/sauer_client $out/bin/sauerbraten_client \
--run "cd $out/share/sauerbraten" \
--add-flags "-q\''${HOME}"
'';
meta = with stdenv.lib; {
description = "";
maintainers = [ maintainers.raskin ];
description = "A free multiplayer & singleplayer first person shooter, the successor of the Cube FPS";
maintainers = with maintainers; [ raskin ajs124 ];
hydraPlatforms =
# raskin: tested amd64-linux;
# not setting platforms because it is 0.5+ GiB of game data

41
pkgs/os-specific/linux/kernel/linux-rt-5.9.nix Normal file
View File

@ -0,0 +1,41 @@
{ lib, buildLinux, fetchurl
, kernelPatches ? [ ]
, structuredExtraConfig ? {}
, extraMeta ? {}
, argsOverride ? {}
, ... } @ args:
let
version = "5.9.1-rt20"; # updated by ./update-rt.sh
branch = lib.versions.majorMinor version;
kversion = builtins.elemAt (lib.splitString "-" version) 0;
in buildLinux (args // {
inherit version;
src = fetchurl {
url = "mirror://kernel/linux/kernel/v5.x/linux-${kversion}.tar.xz";
sha256 = "0dn0xz81pphca5dkg6zh8c78p05f63rrr5ihqqsmhc4n73li2jms";
};
kernelPatches = let rt-patch = {
name = "rt";
patch = fetchurl {
url = "mirror://kernel/linux/kernel/projects/rt/${branch}/older/patch-${version}.patch.xz";
sha256 = "0ma3mv475qgg0dri4928gi6z00d7s59pdwj0d6dh0mfzs2xddnyv";
};
}; in [ rt-patch ] ++ lib.remove rt-patch kernelPatches;
structuredExtraConfig = with lib.kernel; {
PREEMPT_RT = yes;
# Fix error: unused option: PREEMPT_RT.
EXPERT = yes; # PREEMPT_RT depends on it (in kernel/Kconfig.preempt)
# Fix error: option not set correctly: PREEMPT_VOLUNTARY (wanted 'y', got 'n').
PREEMPT_VOLUNTARY = lib.mkForce no; # PREEMPT_RT deselects it.
# Fix error: unused option: RT_GROUP_SCHED.
RT_GROUP_SCHED = lib.mkForce (option no); # Removed by sched-disable-rt-group-sched-on-rt.patch.
} // structuredExtraConfig;
extraMeta = extraMeta // {
inherit branch;
};
} // argsOverride)

8
pkgs/servers/http/gatling/default.nix
View File

@ -1,7 +1,7 @@
{ stdenv, fetchurl, libowfat, zlib, openssl }:
{ stdenv, fetchurl, libowfat, libcap, zlib, openssl }:
let
version = "0.15";
version = "0.16";
in
stdenv.mkDerivation rec {
pname = "gatling";
@ -9,10 +9,10 @@ stdenv.mkDerivation rec {
src = fetchurl {
url = "https://www.fefe.de/gatling/${pname}-${version}.tar.xz";
sha256 = "194srqyja3pczpbl6l169zlvx179v7ln0m6yipmhvj6hrv82k8vg";
sha256 = "0nrnws5qrl4frqcsfa9z973vv5mifgr9z170qbvg3mq1wa7475jz";
};
buildInputs = [ libowfat zlib openssl.dev ];
buildInputs = [ libowfat libcap zlib openssl.dev ];
configurePhase = ''
substituteInPlace Makefile --replace "/usr/local" "$out"

5
pkgs/tools/misc/coreutils/default.nix
View File

@ -31,7 +31,10 @@ stdenv.mkDerivation (rec {
patches = optional stdenv.hostPlatform.isCygwin ./coreutils-8.23-4.cygwin.patch
# included on coreutils master; TODO: apply unconditionally, I guess
++ optional stdenv.hostPlatform.isAarch64 ./sys-getdents-undeclared.patch;
++ optional stdenv.hostPlatform.isAarch64 ./sys-getdents-undeclared.patch
# fix gnulib tests on 32-bit ARM. Included on coreutils master.
# https://lists.gnu.org/r/bug-gnulib/2020-08/msg00225.html
++ optional stdenv.hostPlatform.isAarch32 ./fix-gnulib-tests-arm.patch;
postPatch = ''
# The test tends to fail on btrfs,f2fs and maybe other unusual filesystems.

45
pkgs/tools/misc/coreutils/fix-gnulib-tests-arm.patch Normal file
View File

@ -0,0 +1,45 @@
>From 175e0bc72808d564074c4adcc72aeadb74adfcc6 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 27 Aug 2020 17:52:58 -0700
Subject: [PATCH] perror, strerror_r: remove unportable tests
Problem reported by Florian Weimer in:
https://lists.gnu.org/r/bug-gnulib/2020-08/msg00220.html
* tests/test-perror2.c (main):
* tests/test-strerror_r.c (main): Omit unportable tests.
---
tests/test-perror2.c | 3 ---
tests/test-strerror_r.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/gnulib-tests/test-perror2.c b/gnulib-tests/test-perror2.c
index 1d14eda7b..c6214dd25 100644
--- a/gnulib-tests/test-perror2.c
+++ b/gnulib-tests/test-perror2.c
@@ -79,9 +79,6 @@ main (void)
errno = -5;
perror ("");
ASSERT (!ferror (stderr));
- ASSERT (msg1 == msg2 || msg1 == msg4 || STREQ (msg1, str1));
- ASSERT (msg2 == msg4 || STREQ (msg2, str2));
- ASSERT (msg3 == msg4 || STREQ (msg3, str3));
ASSERT (STREQ (msg4, str4));
free (str1);
diff --git a/gnulib-tests/test-strerror_r.c b/gnulib-tests/test-strerror_r.c
index b11d6fd9f..c1dbcf837 100644
--- a/gnulib-tests/test-strerror_r.c
+++ b/gnulib-tests/test-strerror_r.c
@@ -165,9 +165,6 @@ main (void)
strerror_r (EACCES, buf, sizeof buf);
strerror_r (-5, buf, sizeof buf);
- ASSERT (msg1 == msg2 || msg1 == msg4 || STREQ (msg1, str1));
- ASSERT (msg2 == msg4 || STREQ (msg2, str2));
- ASSERT (msg3 == msg4 || STREQ (msg3, str3));
ASSERT (STREQ (msg4, str4));
free (str1);
--
2.17.1

7
pkgs/tools/misc/findutils/default.nix
View File

@ -20,9 +20,10 @@ stdenv.mkDerivation rec {
substituteInPlace xargs/xargs.c --replace 'char default_cmd[] = "echo";' 'char default_cmd[] = "${coreutils}/bin/echo";'
'';
patches = [
./no-install-statedir.patch
];
patches = [ ./no-install-statedir.patch ]
# fix gnulib tests on 32-bit ARM. Included on findutils master.
# https://lists.gnu.org/r/bug-gnulib/2020-08/msg00225.html
++ stdenv.lib.optional stdenv.hostPlatform.isAarch32 ./fix-gnulib-tests-arm.patch;
buildInputs = [ coreutils ]; # bin/updatedb script needs to call sort

45
pkgs/tools/misc/findutils/fix-gnulib-tests-arm.patch Normal file
View File

@ -0,0 +1,45 @@
>From 175e0bc72808d564074c4adcc72aeadb74adfcc6 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 27 Aug 2020 17:52:58 -0700
Subject: [PATCH] perror, strerror_r: remove unportable tests
Problem reported by Florian Weimer in:
https://lists.gnu.org/r/bug-gnulib/2020-08/msg00220.html
* tests/test-perror2.c (main):
* tests/test-strerror_r.c (main): Omit unportable tests.
---
tests/test-perror2.c | 3 ---
tests/test-strerror_r.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/gnulib-tests/test-perror2.c b/gnulib-tests/test-perror2.c
index 1d14eda7b..c6214dd25 100644
--- a/gnulib-tests/test-perror2.c
+++ b/gnulib-tests/test-perror2.c
@@ -79,9 +79,6 @@ main (void)
errno = -5;
perror ("");
ASSERT (!ferror (stderr));
- ASSERT (msg1 == msg2 || msg1 == msg4 || STREQ (msg1, str1));
- ASSERT (msg2 == msg4 || STREQ (msg2, str2));
- ASSERT (msg3 == msg4 || STREQ (msg3, str3));
ASSERT (STREQ (msg4, str4));
free (str1);
diff --git a/gnulib-tests/test-strerror_r.c b/gnulib-tests/test-strerror_r.c
index b11d6fd9f..c1dbcf837 100644
--- a/gnulib-tests/test-strerror_r.c
+++ b/gnulib-tests/test-strerror_r.c
@@ -165,9 +165,6 @@ main (void)
strerror_r (EACCES, buf, sizeof buf);
strerror_r (-5, buf, sizeof buf);
- ASSERT (msg1 == msg2 || msg1 == msg4 || STREQ (msg1, str1));
- ASSERT (msg2 == msg4 || STREQ (msg2, str2));
- ASSERT (msg3 == msg4 || STREQ (msg3, str3));
ASSERT (STREQ (msg4, str4));
free (str1);
--
2.17.1

30
pkgs/tools/misc/pfsshell/default.nix Normal file
View File

@ -0,0 +1,30 @@
{ stdenv, fetchFromGitHub, meson, ninja }:
stdenv.mkDerivation rec {
version = "1.1.1";
pname = "pfsshell";
src = fetchFromGitHub {
owner = "uyjulian";
repo = "pfsshell";
rev = "v${version}";
sha256 = "0cr91al3knsbfim75rzl7rxdsglcc144x0nizn7q4jx5cad3zbn8";
};
nativeBuildInputs = [ meson ninja ];
# Build errors since 1.1.1 when format hardening is enabled:
# cc1: error: '-Wformat-security' ignored without '-Wformat' [-Werror=format-security]
hardeningDisable = [ "format" ];
meta = with stdenv.lib; {
inherit (src.meta) homepage;
description = "PFS (PlayStation File System) shell for POSIX-based systems";
platforms = platforms.unix;
license = with licenses; [
gpl2Only # the pfsshell software itself
afl20 # APA, PFS, and iomanX libraries which are compiled together with this package
];
maintainers = with maintainers; [ makefu ];
};
}

16
pkgs/tools/security/clamav/default.nix
View File

@ -1,6 +1,6 @@
{ stdenv, fetchurl, pkgconfig
{ stdenv, fetchurl, pkg-config
, zlib, bzip2, libiconv, libxml2, openssl, ncurses, curl, libmilter, pcre2
, libmspack, systemd, Foundation
, libmspack, systemd, Foundation, json_c, check
}:
stdenv.mkDerivation rec {
@ -17,9 +17,10 @@ stdenv.mkDerivation rec {
substituteInPlace Makefile.in --replace ' etc ' ' '
'';
nativeBuildInputs = [ pkgconfig ];
enableParallelBuilding = true;
nativeBuildInputs = [ pkg-config ];
buildInputs = [
zlib bzip2 libxml2 openssl ncurses curl libiconv libmilter pcre2 libmspack
zlib bzip2 libxml2 openssl ncurses curl libiconv libmilter pcre2 libmspack json_c check
] ++ stdenv.lib.optional stdenv.isLinux systemd
++ stdenv.lib.optional stdenv.isDarwin Foundation;
@ -31,8 +32,11 @@ stdenv.mkDerivation rec {
"--with-xml=${libxml2.dev}"
"--with-openssl=${openssl.dev}"
"--with-libcurl=${curl.dev}"
"--with-libjson=${json_c.dev}"
"--with-system-libmspack"
"--enable-milter"
"--disable-unrar" # disable unrar because it's non-free and requires some extra patching to work properly
"--enable-check"
] ++ stdenv.lib.optional stdenv.isLinux
"--with-systemdsystemunitdir=$(out)/lib/systemd";
@ -41,6 +45,10 @@ stdenv.mkDerivation rec {
cp etc/*.sample $out/etc
'';
# Only required for the unit tests
hardeningDisable = [ "format" ];
doCheck = true;
meta = with stdenv.lib; {
homepage = "https://www.clamav.net";
description = "Antivirus engine designed for detecting Trojans, viruses, malware and other malicious threats";

6
pkgs/tools/text/pbgopy/default.nix
View File

@ -2,16 +2,16 @@
buildGoModule rec {
pname = "pbgopy";
version = "0.1.1";
version = "0.2.0";
src = fetchFromGitHub {
owner = "nakabonne";
repo = pname;
rev = "v${version}";
sha256 = "17rk15hs7kg9m1vphh1gjny7sqnk80qw61jn8qyxcmw2n55rkmfp";
sha256 = "0impgx9w9lk93b7p1vhjnbslr04655fn6csx7hj04kffzhyb3p1q";
};
vendorSha256 = "1ak3hd979395grbns9p5sw5f45plcqq6vg7j7v8n7xqc20s2l8m9";
vendorSha256 = "09hn92bi2rmixpsgckbi8f70widls40fwqqm7y7rqglyjqi7rdmw";
meta = with stdenv.lib; {
description = "Copy and paste between devices";

31
pkgs/top-level/all-packages.nix
View File

@ -1228,6 +1228,8 @@ in
goimapnotify = callPackage ../tools/networking/goimapnotify { };
gojsontoyaml = callPackage ../development/tools/gojsontoyaml { };
gomatrix = callPackage ../applications/misc/gomatrix { };
gopacked = callPackage ../applications/misc/gopacked { };
@ -2576,6 +2578,8 @@ in
socklog = callPackage ../tools/system/socklog { };
spacevim = callPackage ../applications/editors/spacevim { };
ssmsh = callPackage ../tools/admin/ssmsh { };
stagit = callPackage ../development/tools/stagit { };
@ -7862,6 +7866,8 @@ in
turses = callPackage ../applications/networking/instant-messengers/turses { };
tvm = callPackage ../development/compilers/tvm { };
oysttyer = callPackage ../applications/networking/instant-messengers/oysttyer { };
twilight = callPackage ../tools/graphics/twilight {
@ -10777,6 +10783,8 @@ in
tcl-8_5 = callPackage ../development/interpreters/tcl/8.5.nix { };
tcl-8_6 = callPackage ../development/interpreters/tcl/8.6.nix { };
tclreadline = callPackage ../development/interpreters/tclreadline { };
wasm = ocamlPackages.wasm;
proglodyte-wasm = callPackage ../development/interpreters/proglodyte-wasm { };
@ -11827,6 +11835,8 @@ in
pax-rs = callPackage ../development/tools/pax-rs { };
perfect-hash = callPackage ../development/tools/misc/perfect-hash { };
peg = callPackage ../development/tools/parsing/peg { };
pgcli = pkgs.python3Packages.pgcli;
@ -18334,6 +18344,14 @@ in
];
};
linux-rt_5_9 = callPackage ../os-specific/linux/kernel/linux-rt-5.9.nix {
kernelPatches = [
kernelPatches.bridge_stp_helper
kernelPatches.request_key_helper
kernelPatches.export_kernel_fpu_functions."5.3"
];
};
linux_testing = callPackage ../os-specific/linux/kernel/linux-testing.nix {
kernelPatches = [
kernelPatches.bridge_stp_helper
@ -18583,10 +18601,11 @@ in
# Realtime kernel packages.
linuxPackages-rt_5_4 = linuxPackagesFor pkgs.linux-rt_5_4;
linuxPackages-rt = linuxPackages-rt_5_4;
linux-rt = linuxPackages-rt.kernel;
linuxPackages-rt_5_6 = linuxPackagesFor pkgs.linux-rt_5_6;
linuxPackages-rt_latest = linuxPackages-rt_5_6;
linuxPackages-rt_5_9 = linuxPackagesFor pkgs.linux-rt_5_9;
linuxPackages-rt = linuxPackages-rt_5_4;
linuxPackages-rt_latest = linuxPackages-rt_5_9;
linux-rt = linuxPackages-rt.kernel;
linux-rt_latest = linuxPackages-rt_latest.kernel;
linuxPackages_mptcp = linuxPackagesFor pkgs.linux_mptcp;
@ -22059,6 +22078,8 @@ in
imgcat = callPackage ../applications/graphics/imgcat { };
img-cat = callPackage ../applications/graphics/img-cat { };
imgp = python3Packages.callPackage ../applications/graphics/imgp { };
# Impressive, formerly known as "KeyJNote".
@ -23094,7 +23115,7 @@ in
nedit = callPackage ../applications/editors/nedit { };
ngt = callPackage ../development/libraries/ngt { };
ngt = callPackage ../development/libraries/ngt { enableAVX = false; };
nheko = libsForQt5.callPackage ../applications/networking/instant-messengers/nheko { };
@ -23311,6 +23332,8 @@ in
pflask = callPackage ../os-specific/linux/pflask {};
pfsshell = callPackage ../tools/misc/pfsshell { };
photoqt = libsForQt5.callPackage ../applications/graphics/photoqt { };
photoflare = libsForQt5.callPackage ../applications/graphics/photoflare { };