<emily>
then I'd personally consider that exactly an example of the RFC process holding things up pointlessly, honestly
<infinisil>
Potentially yeah..
lovesegfault has quit [Quit: WeeChat 2.7.1]
<infinisil>
I think rfcs should only be used when it's something controversial and/or big
lovesegfault has joined #nixos-dev
<infinisil>
This one was slightly controversial
<infinisil>
In special cases there are benefits to static ids
<emily>
mhm
<emily>
there's always compatibility and integration drawbacks to sandboxing stuff, but tbh I wish nixos erred much more on the side of putting a bunch of hardening stuff in systemd service configs by default and turning it off when it's an issue, than the other way around
<andi->
samueldr: not really, I just wanted to test it one more time. If you are confiedent you have my +1
<gchristensen>
a proposed way to have low-tier architecture builds in Hydra: https://github.com/NixOS/hydra/pull/721 for thigns like riscv or armv7 or armv6 etc.
<colemickens>
Sorry. asap was definitely the wrong choice of words, sooner rather than later is what I meant. Last time I touched a pkg that require a big rebuild it took a long time to get merged.
<gchristensen>
cool
<colemickens>
(not sure that latest is needed, but I'm trying to validate firefox-nightly + sway + vaapi and I figured I'd bump it while I was checking things out)
<jtojnar>
`LD_LIBRARY_PATH` usage in nixpkgs needs to die
<domenkozar[m]>
yeah it's kind of the opposite of nix goals :)
<domenkozar[m]>
but I guess there's a habit that's it ok for executables
<domenkozar[m]>
except that vscode runs a terminal :D
<jtojnar>
you never know what runs a terminal (e.g. you can open a firefox from sublime text, open nautilus from firefox downloads and open terminal from there)
<jtojnar>
we should disable stripping and add the required paths to rpath instead
<jtojnar>
or hardcode the paths for non-elf files
<domenkozar[m]>
seems like autopatchelf provide runtimeDependencies
<domenkozar[m]>
yay fixed
<domenkozar[m]>
it's been a while since I needed to fix something in nixkgs
genesis has joined #nixos-dev
<domenkozar[m]>
is there any way for glibc not to crash at runtime with mismatched versions?
<gchristensen>
sort of ignoring the big elephant in that path though, openglib-driver
<infinisil>
domenkozar[m]: Although that's probably problematic with `ghcWithPackages`
<infinisil>
Because that ouputs a ghc binary wrapped with the correct packages
<infinisil>
Which probably all nix people use
<domenkozar[m]>
right
<infinisil>
A solution would be to wrap hie/ghcide with a Nix-specific project setup calling ghcWithPackages on its own for the packages in the project
<domenkozar[m]>
so it does try to get system lib, which is what ghcWithPackages manipulates I presume?
rajivr___ has quit [Ping timeout: 240 seconds]
vdemeester has quit [Ping timeout: 256 seconds]
vdemeester has joined #nixos-dev
rajivr___ has joined #nixos-dev
<mkaito>
I was just told that "user profiles were removed". I did a thing that relies on /nix/var/nix/profiles/foo to be a gcroot (kinda like Hail does) -- what do I need to fix about this?
<gchristensen>
where did you hear that?
<mkaito>
yorick told me :P
<mkaito>
(a while ago)
<mkaito>
I just remembered now because I wrote a new thing yesterday that relies on this
<gchristensen>
I don't think that has happened :)
<mkaito>
good lol
<mkaito>
I (ab)use nix-env to create a fake user profile that I can switch around using nix-env, and service definitions that use this known path. that way I can deploy things at the service level by pushing closures around.
<mkaito>
I basically rewrote Hail in bad Bash
<gchristensen>
yikies
<mkaito>
my plan is to rewrite it in rust, it's just a proof of concept right now
<mkaito>
but the crux was that those fake profiles not be garbage collected
<gchristensen>
yeah Nix doesn't really work without GC roots, and profiles are really just a special GC root :
<mkaito>
and a known path that I can point things at while switching them around for deployment. without that, I'd have to rebuild the host every time something updates.
<mkaito>
I know the entire idea goes a bit against the grain in nix, which presumes the entire system is an atomic closure, but I've found myself wanting this for years now.
<domenkozar[m]>
mkaito: why not just fix Hail?
<yorick>
I recall no such thing
<mkaito>
I do
<mkaito>
domenkozar[m]: Me no habla Haskell :P
<mkaito>
I'm not looking to start a debate, but the chances of me ever sitting down in earnest with Haskell are pretty slim
<domenkozar[m]>
ah ok
<mkaito>
which is ironic, given where I work and what I do, but still
<domenkozar[m]>
that's a good answer, I was just wondering
<gchristensen>
mkaito: I feel the same way
<mkaito>
maybe we can just agree that as long as I don't rewrite Hail in Perl, it's cool? :P
abathur has joined #nixos-dev
CRTified has quit [Quit: Gateway shutdown]
CRTified has joined #nixos-dev
myskran has joined #nixos-dev
abathur has quit [Ping timeout: 258 seconds]
<mkaito>
gchristensen: I messed around a bit with writhing "shell scripts" in Rust, and the duct package makes a *huge* difference. I've been rewriting a few of my old bash scripts in Rust just for the heck of it, and it's actually pretty decent.
<gchristensen>
nice!
<mkaito>
I actually feel like they improve upon the scripts they come from, rather than just adding unnecessary baggage in the form of rust "cruft".
<genesis>
jtojnar : could you please merge #81572, i need it to go ahead on the topic
<{^_^}>
undefined variable 'DRAGONS' at (string):286:1
<srk>
:D
<mkaito>
I can relate :P
<mkaito>
also, that's how most of my coworkers feel about my bash scripts
<mkaito>
talking about cthulhu bash, I wrote a thing to fetch secrets from hashicorp vault in dependent units which we've moved all our server secrets to. maybe with a little cleanup that would be useful to have in nixpkgs? would that be interesting?
<gchristensen>
not as-described, no :P
<mkaito>
figured I'd at least ask :P
<gchristensen>
but if your method is working well, it'd be cool to document how it works and post your cthulhu bash as a working example
<mkaito>
I feel it's quite elegant, as long as you don't look under the hood lol
<gchristensen>
all the more reason to open it up describing how it works
<gchristensen>
the 0755 is pretty frightful, but overall pretty cool
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
lovesegfault has quit [Client Quit]
<mkaito>
oh huh good catch
<mkaito>
that should be 0700
<mkaito>
no wait, it shouldn't. that's intentional because otherwise nobody but root can traverse the folder.
<mkaito>
it's a simple wrapper around getting values from vault and dumping them into files under /run/secrets/<service> -- it's then up to you to figure out how to consume them in your services.
<mkaito>
it takes care of binding the units together so that they restart together
<mkaito>
so anyway, do you see any value in cleaning it up for nixpkgs? or should that better live in a blog post? :P
<genesis>
jq powered :)
<mkaito>
yeah lol
lovesegfault has joined #nixos-dev
<gchristensen>
mkaito: I think putting it in nixos now is maybe a bit soon, but I think starting a discussion about it is a good idea
<aanderse>
gchristensen: mkaito: there is an rfc discussing this sorta thing
<aanderse>
your input on that rfc would be of value
<mkaito>
that's a very small scroll bar. do I make some coffee?
* genesis
have to work on libffado, recently broken stuff, is there a channel like #nixos-musician ?
<mkaito>
hmmmm to work with DynamicUser, the only thing you can do to feed secrets into the unit is EnvironmentFile and/or a bang preStart script, which is mildly annoying in nixos atm.
<mkaito>
EnvironmentFile is always read as root, so if you can configure a service via environment, that's ideal (and a primary use case for my module, in fact)
<gchristensen>
nice
<mkaito>
this RFC seems to be entirely about the *other* side of what I wrote: consuming secrets that are already provisioned some other way.
<abathur>
gchristensen: did you see the email I sent on the 24th?
<gchristensen>
no, sorry
<abathur>
no worries if you don't have time to look at it; I know it's a busy part of the calendar
<abathur>
though I could maybe use a punt to someone else if so? :)
<gchristensen>
see PM?
<flokli>
mkaito: gchristensen: I think one big problem is "how to pass in secrets to a specific service"
<mkaito>
I strongly believe in EnvironmentFile
<flokli>
because it doesn't really work for dynamic users etc.
<mkaito>
but not all things support that
<flokli>
mkaito: EnvironmentFile is another hack ;-)
<flokli>
can we use fsattrs on /run/keys/…, and could that be made to work with dynamic users as well?
<mkaito>
well yes, but then we move into things like services natively integrating with Vault et al... and I'm already complaining about services that don't care about environment variables :P
<mkaito>
scoping access for dynamic users is basically impossible, since you don't know the uid beforehand. it switches straight from root to an unknown user with (hopefully) strongly sandboxed environment.
<flokli>
Crazy idea: get proper namespace support into the kernel keyring, and have systemd provide some sidecar services exposing a filesystem in a private mount namespace
<flokli>
that could be auto-activated on access.
<flokli>
^ arianvp aanderse
<flokli>
then on the other side of the keyring, there could be something doing the thinking about who's allowed to access what.
<aanderse>
i mentioned (in #nixos-systemd?) the other day that DynamicUser works "fine" with secrets
<aanderse>
you push a secret into StateDirectory or RuntimeDirectory and bam it works
<samueldr>
specifically ${var/Pattern/Replacement} in that page
<lovesegfault>
I'm getting almost full utilization on all 64 cores though, nice
abathur has quit [Read error: Connection reset by peer]
myskran has joined #nixos-dev
myskran has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
myskran has joined #nixos-dev
myskran has quit [Read error: Connection reset by peer]
<worldofpeace>
sounds like rustc lovesegfault
<lovesegfault>
worldofpeace: don't even tell me :P
<lovesegfault>
At work we have a Rust workspace with >700 deps in test mode
<lovesegfault>
takes a while to build
myskran has joined #nixos-dev
myskran has quit [Read error: Connection reset by peer]
<cole-h>
samueldr++ lovesegfault++ Ah, OK. It just looked strange with the whitespace, but now looking at the context, it makes sense (the whitespace is necessary)
<{^_^}>
lovesegfault's karma got increased to 18, samueldr's karma got increased to 179
myskran has joined #nixos-dev
myskran has quit [Read error: Connection reset by peer]
ixxie has quit [Ping timeout: 260 seconds]
myskran has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
<lovesegfault>
jtojnar: Oh god it's making me rebuild rustc
<jtojnar>
are you doing the branch or cherry-pick?
<lovesegfault>
cherry-picked on top of nixos-unstable
<lovesegfault>
cherry-picked your PR and worldofpeace's already merged one
<worldofpeace>
lovesegfault: that doesn't seem right to me, it's like you merged in staging