<arianvp>
gchristensen:you around? have a question about path units
<gchristensen>
sort of, go for it :
<gchristensen>
)
<arianvp>
I was wondering why you have a RequiredBy on the wireguard path unit, as a path unit already implicitly activates the service unit of the same name
<arianvp>
is it to enforce that it is _not_ activated before a change occurs?
<arianvp>
it referring to the wireguard _service_
<gchristensen>
ah
<gchristensen>
I'm not sure I can give you a super good answer there ... it could maybe not even have the RequiredBy
<gchristensen>
you could try deleting that directive and building the "generated" nixos test
colemickens has quit [Ping timeout: 240 seconds]
Synthetica has quit [Ping timeout: 258 seconds]
sorear has quit [Read error: Connection reset by peer]
Synthetica has joined #nixos-dev
colemickens has joined #nixos-dev
sorear has joined #nixos-dev
<arianvp>
hmm I think path units aren't gonna help me here
<arianvp>
I misunderstood them. I though the path unit would be active iff the file exists
<arianvp>
but that's not the case. the path unit is always active, and starts another unit when state changes
<arianvp>
gchristensen:so I think actually in the wireguard module it also does something different than we think
<gchristensen>
yikes :
<gchristensen>
:?
<arianvp>
what it does now, is start "wireguard-${name}.service" any time the keyfile is touched
<arianvp>
think of path units as .timer units. they activate another unit when some condition is met
<arianvp>
which is something different than what we're trying to describe =)
<arianvp>
(right?)
<gchristensen>
yeah I think so
<gchristensen>
maybe a ConditionPathExists + the .path unitis what I wanted
<arianvp>
the idea is that you activate a path unit on boot, by doing WantedBy=paths.target just like you activate a timer at boot
<arianvp>
and then each time the "blah.path" unit changes, it activates the corresponding "blah.service"
<arianvp>
maybe i should start a systemd consultancy or something. hehe
<gchristensen>
:
<gchristensen>
)
justanotheruser has joined #nixos-dev
orivej has joined #nixos-dev
Synthetica_ has joined #nixos-dev
Synthetica has quit [Ping timeout: 258 seconds]
Synthetica_ is now known as Synthetica
Synthetica has quit [Quit: Connection closed for inactivity]
<Taneb>
When people talk about content-addressable stores, what does that actually mean?
<gchristensen>
someone gave it that name, and if you fetch it and it arrives corrupted you have no idea
<arianvp>
Taneb: that the hash in the path in nix store is the hash of the contents stored at that path
<arianvp>
For example. Source files in the nix store are addressed by content
<gchristensen>
if it was content-addressed, it would be named ea7daa44f385c253753a3726628d611f678e53a1b78c2bb64037bfcc14870e65 (the hash of the file's contents)
<arianvp>
But produced files and bin (like output fromC)
<arianvp>
Accidentally pressed enter there. Ooos
<arianvp>
Build outputs are not content addressed in nix, the path of builds outputs is the hash of all _inputs_ instead.
<yorick>
gchristensen: how do you make those graphs?
<{^_^}>
nix#2782 (by grahamc, 2 days ago, open): Track function start and end
<yorick>
oh, cool
<yorick>
define "lot of memory"
<Taneb>
arianvp: OK, this makes sense
<gchristensen>
yorick: I use nearly all of my RAM + swap space, which totals 32G
<arianvp>
So for now. Only source files are content addressed (they have no build inputs)
<yorick>
gchristensen: but this is all of nixpkgs
<arianvp>
But there is a plan to also rewrite build outputs to be content addressed. This is useful when for example you change the source code of glibc, but the output doesn't change becauss of it
<arianvp>
It avoids mass rebuilds
<gchristensen>
yorick: right, so the output from the trace is quite large (a few hundred mb)
<arianvp>
There's an RFC that explains the rationale why this is useful.
<gchristensen>
yorick: the part which requires like 32gb of RAM is running flamegraph.pl
<Taneb>
Doesn't that have the cost of making it so you need to build something to know where in the nix store you'd find it?
<arianvp>
There's also an entire chapter in Eelco's thesis
<gchristensen>
it does, Taneb
<arianvp>
Iirc there is a mapping stored between input hashes and output hashes, right?
<gchristensen>
that is maintained in the result derivations themselves I think
<gchristensen>
definitely check the RFC for specifics :)
<yorick>
gchristensen: what causes this to use that much memory?
<arianvp>
Also what it brings is ability to trust builds without them being signed. Because if builds are reproducibility multiple untrusted builders will produce the same output
<gchristensen>
and a bit mysterious that 18.09 wasn't a problem
<LnL>
thought there was something with a fallback based on stateVersion
psyanticy has quit [Quit: Connection closed for inactivity]
ckauhaus has quit [Quit: WeeChat 2.4]
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 245 seconds]
n_db has quit [Remote host closed the connection]
jtojnar_ is now known as jtojnar
n_db has joined #nixos-dev
justanotheruser has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Quit: WeeChat 2.4]
justanotheruser has joined #nixos-dev
<gchristensen>
for people operating a Hydra who could also use Packet (hem, fpletz, globin, sphalerite) I've made a packet.net spot instance instance importer for Hydra -- https://github.com/NixOS/nixos-org-configurations/pull/85