Related to #262907 (Django3 removal from nixpkgs).
This package already required an unreasonable amount of maintenance
regularly for a such small leaf-package. It has a few highly outdated
dependencies (e.g. flask 1, jinja2 2.11, sqlalchemy 1.3).
After at least each Python package-set update one had to fix up a lot of
dependencies to fix the package itself, so it was only useful on stable
branches. And having so much outdated software in a security-sensitive
piece of software seems questionable.
Finally, globin and I won't be available for maintaining this now that
Mayflower is migrating to another solution (and we'll do that as well)
and I'd expect this to bitrot extremely quick if we both bail out.
literalExpression triggers the following error when building the
manual:
Cacheable portion of option doc build failed.
Usually this means that an option attribute that ends up in documentation (eg `default` or `description`) depends on the restricted module arguments `config` or `pkgs`.
Remove the deprecated --models option, as models are now discovered
and loaded dynamically from all configured model dirs at runtime.
Allow setting up custom model directories, so wake words other than the
built-in ones can be used, e.g. from
https://github.com/fwartner/home-assistant-wakewords-collection.
I don't really understand why this is only for a single version, so I
figured I'd just add this to the test matrix to also cover this
test-case for each major. Now, there's also one thing less to take care of
when removing old postgresql versions.
As described in the release lifecycle docs from postgresql[1], v11 will
stop receiving fixes as of Nov 9 2023. This means it's EOL throughout
the entire lifetime of 23.11, so let's drop it now.
A lot of examples are also referencing postgresql_11. Where it's
sensible, use postgresql_15 as example now to avoid confusion.
This is also handy because the LLVM 16 fix for postgresql is not
available for postgresql 11 ;-)
[1] https://www.postgresql.org/support/versioning/
* luarocks-packages-updater: init
Goal is to make it possible to maintain out-of-tree luarocks packages
without needing to clone nixpkgs.
maintainers/scripts/update-luarocks-packages gets renamed to
pkgs/development/lua-modules/updater/updater.py
Once merged you can run for instance
nix run nixpkgs#luarocks-packages-updater -- -i contrib/luarocks-packages.csv -o contrib/generated-packages.nix
I also set the parallelism (--proc) to 1 by default else luarocks fails
because of https://github.com/luarocks/luarocks/issues/1540
* Update maintainers/scripts/pluginupdate.py
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
---------
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
When using iproute2's ip binary, you can omit the dev parameter, e.g. ip link set up eth0 instead of ip link set up dev eth0.
This breaks if for some reason your device is named e.g. he, hel, … because it is interpreted as ip link set up help.
I just encountered this bug using networking.bridges trying to create an interface named he.
I used a grep on nixpkgs to try to find iproute2 invocations using variables without the dev keyword, and found a few, and fixed them by providing the dev keyword.
I merely fixed what I found, but the use of abbreviated commands makes it a bit hard to be sure everything has been found (e.g. ip l set … up instead of ip link set … up).
From now on, we will aim to ensure that the test driver
gets tested by OfBorg using all our available tests.
This commit adds the driver timeout test to the driver.
For `testBuildFailure` and similar functions, we need a full blown derivation and not a lazy one.
This is an internal option for test framework developers.
Since the debut of the test-driver, we didn't obtain
a race timer with the test execution to ensure that tests doesn't run beyond
a certain amount of time.
This is particularly important when you are running into hanging tests
which cannot be detected by current facilities (requires more pvpanic wiring up, QMP
API stuff, etc.).
Two easy examples:
- Some QEMU tests may get stuck in some situation and run for more than 24 hours → we default to 1 hour max.
- Some QEMU tests may panic in the wrong place, e.g. UEFI firmware or worse → end users can set a "reasonable" amount of time
And then, we should let the retry logic retest them until they succeed and adjust
their global timeouts.
Of course, this does not help with the fact that the timeout may need to be
a function of the actual busyness of the machine running the tests.
This is only one step towards increased reliability.
This is mainly due to the lack of maintenance in nixpkgs.
`google-chrome-{beta,dev}` depend on `chromium{Beta,Dev}`'s version
info.
`chromium{Beta,Dev}` are rarely updated and explicitly blocklisted by
`hydra.nixos.org`, meaning they are almost always outdated and not
cached in `cache.nixos.org`.
`chromium{Beta,Dev}` were intended to fix the build derivation of each
new major release (if something broke) *before* stable reached that
new major release.
Allowing for fast bumps in nixpkgs, especially if the stable bump
contains very important critical security fixes.
Something that can easily be replicated by using an early-stable release
or by manually entering a dev/beta version string in stable's
`upstream-info.nix`.
This resolves exposing end-users to outdated and vulnerable
`google-chrome-{beta,dev}` and `chromium{Beta,Dev}` versions.
If the PAPERLESS_SECRET_KEY environment variable is left unset
paperless-ngx defaults to a well-known value, which is insecure.
Co-authored-by: Erik Arvstedt <erik.arvstedt@gmail.com>
On current nixpkgs, no modifications to the server settings were
necessary to pass the audit. However, some of the client algorithms were
considered insecure. The client configuration lists all algorithms which
were listed as acceptable by `ssh-audit`.
This can be used as an example of a configuration currently considered
acceptable by `ssh-audit`, and verifies that such a configuration
results in a compatible client/server configuration.
Beware that this test will continue passing when future versions of
`ssh-audit` add support for new algorithms. In other words, the example
configuration represents a subset of what the current version of
`ssh-audit` would consider acceptable.
Use modulesPath so we don't have to magically rewrite paths in activation script,
set stateVersion to the one this was built with (which should approximate "first install")
Release announcement:
https://github.com/psb1558/Junicode-font/releases/tag/v2.001
This is a breaking change, at least in font file naming (Junicode.ttf
is now Junicode-Regular.ttf). In general, 2.0 adds a lot more font
variants and opentype and web font versions of the font.
Seeing as backward compatibility is broken anyway, I opted to break it
a bit more and change custom install path (`junicode-ttf`) to
seemingly more conventional `truetype`; new .otf and .woff2 variants
are then naturally placed in corresponding directories. This
does *not* affect the `fonts.packages` NixOS option, which rearranges
font files anyway, but brings a degree of consistency with other
fonts.
Both the file renaming and the directory structure change break
satysfi, however, so I adjusted its builder accordingly, copying over
only those font variants that were also present in 1.0 series.
You can see in https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html that
this should be "HairPin" not "Hairpin". Using "Hairpin" results in
```
Oct 25 18:55:03 my-host systemd-networkd[843736]: /etc/systemd/network/10-bridge.network:11:
Unknown key name 'Hairpin' in section 'Bridge', ignoring.
```
This flag allows the user to optionally exclude
switch-to-confguration.pl from toplevel.
This is interesting for appliance images where you don't want to re-build
the system. This flag is called `rebuildable` because the standard
interface to do this is `nixos-rebuild` which will not work anymore with
this change.
While there is no fetcher or builder (in nixpkgs) that takes an `md5` parameter,
for some inscrutable reason the nix interpreter accepts the following:
```nix
fetchurl {
url = "https://www.perdu.com";
hash = "md5-rrdBU2a35b2PM2ZO+n/zGw==";
}
```
Note that neither MD5 nor SHA1 are allowed by the syntax of SRI hashes.
Kea may clean the runtime directory when starting (or maybe systemd does
it). I ran into this issue when restarting Kea after changing its
configuration, so I think the fact it normally doesn't clean it is a
race condition (it's cleaned on service start, and normally all Kea
services start at roughly the same time).
