pkgs.steam-run-native is defined as exactly the expression that
these instructions tell you to write, so the instruction is no
longer necessary since we can just tell you to use that.
The attributes got renamed in PR #126440 and in some places this caused
evaluation errors, e.g. the tarball job was saying (locally)
> attribute 'alsaUtils' missing, at /build/source/nixos/modules/services/audio/alsa.nix:6:4
and I suspect that trunk-combined jobset's failure to evaluate was also caused.
We are still using Pandoc’s Markdown parser, which differs from CommonMark spec slightly.
Notably:
- Line breaks in lists behave differently.
- Admonitions do not support the simpler syntax https://github.com/jgm/commonmark-hs/issues/75
- The auto_identifiers uses a different algorithm – I made the previous ones explicit.
- Languages (classes) of code blocks cannot contain whitespace so we have to use “pycon” alias instead of Python “console” as GitHub’s linguist
While at it, I also fixed the following issues:
- ShellSesssion was used
- Removed some pointless docbook tags.
The distinction between the inputs doesn't really make sense in the
mkShell context. Technically speaking, we should be using the
nativeBuildInputs most of the time.
So in order to make this function more beginner-friendly, add "packages"
as an attribute, that maps to nativeBuildInputs.
This commit also updates all the uses in nixpkgs.
It is now possible to pass a `fromImage` to `buildLayeredImage` and
`streamLayeredImage`, similar to what `buildImage` currently supports.
This will prepend the layers of the given base image to the resulting
image, while ensuring that at most `maxLayers` are used. It will also
ensure that environment variables from the base image are propagated
to the final image.
I used the existing anchors generated by Docbook, so the anchor part
should be a no-op. This could be useful depending on the
infrastructure we choose to use, and it is better to be explicit than
rely on Docbook's id generating algorithms.
I got rid of the metadata segments of the Markdown files, because they
are outdated, inaccurate, and could make people less willing to change
them without speaking with the author.
I did double-check that the fixed version does what we would want. In
either case, the katamari script is mostly of historical value, and
there's nothing to change in pkgs.
I tested the shell snippets shown here; they work. Note that, because
they're intended for copy-and-paste, I did *not* make them into
ShellSessions with prompts. But that's something I can do if desired.
This is essentially an automatic pandoc conversion of the weechat
section in docbook as part of the larger CommonMark Docs project
(https://github.com/NixOS/nixpkgs/projects/37)
fixes#105264
Update doc/builders/packages/weechat.section.md
Co-authored-by: Frederik Rietdijk <freddyrietdijk@fridh.nl>
Update doc/builders/packages/weechat.section.md
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
The previous implementation of plugin-support for the kakoune derivation
was based on generating, at build time, a `plugins.kak` file that would
source all .kak files in the list of plugins, and wrap the `kak` binary
in a script that would add some command-line arguments so that this
file gets loaded on start-up. The main problem with this approach
is that the plugins' code get executed *after* the user's configuration
file is loaded, so effectively one cannot automatically activate/configure
these plugins.
The idiomatic way of loading plugins is ensuring they end up installed
somwhere under `share/kak/autoload`. Because plugins are already being
packaged to have their code in `share/kak/autoload/plugins/<name-of-plugin>`,
we can obtain a derivation that includes the plugins simply by doing a
`symlinkJoin` of `kakoune-unwrapped` and all the requested plugins.
For this to work, we need to fix two issues:
1. By default, kakoune makes `share/kak/autoload` a symbolic link to
`share/kak/rc`, which contains all builtin definitions. We need
to patch this to put the symlink under `share/kak/autoload/rc`, so that
the join works.
2. By default kakoune expects the `autoload` directory to be in
`../share/kak/autoload` relative to the location of the `kak` binary.
We need to set the `KAKOUNE_RUNTIME` to point the symlinked
share/kak for this to work.
In #89806 it has been reported that the final package is missing a lot
of features like support for the self-service GUI and the
config-management.
While working on supporting those components in the Nix-package, I
decided to refactor the package to simplify the entire setup.
This patch changes the following things:
* Binaries and libraries are patched using the `autoPatchelfHook` to
avoid having unneeded libraries linked (e.g. some programs use gtk2,
others use gtk3).
* Moved source-declarations into their own file.
* Wrapped `configmgr` and `selfservice` and added those to `$out/bin`.
* Don't mention the old `citrix_receiver`-packages in the manual anymore
since those packages were removed in 19.09 and are EOLed anyways.
Closes#89806
We shouldn’t force the user to have a C compiler in scope, just
because the derivation is forced to build locally. That can’t be
counted as “lightweight” anymore.
Co-Authored-By: Silvan Mosberger<contact@infinisil.com>
This has the same motivation as fetchFromGitHub/fetchFromGitLab --
it's cheaper to download a tarball of a single revision than it is to
download a whole history.
I could have gone with domain/group/repo, like fetchFromGitLab, but it
would have made implementation more difficult, and this syntax means
it's a drop-in replacement for fetchgit, so I decided it wasn't worth
it.
In my opinion Functions should only contain pure functions. These are
both meant to provide derivations so I put them under Builders. Don't
know exactly *where* to put them so "special" it is...
