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...
