In my earlier commit
manual: Don't suggest exposing VM port to local network.
I made a side change titled
Use `127.0.0.1` also on the VM side, otherwise connections to
services that, in the VM, bind to `127.0.0.1` only
(doing the safe approach) do not work.
Unfortunately, that was wrong:
QEMU inside the VM always communicates via the virtualised
Ethernet interface, not via the VM's loopback interface.
So trying to connect to `127.0.0.1` on the VM's side cannot work.
The setting
QEMU_NET_OPTS="hostfwd=tcp::2222-:22"
caused the VM's port 2222 to be advertised on the host as
`0.0.0.0:2222`, thus anybody in the local network of the host
could SSH into the VM.
Instead, port-forward to localhost only.
Use `127.0.0.1` also on the VM side, otherwise connections to
services that, in the VM, bind to `127.0.0.1` only
(doing the safe approach) do not work.
See e.g. https://github.com/NixOS/nixpkgs/issues/100192
for more info why localhost listening is the best default.
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
Based on #257780, separated since it introduces significant changes.
bpycv: update passthru.tests.render
blender-with-packages: deprecated
it is still backwards compatible, but no longer preferred.
[Motivation](NixOS#257817 (comment))
`extraLayouts` was missed in #259891, so moving it to the other xkb
options with this PR.
Signed-off-by: Paul Meyer <49727155+katexochen@users.noreply.github.com>
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.
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>
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.
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.
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).
