Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
In particular we move the src into the actual quassel derivation
instead of using a `source.nix`.
Also use `fetchFromGitHub` since using `fetchurl` for github archives
is problematic.
Identified in 8887e1f697 (r239097413).
9504292b1e accidentally reverted all the
changes that had been made to the weechat wrapper since
8887e1f697.
I removed the wrapper, then wrote it again, but this time taking the
code from the latest version of weechat before the bad merge.
Allows for adding Perl libraries in the same way as for Python. Doesn't
really need to be a function, since there's only one perlPackages in
nixpkgs, but I went for consistency with the python plugin.
Loading olm.lua as weechat script with `/script load olm.lua' causes
errors like this:
```
/nix/store/43jbh7yxh8j4gjfzbvpd9clncah5dip1-weechat-matrix-bridge-2018-05-29/lib/ffi.so: undefined symbol: lua_tointeger
```
As `olm.lua' is loaded by `matrix.lua' it doesn't need to be included
manually by the weechat configuration.
In my previous PR I missed that ${sec.foobar} (syntax to retrieve
secrets in a weechat runtime) breaks the shell evaluation.
Furthermore `;` shall be used rather than `\n` to concat scripts and the
init config.
This aims to make the `weechat` package even more configurable. It
allows to specify scripts and commands using the `configure` function
inside a `weechat.override` expression.
The package can be configured like this:
```
with import <nixpkgs> { };
weechat.override {
plugins = { availablePlugins, ... }: {
plugins = builtins.attrValues availablePlugins;
init = ''
/set foo bar
/server add freenode chat.freenode.org
'';
scripts = [ "/path/to/script.py" ];
};
}
```
All commands are passed to `weechat --run-command "/set foo bar;/server ..."`.
The `plugins' attribute is not necessarily required anymore, if it's
sufficient to add `init' commands, the `plugins' will be
`builtins.attrValues availablePlugins' by default.
Additionally the result contains `weechat` and `weechat-headless`
(introduced in WeeChat 2.1) now.
If I have a patch I want to apply to weechat, I can't do that with
overrideAttrs like I can with almost every other package, because that
only applies to the wrapper derivation. For other wrapped packages, one
can usually call the wrapper with any version of the derivation, but the
weechat derivation didn't expose a wrapper creation function.
Taking inspiration from other packages, particularly Firefox, I
extracted the wrapper into its own function, made the default weechat
derivation use that, and added weechat-unwrapped.
Now I can add my custom patch like this:
(wrapWeechat
(weechat-unwrapped.overrideAttrs (oldAttrs: {
patches = [
(fetchpatch {
url = "55767f5f11.patch?full_index=1";
sha256 = "1pkcdsby57diqds1y5hhl0fr4i8j0zax32jb0gqd36siki3lza3d";
})
];
}))
{ configure =
{ availablePlugins, ... }:
{
plugins = with availablePlugins; [
(python.withPackages (packages: with packages; [ potr websocket_client ]))
];
};
})
There is a small backward incompatibility here: previously, it was
possible to get an unwrapped weechat like this:
weechat.override { configure = null; }
This didn't seem too important to keep around since it was also possible
to get an unwrapped weechat in a much more obvious way:
weechat.unwrapped
I could probably make it so that the first way still worked, if that
behavior turns out to really have been important.
* treewide: http -> https sources
This updates the source urls of all top-level packages from http to
https where possible.
* buildtorrent: fix url and tab -> spaces
It was found that Quassel could be remotely crashed and had an
unauthenticated RCE vulnerability. The public annoucement can be found
on the oss-sec archive [1]. The bump to 0.12.5 is supposed fixe both issues.
[1] http://seclists.org/oss-sec/2018/q2/77
