AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
evils has joined #nixos-dev
__monty__ has joined #nixos-dev
jdelStrother has joined #nixos-dev
pmy_ has quit [Quit: WeeChat 3.0.1]
pmy has joined #nixos-dev
jdelStrother has quit [Quit: Connection closed]
jdelStrother has joined #nixos-dev
orivej has joined #nixos-dev
LinuxHackerman has quit [Quit: Bridge terminating on SIGTERM]
regnat[m]1 has quit [Quit: Bridge terminating on SIGTERM]
jtojnar has quit [Quit: Bridge terminating on SIGTERM]
immae has quit [Quit: Bridge terminating on SIGTERM]
DamienCassou has quit [Quit: Bridge terminating on SIGTERM]
emily has quit [Quit: Bridge terminating on SIGTERM]
Ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
mkg20001 has quit [Quit: Bridge terminating on SIGTERM]
bbigras has quit [Quit: Bridge terminating on SIGTERM]
alexarice[m] has quit [Quit: Bridge terminating on SIGTERM]
puzzlewolf has quit [Quit: Bridge terminating on SIGTERM]
rnhmjoj has quit [Quit: Bridge terminating on SIGTERM]
aanderse has quit [Quit: Bridge terminating on SIGTERM]
colemickens has quit [Quit: Bridge terminating on SIGTERM]
zuh0 has quit [Quit: Bridge terminating on SIGTERM]
rmcgibbo[m] has quit [Quit: Bridge terminating on SIGTERM]
danielrf[m] has quit [Quit: Bridge terminating on SIGTERM]
nh2[m] has quit [Quit: Bridge terminating on SIGTERM]
michaelpj has quit [Quit: Bridge terminating on SIGTERM]
symphorien[m] has quit [Quit: Bridge terminating on SIGTERM]
siraben has quit [Quit: Bridge terminating on SIGTERM]
mjlbach has quit [Quit: Bridge terminating on SIGTERM]
rycee has quit [Quit: Bridge terminating on SIGTERM]
ryantm has quit [Quit: Bridge terminating on SIGTERM]
zimbatm[m] has quit [Quit: Bridge terminating on SIGTERM]
chvp has quit [Quit: Bridge terminating on SIGTERM]
jonge[m] has quit [Quit: Bridge terminating on SIGTERM]
garbas[m] has quit [Quit: Bridge terminating on SIGTERM]
timokau[m] has quit [Quit: Bridge terminating on SIGTERM]
Dandellion has quit [Quit: Bridge terminating on SIGTERM]
thefloweringash has quit [Quit: Bridge terminating on SIGTERM]
maralorn has quit [Quit: Bridge terminating on SIGTERM]
ili has quit [Quit: Bridge terminating on SIGTERM]
codyopel has quit [Quit: Bridge terminating on SIGTERM]
roberth has quit [Quit: Bridge terminating on SIGTERM]
Valodim[m] has quit [Quit: Bridge terminating on SIGTERM]
domenkozar[m] has quit [Quit: Bridge terminating on SIGTERM]
kalbasit[m] has quit [Quit: Bridge terminating on SIGTERM]
davidak[m] has quit [Quit: Bridge terminating on SIGTERM]
ma27[m] has quit [Quit: Bridge terminating on SIGTERM]
bachp has quit [Quit: Bridge terminating on SIGTERM]
Ox4A6F has quit [Quit: Bridge terminating on SIGTERM]
kraem[m] has quit [Quit: Bridge terminating on SIGTERM]
freeman42x[m]1 has quit [Quit: Bridge terminating on SIGTERM]
philipp[m]1 has quit [Quit: Bridge terminating on SIGTERM]
jdelStrother has quit [Quit: Connection closed]
jdelStrother has joined #nixos-dev
lopsided98_ has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 246 seconds]
michaelpj has joined #nixos-dev
lopsided98 has joined #nixos-dev
roberth has joined #nixos-dev
garbas[m] has joined #nixos-dev
Guest68587 has joined #nixos-dev
Valodim[m] has joined #nixos-dev
puzzlewolf has joined #nixos-dev
symphorien[m] has joined #nixos-dev
kraem[m] has joined #nixos-dev
LinuxHackerman has joined #nixos-dev
ryantm has joined #nixos-dev
davidak[m] has joined #nixos-dev
jtojnar has joined #nixos-dev
enick_4 has joined #nixos-dev
emily has joined #nixos-dev
JonasChevalier[m has joined #nixos-dev
DamienCassou has joined #nixos-dev
chvp has joined #nixos-dev
aanderse has joined #nixos-dev
nh2[m] has joined #nixos-dev
bbigras has joined #nixos-dev
Dandellion has joined #nixos-dev
zuh0 has joined #nixos-dev
maralorn has joined #nixos-dev
siraben has joined #nixos-dev
timokau[m] has joined #nixos-dev
ili has joined #nixos-dev
Ox4A6F has joined #nixos-dev
kalbasit[m] has joined #nixos-dev
danielrf[m] has joined #nixos-dev
colemickens has joined #nixos-dev
thefloweringash has joined #nixos-dev
jonge[m] has joined #nixos-dev
immae has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
Ericson2314 has joined #nixos-dev
mjlbach has joined #nixos-dev
rnhmjoj has joined #nixos-dev
rmcgibbo[m] has joined #nixos-dev
philipp[m]1 has joined #nixos-dev
alexarice[m] has joined #nixos-dev
regnat[m] has joined #nixos-dev
ma27[m] has joined #nixos-dev
Raito_Bezarius has quit [Ping timeout: 240 seconds]
Raito_Bezarius has joined #nixos-dev
ScottHDev5 has quit [Quit: Ping timeout (120 seconds)]
ScottHDev5 has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
<siraben>
So this was interesting to find over and over again, just because `buildInputs = []` doesn't necessarily mean the package has no dependencies, e.g. because of things like string interpolation + wrapper scripts.
<siraben>
How do I get all the direct dependencies of a package, regardless of being in buildInputs or not?
jdelStrother has quit [Quit: Ping timeout (120 seconds)]
<sterni>
siraben: probably via the derivation
<sterni>
i. e. nix show-derivation inputSrcs and inputDrvs
<sterni>
at least I'd think this also tracks string dependencies etc.
AlwaysLivid has quit [Ping timeout: 268 seconds]
janneke_ has joined #nixos-dev
janneke has quit [Ping timeout: 272 seconds]
janneke_ is now known as janneke
orivej has joined #nixos-dev
rj has joined #nixos-dev
<siraben>
sterni: i'll look into that
<siraben>
How do people package Rust programs for Nixpkgs that need Rust nightly?
<symphorien[m]>
export RUSTC_BOOTSTRAP=1
<symphorien[m]>
but don't tell rust devs, the will (and have already) complained
<siraben>
What's bad about it?
<siraben>
Huh I don't see that flag in the Nixpkgs manual
<symphorien[m]>
it's interpreted by rustc stable to "unlock" nightly features
<symphorien[m]>
it's only meant to allow rustc to bootstrap, because rustc uses nightly features
<siraben>
Heh
ghuntley has quit []
ghuntley has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
manveru has quit []
manveru has joined #nixos-dev
abathur has quit [Quit: abathur]
abathur has joined #nixos-dev
<sterni>
siraben: no nightly in nixpkgs generally though
jonringer has joined #nixos-dev
Rovanion has quit [Ping timeout: 245 seconds]
<aminechikhaoui>
copying from #nixos as I didn't get an answer: What process should be used to update vendorSha256 for Go packages ?
<supersandro2000>
invalidate it and recalc or use nix-update
<supersandro2000>
nix-update also prints an expression you can use to calculate it
orivej_ has quit [Ping timeout: 264 seconds]
<clever>
,tofi aminechikhaoui
<{^_^}>
clever: Did you mean tofu?
<{^_^}>
aminechikhaoui: To get a sha256 hash of a new source, you can use the Trust On First Use model: use probably-wrong hash (for example: 0000000000000000000000000000000000000000000000000000), then replace it with the correct hash Nix expected. For inserting 52 0's in vim: <esc>52i0<esc>
<clever>
infinisil: your code is too smart! lol
<infinisil>
*magic* (but really just levenshtein distance ;))
<aminechikhaoui>
Thanks I didn't know it applies also for the vendor dir, though I guess it's the same mechanism as it's a fixed output derivation
<ekleog_>
Opinion: environment.etc should be used only when strictly necessary, and if possible a hand-made systemd service with the right `--config ${writeText "cfg" the-config}` would be better. What do you think? (cc aanderse for this discussion, context being a comment on #113620)
<supersandro2000>
ekleog: Do I understand you correctly that you want to write a systemd service to create a file?
<aanderse>
supersandro2000: no ekleog_ means that the systemd service should contain `--config ${config-from-nix-store}` in its `ExecStart` line
<ekleog>
^ yup this (which unfortunately means we can't reuse the package-provided systemd service, so in a way yes it means we have to write the systemd service in nix-land)
<aanderse>
ekleog_: some people insist configuration files for systemd services shouldn't be placed under `/etc` (whenever possible, of course), while other people put them in all the time... generally i agree we shouldn't use `/etc` for that... but too many times practicality trumps that :(
<supersandro2000>
nix can't do an overwrite?
<aanderse>
ekleog: supersandro2000 we **can** overwrite!
<aanderse>
finding example
<aanderse>
** finding good example :D
<supersandro2000>
just overwrite that from upstream?
<supersandro2000>
systemctl edit name.service
<ekleog>
aanderse: agreed, it's also the reason why I landed, mostly wanted to figure out whether there'd be opposition to the philosophical stance of “there should ideally be nothing in /etc” ^^'
<ekleog>
supersandro2000: AFAIK the only way to do that without rewriting the systemd service would be to create a new derivation that copies and edits the .service file and put that new derivation in systemd.packages; which would indeed be possible but probably be quite a bit of boilerplate
<aanderse>
ekleog: having an unstable path in `ExecStart` also has implications if we ever want to improve the state of systemd restart vs reload
<aanderse>
ekleog: include the package via `systemd.packages` and then overwrite the `ExecStart` line and it works like a charm
<ekleog>
like, I think there are 3 solutions: 1) environment.etc + systemd.packages, 2) systemd.services like the powerdns link above, and 3) systemd.packages with a dynamic derivation that patches the .service file with the appropriate config'
<aanderse>
#2 is easiest i believe, and most practical
<aanderse>
#3 isn't practical because a "bug" in nixos means you have to override upstream units included via `systemd.packages` anyways
<aanderse>
(specifically nixos can't utilize the upstream units "wantedBy" values)
<ekleog>
hmm I hadn't thought of restart/reload… I guess this comes at a natural opposition to the ability to run multiple instances of a single service on a single machine :/
<ekleog>
(also yes I'm with you that IMO #2 is my favorite one)
<aanderse>
multiple instances of service is something nixos isn't good at currently :(
<aanderse>
but...
<aanderse>
michael raskin (who maybe doesn't hang out on irc anymore?) has that RFC to improve the settings file situation in nixos
<aanderse>
i have a feeling that might lend itself to improve the situation
<ekleog>
I seemed to understand SLNOS had figured out some way to reuse the nixos modules to make them multiply-instantiatable, so it feels like something that could happen without a world rewrite
<aanderse>
i haven't followed the rfc closely enough, though
<ekleog>
oh I hadn't followed that rfc
<aanderse>
ekleog: i didn't know that anyone had figured out some sort of way to do that
<aanderse>
have any examples handy?
<aanderse>
technically you can do it with nixos, but writing and maintaining modules like that is a nightmore
<aanderse>
the code baloons
<ekleog>
unfortunately it's SLNOS so no source available so it's just my recollection of hear-say from a few years :/
<ekleog>
oxij might be able to say more, but my own investigations with module systems ended up with “by changing the way the fixpoint happens it'd probably be possible to make it happen”
<aanderse>
eelco had that idea for a revamped module system that could do this
<gchristensen>
it isn't clear to me that slnos is really a thing
<ekleog>
I had a few email exchanges with oxij that kind of strongly indicated there was something, though the number of contributors is unclear
<ekleog>
(never saw code either that said, so it's possible that it was more “planned work” than “done work”, though it's not the way it sounded to me)
<aanderse>
i think it was 2 nixcons ago eelco had that proposal
<ekleog>
oh yes the MichaelRaskin RFC is the one about using config generators, now I remember :)
<aanderse>
there, found the link for eelcos proposal
Cale has joined #nixos-dev
<ekleog>
ooh yes this one, it's among the things I kind of hope don't happen because it'll be a huge migration cost and I think other directions would lead to a better result with a similar migration cost
<aanderse>
yeah, i mean... i want the results, but not the big migration cost :D
<ekleog>
heh ^^
rajivr has quit [Quit: Connection closed for inactivity]
copumpkin has quit [Remote host closed the connection]
copumpkin has joined #nixos-dev
<aanderse>
ekleog: so... next steps? :)
<ekleog>
aanderse: not sure, to me it's mostly “continue telling people solution #2 is best except when it'd be a bother”, it's totally doable to migrate from one to the other after the fact anyway
rj has joined #nixos-dev
ris has joined #nixos-dev
mkaito has quit [Quit: WeeChat 3.0.1]
<aanderse>
ekleog: i was hoping you'd have something to say about multiple instances of nixos modules ;-)
<cole-h>
supersandro2000: That package doesn't have any platforms (so whatever buildPythonApplication specifies is what it has), while essentia-extractor only supports x86_64/i686 linux
<cole-h>
supersandro2000: and also, why use `substituteInPlace` over `sed`?
justanotheruser has quit [Ping timeout: 264 seconds]
rj has joined #nixos-dev
BaughnLogBot_ has joined #nixos-dev
eyJhbV2 has joined #nixos-dev
puckipedia has joined #nixos-dev
infinisi1 has joined #nixos-dev
qyliss_ has joined #nixos-dev
aminechikhaoui9 has joined #nixos-dev
danderso1 has joined #nixos-dev
pmy_ has joined #nixos-dev
<ekleog>
aanderse: ooh that… well I started some experiments on https://github.com/NixtOS/nixtos/ (not sure why I even made an org for that, but now it's done so w/e), which would probably have a similar amount of churn for IMO more benefits, put it on the backburner for now (focusing on another project) but when I go back to it I think I'll look into how much it'd be possible to reuse the current
<ekleog>
nixos modules in this infrastructure
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
<ekleog>
(now… it's probably way too much churn, so unless it's really easy to reuse the current nixos modules it's probably not going to be worth it)
aminechikhaoui has quit [*.net *.split]
abathur has quit [*.net *.split]
pmy has quit [*.net *.split]
puck has quit [*.net *.split]
qyliss has quit [*.net *.split]
FireFly has quit [*.net *.split]
danderson has quit [*.net *.split]
maljub01 has quit [*.net *.split]
niksnut has quit [*.net *.split]
BaughnLogBot has quit [*.net *.split]
infinisil has quit [*.net *.split]
eyJhb has quit [*.net *.split]
energizer has quit [*.net *.split]
aminechikhaoui9 is now known as aminechikhaoui
qyliss_ is now known as qyliss
puckipedia is now known as puck
eyJhbV2 is now known as eyJhb
BaughnLogBot_ is now known as BaughnLogBot
Effilry has joined #nixos-dev
eyJhb has quit [Changing host]
eyJhb has joined #nixos-dev
<aanderse>
oh wow you wrote a ton there
supersandro2000 has quit [Client Quit]
energizer has joined #nixos-dev
supersandro2000 has joined #nixos-dev
<ekleog>
I got to a bootable VM, IIRC last I checked it was at the status of “for some reason eudev doesn't autoload the e1000e module”
<ekleog>
probably should have started with systemd, even though one of the ideas was to make something that's init-system-agnostic proving that from the beginning was probably not worth it
abathur has joined #nixos-dev
<ekleog>
the core idea is to change the fixpoint so that all the edges (dependencies between modules) are explicit and user-overridable
<aanderse>
ok
<aanderse>
right
maljub01 has joined #nixos-dev
niksnut has joined #nixos-dev
danderso1 is now known as danderson
rj has quit [Ping timeout: 268 seconds]
rj has joined #nixos-dev
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
pinpox has quit [Write error: Connection reset by peer]
Effilry is now known as FireFly
<gchristensen>
does initrd.secrets make the initrd's not readable by non-root users? seems it should ...
<symphorien[m]>
I think the whole /boot is read protected
<gchristensen>
hm
rj has quit [Ping timeout: 268 seconds]
rj has joined #nixos-dev
<LinuxHackerman>
gchristensen: tricky on FAT :) I mount my boot partitions on EFI machines with initrd secrets with umask=077 for that reason
<gchristensen>
:/
<LinuxHackerman>
though yeah the concatenation script should probably refuse to write to a world-readable file