Previously we could not override the input packages to docker at all as
that had been shadowed due to the usage of inherit in all-package.nix.
We are now mixing the "variable" variables for the build and the
dependency declarations for the package and using callPackage as if each
of the docker packages would be separate files that we evaluate.
This now enables overriding e.g. iptables for a single verison of
docker which previously was not feasible without importing the
default.nix again (and passing different arguments).
> pkgs.docker.override { iptables = pkgs.iptables-nftables-compat; }
The change to GCC 10 did break this package as it does some conversation
from 32bit integer to the type "int" which might be "narrower" depending
on the platform. By default GCC 10 errors in these cases. Since this
code is fine (and has been for a long time) it is okay to disable the
error in this case.
This plugin is used commonly enough that we should ensure it still
builds (and dovecot works) after loading it.
This is not yet perfect as we aren't testing any of it's functionality
but at least we ensure that dovecot continues to do the regular job.
This updates to the latest version. According to the changelog 0.5.12
was skipped. The changes in this release are required to be compatible
with the latest dovecot release.
Changes:
- duplicate: The test was handled badly in a multiscript (sieve_before,
sieve_after) scenario in which an earlier script in the sequence with
a duplicate test succeeded, while a later script caused a runtime
failure. In that case, the message is recorded for duplicate tracking,
while the message may not actually have been delivered in the end.
- editheader: Sieve interpreter entered infinite loop at startup when
the "editheader" configuration listed an invalid header name. This
problem can only be triggered by the administrator.
- relational: The Sieve relational extension can cause a segfault at
compile time. This is triggered by invalid script syntax. The segfault
happens when this match type is the last argument of the test command.
This situation is not possible in a valid script; positional arguments
are normally present after that, which would prevent the segfault.
- sieve: For some Sieve commands the provided mailbox name is not
properly checked for UTF-8 validity, which can cause assert crashes at
runtime when an invalid mailbox name is encountered. This can be
caused by the user by writing a bad Sieve script involving the
affected commands ("mailboxexists", "specialuse_exists").
This can be triggered by the remote sender only when the user has
written a Sieve script that passes message content to one of the
affected commands.
- sieve: Large sequences of 8-bit octets passed to certain Sieve
commands that create or modify message headers that allow UTF-8 text
(vacation, notify and addheader) can cause the delivery or IMAP
process (when IMAPSieve is used) to enter a memory-consuming
semi-infinite loop that ends when the process exceeds its memory
limits. Logged in users can cause these hangs only for their own
processes.
While we already had some test we might as well add the test for that
exact package to the tests attribute set. After all that should be what
(primarily) tests dovecot.
This fixes CVE_2020-24386, CVE-2020-25725 and a bunch of regular bugs
[1].
* CVE-2020-24386: Specially crafted command can cause IMAP hibernate to
allow logged in user to access other people's emails and filesystem
information.
* CVE-2020-25275: Mail delivery / parsing crashed when the 10 000th MIME part was
message/rfc822 (or if parent was multipart/digest). This happened
due to earlier MIME parsing changes for CVE-2020-12100.
[1] https://raw.githubusercontent.com/dovecot/core/2.3.13/NEWS
Previously, after the version bump to v247, we broke journalctl --grep
as libpcre2 was lazily loaded during runtime using dlopen(3). This
ensures that we have a test case that alerts us when it fails again.
This ensures that all the features that are implemented via dlopen(3)
are available (or explicitly deactivated) by pointing dlopen to the
absolute store path instead of relying on the linkers runtime lookup
code.
All of the dlopen calls have to be handled. When new ones are introduced
by upstream (or one of our patches) those must be explicitly declared,
otherwise the build will fail.
As of systemd version 247 we've seen a few errors like `libpcre2.… not
found` when using e.g. --grep with journalctl. Those errors should
become less unexpected now.
There are generally two classes of dlopen calls. Those that we want to
support and those that should be deactivated / unsupported. This change
enforces that we handle all dlopen calls explicitly. Meaning: There is
not a single dlopen call in the code source tree that we did not
explicitly handle.
In order to do this I introduced a list of attributes that maps from
shared object name to the package that contains them. The package can be
null meaning the reference should be nuked and the shared object will
never be loadable during runtime (because it points at an invalid store
path location).
Since 40e7be1 all ARM platforms that didn't have a parsed cpu version
(e.g. arm-none-eabi) would be handled as armv7l-hf-multiplatform which
did break building arm-trusted-platform packages for some targets (e.g.
rk3399).
Using pcBase as fallback, instead of armv7l-hf-multiplatform,
corresponds with the behaviour we had before 40e7be1.
Qt 5.15 carried a change that renamed a getter for the socket error. In
a later relase that change was reverted (to be less ambiguous) thus now
those that had picked up the change in API had to change their code.
This has now been reverted [0] and thus the consumers also have to
revert their changes…
[0] https://codereview.qt-project.org/c/qt/qtbase/+/289693
This is a maintenance release of the Qt 5.15 release series. It focuses on
bug and security fixes. The feature that made me update this package was
the broken u2f support in QtWebEngine when used together with
Qutebrowser. It previously (on older Qt versions) used to work but
stopped working with the switch to 5.15.
As the changelog is rather extensive the reader is advised to inspect
[0] to checkout the changes to each of the components of their
interest.
This also fixes a security issue with QtWebEngine based browsers that
could be crashed by visiting a website that invokes certain WebRTC
features [1].
[0] https://wiki.qt.io/Qt_5.15.2_Change_Files
[1] https://bugreports.qt.io/browse/QTBUG-86752
After the recent wrapper and plugin purge outbreak where as the only
active listed maintainer of the package I didn't even get a chance to
comment (e.g. via comment or review request) I do not want to continue
maintaining this package anymore.
rust >= 1.48 causes a panic within spotifyd on music playback. As long
as there is no upstream fix for the issue we use an older version of
rust.
Upstream issue: https://github.com/Spotifyd/spotifyd/issues/719
This patch fixes compilation on aarch64 that broke somewhere between the
upgrade to the lateste rustc and the firefox 82 to 83 upgrade.
The patch has been submitted upstream and can probably be removed on the
next version bump.
In [#100765] @vcunat pointed out that we could decouple cacert from the
NSS package to make it more rebuild friendly. Just rebuilding packages
that depend on NSS seems to be about ~100. Rebuilding all the packages
that depend on cacert is >9k as of this writing. This makes it much more
feasible to upgrade high-profile packages that are (rightfully) pedantic
on their NSS version like firefox and thunderbird.
[#100765]: https://github.com/NixOS/nixpkgs/pull/100765
This adds support for the Radxa Rock Pi 4 board which is based on
RK3399. The u-boot outputs from the introduced build are suitable to
build a generic image for the Rock Pi 4 by setting the following in a
custom build of $nixpkgs/nixos/modules/installer/cd-dvd/sd-image-aarch64.nix:
```
sdImage.postBuildCommands = ''
dd if=${pkgs.ubootRockPi4}/idbloader.img of=$img seek=64 conv=notrunc
dd if=${pkgs.ubootROckPi4}/u-boot.itb of=$img seek=16384 conv=notrunc
'';
```
This is to ensure that whenever we install the desktop item we also have
the script installed. Prior to b02719a we always had the reference to
the script in the desktop item. Since desktop items are being copied to
home directories and thus "bit rod" over time that absolute path was
removed.
i3status-rust requires `ethtool` for the net block to work since 0.14.2.
The notmuch feature is also available and all we've to do for that is to
pass the `notmuch` input and enable the feature.
Other units depend on nss-lookup.target and expect the DNS resolution to
work once that target is reached. The previous version
`wants=nss-lookup.target` made this unit require the nss-lookup.target
to be reached before this was started.
Another change that we can probalby do is drop the before relationship
with the nss-lookup.target. That might just be implied with the current
version.
This option allows users to specify a local UNIX control socket to
"remote control" the daemon. System users, that should be permitted to
access the daemon, must be in the `unbound` group in order to access the
socket. When a socket path is configured we are also creating the
required group.
Currently this only supports the UNIX socket mode while unbound actually
supports more advanced types. Users are still able to configure more
complex scenarios via the `extraConfig` attribute.
When this option is set to `null` (the default) it doesn't affect the
system configuration at all. The unbound defaults for control sockets
apply and no additional groups are created.
Previously we just applied a very minimal set of restrictions and
trusted unbound to properly drop root privs and capabilities.
With this change I am (for the most part) just using the upstream
example unit file for unbound. The main difference is that we start
unbound was `unbound` user with the required capabilities instead of
letting unbound do the chroot & uid/gid changes.
The upstream unit configuration this is based on is a lot stricter with
all kinds of permissions then our previous variant. It also came with
the default of having the `Type` set to `notify`, therefore we are also
using the `unbound-with-systemd` package here. Unbound will start up,
read the configuration files and start listening on the configured ports
before systemd will declare the unit "running". This will likely help
with startup order and the occasional race condition during system
activation where the DNS service is started but not yet ready to answer
queries.
Aditionally to the much stricter runtime environmet I removed the
`/dev/urandom` mount lines we previously had in the code (that would
randomly fail during `stop`-phase).
The `preStart` script is now only required if we enabled the trust
anchor updates (which are still enabled by default).
Another beneefit of the refactoring is that we can now issue reloads via
either `pkill -HUP unbound` or `systemctl reload unbound` to reload the
running configuration without taking the daemon offline. A prerequisite
of this was that unbound configuration is available on a well known path
on the file system. I went for /etc/unbound/unbound.conf as that is the
default in the CLI tooling which in turn enables us to use
`unbound-control` without passing a custom configuration location.
This introduces an unbound variant that is built with systemd support.
That means it is able to signal readiness to systemd once it did start
or finished reloading. This likely allows us to close a small gap during
bootup where the service is assumed up but doesn't respond to DNS
queries just yet.
Systemd has to remain an optional (non-default) dependency as otherwise
we will have an unpleasant bootstrap cycle. Most (if not all) of the
(lib)unbound consumers will likely not care about unbound's systemd
integration that only affects the daemon mode, anyway.
This adds -frandom-seed to each compiler invocation in stdenv. The
object here is to make the compierl invocations produce the same output
every time they are called (for the same derivation). When the
-frandom-seed option is not set the compiler will use a combination of
random numbers (in GCC's case from /dev/urandom) and the durrent time to
produce a "random" input per file. This can (among other things) lead to
different ordering of symbols in the produced object files.
For reason of reproducibility we prefer having the same derivation
produce the exact same outputs. This is not a silver bullet but one way
to tame the compiler.
Upstream has apparently changed the configuration format and is now
throwing an error when the `encrypt_sse` option is set. According to the
current version of the documentation encryption moved to the
`sse_config` option that (is optional and) offers all the features we do
not use or care about for this test.
We've been providing zlib as a buildInput for some time now but rsync
still builds (& links) it's own copy of zlib unless we disable it
explicitly. This cuts down on compilation time but otherwise shouldn't
have any side effects.
Changelog:
- Add QueryRow to our connection interface
- Add SQL API for managing metric compression setting
- Add code documentation for query/read path of the connector
- Adds support for checking pg version on startup
- BUGFIX reset pendingBuffer epoch when we're done
- Epoch-Based cache validation
- First pass documenting the write path
- Fix bug with deletion of metric name labels.
- Fix erroneous PromQL query in end-to-end tests
- Fix error reporting to prevent panic
- Fix golden file tests
- Fix logging output to match rest of the project
- Fix views on Vanilla PG and add tests
- Make example docker-compose clearer (#305)
- Mask password while printing config
- Prepare for the 0.1.1 release
- Prepare for the next development cycle
- REFACTOR rearrange mocks
- REFACTOR switch TestPGXInserterInsertData to the new mock
- REFACTOR switch TestPGXInserterInsertSeries to the new mock
- Start a pgmodel Readme
Source: https://github.com/timescale/promscale/releases/tag/0.1.1
The hydra tarball step would fail due to the nodes attribute not being
properly inherited. Since we can't execute all the tests and release
steps locally anymore (thanks to the JSONification and faster hydra
eval) these errors will probably keep in appearing.
This is hopefully the last of those introduced by me test runner
refactoring.
Error was seen on hydra (https://hydra.nixos.org/build/129282411):
> unpacking sources
> unpacking source archive /nix/store/bp95x52h6nv3j8apxrryyj2rviw682k1-source
> source root is source
> patching sources
> autoconfPhase
> No bootstrap, bootstrap.sh, configure.in or configure.ac. Assuming this is not an GNU Autotools package.
> configuring
> release name is nixpkgs-21.03pre249116.1088f059401
> git-revision is 1088f05940
> building
> no Makefile, doing nothing
> running tests
> warning: you did not specify '--add-root'; the result might be removed by the garbage collector
> warning: you did not specify '--add-root'; the result might be removed by the garbage collector
> checking Nixpkgs on i686-linux
> checking Nixpkgs on x86_64-linux
> checking Nixpkgs on x86_64-darwin
> checking eval-release.nix
> trace: `mkStrict' is obsolete; use `mkOverride 0' instead.
> trace: `lib.nixpkgsVersion` is deprecated, use `lib.version` instead!
> trace: warning: lib.readPathsFromFile is deprecated, use a list instead
> trace: Warning: `showVal` is deprecated and will be removed in the next release, please use `traceSeqN`
> trace: lib.zip is deprecated, use lib.zipAttrsWith instead
> checking find-tarballs.nix
> trace: `mkStrict' is obsolete; use `mkOverride 0' instead.
> trace: `lib.nixpkgsVersion` is deprecated, use `lib.version` instead!
> trace: warning: lib.readPathsFromFile is deprecated, use a list instead
> trace: Warning: `showVal` is deprecated and will be removed in the next release, please use `traceSeqN`
> trace: lib.zip is deprecated, use lib.zipAttrsWith instead
> error: while evaluating anonymous function at /build/source/maintainers/scripts/find-tarballs.nix:6:1, called from undefined position:
> while evaluating 'operator' at /build/source/maintainers/scripts/find-tarballs.nix:27:16, called from undefined position:
> while evaluating 'immediateDependenciesOf' at /build/source/maintainers/scripts/find-tarballs.nix:39:29, called from /build/source/maintainers/scripts/find-tarballs.nix:27:44:
> while evaluating anonymous function at /build/source/lib/attrsets.nix:234:10, called from undefined position:
> while evaluating anonymous function at /build/source/maintainers/scripts/find-tarballs.nix:40:37, called from /build/source/lib/attrsets.nix:234:16:
> while evaluating 'derivationsIn' at /build/source/maintainers/scripts/find-tarballs.nix:42:19, called from /build/source/maintainers/scripts/find-tarballs.nix:40:40:
> while evaluating 'canEval' at /build/source/maintainers/scripts/find-tarballs.nix:48:13, called from /build/source/maintainers/scripts/find-tarballs.nix:43:9:
> while evaluating the attribute 'nodes' at /build/source/nixos/lib/testing-python.nix:195:23:
> attribute 'nodes' missing, at /build/source/nixos/lib/testing-python.nix:193:16
> build time elapsed: 0m0.122s 0m0.043s 17m51.526s 0m56.668s
> builder for '/nix/store/96rk3c74vrk6m3snm7n6jhis3j640pn4-nixpkgs-tarball-21.03pre249116.1088f059401.drv' failed with exit code 1
This reverts commit aab534b894 & uses the
driverInteractive attribute for the test driver instead.
This has the same effect but removes the extra module in the
nixos-build-vms code.
In 5500dc8 we introduced the --keep-vm-state flag and defaulted to that
flag not being set. This lead to the `runInMachine` tests not longer
working and that going unnoticed for quite some time now.
Andreas Rammhold