New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update public-inbox to 1.8.0 and add systemd services #104457
Conversation
9f79ab7
to
67c9564
Compare
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
Looking pretty good overall! |
@ju1m any plans on updating this PR so we can merge it? Would be nice to use this to provide an archive for nixpkgs-dev. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very sorry for taking so long to get to this. I should have more time available for it now. I'm also happy to help, or to take back over, if you'd prefer.
git | ||
/* for InlineC */ | ||
gnumake | ||
stdenv.cc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will break if cross-compiled. Is there no way to compile InlineC stuff up front at build time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, according to public-inbox-tuning, recent public-inbox
generates and compiles C code at runtime to increase performance:
Process spawning
Our optional use of Inline::C speeds up subprocess spawning from large
daemon processes.
To enable Inline::C, either set the "PERL_INLINE_DIRECTORY" environment
variable to point to a writable directory, or create
"~/.cache/public-inbox/inline-c" for any user(s) running public-inbox
processes.
More (optional) Inline::C use will be introduced in the future to lower
memory use and improve scalability.
I've little experience with cross-compiling using Nixpkgs, so I don't know when or how it will break, nor how to address that concern. Should I use something else than stdenv.cc
to get the target's compiler? Should I put InlineC
usage behind a package option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see -- Inline::C is different to XS, in that the code is generated at runtime. So we can't compile at ahead of time and will need a C compiler. In that case, the usual approach I've seen here (that is cross-friendly) is to wrap with gcc
instead of stdenv.cc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inline::C is cool and all, but...
Has anyone mentioned to upstream that the lack of support for ahead of time compilation/the dependency on a compiler at runtime, is fairly annoying for packaging? I'm sure other package managers would also prefer to not add a dependency on gcc to public-inbox, I don't think that's just us. (And the public-inbox maintainer is, I think, very responsive to such concerns)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inline::C
is optional
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's going to take me a little while to review this because it's so big and so different to my version, so this isn't going to be my last round of comments. But we're getting there. :)
to be used as a reverse proxy, eg. in nginx: | ||
<code>locations."/inbox".proxyPass = "http://unix:''${config.services.public-inbox.http.port}:/inbox";</code> | ||
Set to null and use <code>systemd.sockets.public-inbox-httpd.listenStreams</code> | ||
if you need a more advanced listening. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the extra complexity of taking two different kinds of values here is worth the small convenience of being able to open the firewall automatically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure to understand what you want, isn't openFirewall
working well enough?
Thanks for all your feedbacks. |
00d31cb
to
9b6cab8
Compare
|
|
Currently there isn't a single module within NixOS that uses So what are all of the implications of using |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/nixos-policy-regarding-systemd-confinement/18976/1 |
|
|
Add support for enabling confinement but does not enable it by default yet because so far no module within NixOS uses confinement hence that would set a precedent.
|
This PR has had enough feedback, imo it looks good enough for a merge, any further improvements can be done with other PRs. Thanks for the hard work @ju1m! |
Works for me and is ready for review.
Motivation for this change
Add a
public-inbox
NixOS service.Things done
public-inbox
(1.8.0), removing old Nixpkgs patches (merged since).InlineC
.systemd
services :systemd-confinement
for the services.generators.toGitINI
and introduce aformats.gitIni
.nixos/tests/public-inbox.nix
.services.public-inbox.postfix.enable
for configuringpostfix
using a dedicated transport, and supportrecipientDelimiter
. No longer use a.forward
file.sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)Ping @alyssais, @catern, @spacekookie