<red[evilred]>
Should I just be adding those to the pkgs/tools/backup/bacula/default.nix as a propogatedBuildInput
<red[evilred]>
or somehow including that in the nixos/modules/services/backup/bacula.nix service definition
<red[evilred]>
where's the right place to put it?
<red[evilred]>
(right now - I get everything to work by placing that line above directly in the configuration.nix - but those dependencies need to be added as a part of the build / configuration process)
<red[evilred]>
I mean -=- I could add as part of the docs "add systemd.services.bacula-dir.path = [ pkgs.gawk pkgs.mtx pkgs.mt-st pkgs.su ];" to your configuration.nix - but that doesn't seem correct
<red[evilred]>
(or... should I be pushing what I have so far - marking it as WIP and asking in a PR for advice?)
<red[evilred]>
what's the right workflow for asking for implementation advice?
<red[evilred]>
nm - I think I found it
ris has joined #nixos-dev
orivej has joined #nixos-dev
pmy has quit [Ping timeout: 265 seconds]
pmy has joined #nixos-dev
justanotheruser has joined #nixos-dev
scott has quit [Ping timeout: 240 seconds]
scott has joined #nixos-dev
<symphorien[m]>
red[evilred] those should be added to PATH with makeWrapper/wrapProgram in the bacula nix package (not the module)
<symphorien[m]>
except for su for which you should add /run/wrappers/bin to PATH instead of ${pkgs.su}/bin because it needs setuid
<gchristensen>
what if nixos profiles had a toolbox of "rescue tools" relevant to their use case, like a cloud server might have cloud-utils, but a baremetal machine might have, I dunno, memtest
<qyliss>
strong approve
<red[evilred]>
is the number/size of tools high enough that you can't just include them all?
<gchristensen>
yeah the minimal install should probably remain pretty minimal
<red[evilred]>
I guess I can see a time when I might need <X>, which is in one profile but not the profile that I'm in.
<red[evilred]>
Bingo - that's the missing piece - thank you.
<red[evilred]>
Also - gchristensen (IRC) - I sent you a DM in irc and in twitter - if you get a chance to get to it. No hurry.
<red[evilred]>
guessing you're busy a tad.
<samueldr>
gchristensen: which overloaded definition of profiles do you mean?
<gchristensen>
any :P
<gchristensen>
red[evilred]: cool, will ook, thank
<gchristensen>
s
thibm has quit [Quit: WeeChat 2.6]
<domenkozar[m]>
oh man
<domenkozar[m]>
lost like 3h hours today
<domenkozar[m]>
because fixed output derivations don't calculate hash of the inputs
<qyliss>
If I understand correctly, presumably so that we don't have to rehash every tarball whenever gcc updates
<domenkozar[m]>
ah right they depend on stdenv
<lassulus>
wouldn't a trivial change in the source then force a complete rebuild?
<domenkozar[m]>
well it could be chosen inputs
<samueldr>
depending on what you do, you could output the store path paths you choose (or hash thereof) next to the fixed output
<samueldr>
but yeah, that's not a global solution
<qyliss>
an FOD is only really for when you know the hash in advance. If that's dependent on an input, it's probably not a good use of FODs.
<samueldr>
that's a good way to phrase it
<qyliss>
Like, the purpose of FODs in the system to let you bring in inputs without having to IFD or keep them in Nixpkgs
<samueldr>
FODs have been (ab)used a lot with not-exactly-fixed outputs, like language-specific package management
<qyliss>
Yeah
<samueldr>
though, trying to psychic debug, even if you did have those inputs hashed into the FOD, it might not have helped if you didn't break the expected hash during the development
<samueldr>
because if the expected hash is present in the store, it's used
<qyliss>
Yeah that's the other problem
<domenkozar[m]>
yeah I also noticed it's possible to have non-deterministic FOD
<domenkozar[m]>
if the hash will always be different, when nix tells you the hash is X but not Y
<domenkozar[m]>
you can take X and it will just reuse that derivation
<samueldr>
that's because it's not actually F, but Nix has no way to know you're (unconciously) lying to it :)
<domenkozar[m]>
well I wouldn't say I'm lying, Nix is telling me me the hash
<gchristensen>
they used to include the name in the nar hash I think, but we renamed everything to source
<gchristensen>
I would like to put names back in the path because of this
<domenkozar[m]>
well in this case is due to postFetch
<samueldr>
gchristensen: that's when the source file includes the version number, one of the problematic bits
<samueldr>
but if the fixed-output is not actually fixed, for any reason, then that wouldn't change anything
<gchristensen>
ah
<domenkozar[m]>
I think previously Nix would say the hash is X
<domenkozar[m]>
but then it would rebuild the fixed output again
<domenkozar[m]>
now it just caches the one with wrong hash
<gchristensen>
what if it printed that the drv changed but the hash stayed the same?
<samueldr>
since I've been using nix it's been that way, so "now" must have been a good while back (3+ years)
<gchristensen>
(and thus didn't build)
<gchristensen>
b/c it is really nice to tofu and not need to fetch 2x
<domenkozar[m]>
yeah I guess I'd notice it sooner than later
<qyliss>
This is a common thing people get confused by
<domenkozar[m]>
yup
<samueldr>
not saying it's not possible, I really haven't thought about it much, but what about when you want to use the same FOD hash?
<samueldr>
when e.g. you change the source location
<samueldr>
but it's the same tarball
<adisbladis>
samueldr: We already do this quite a lot (mirrors)
<samueldr>
does mirrors change the .drv?
<gchristensen>
then I'd be unsurprised by the "the derivation changed but the hash changed the same" notice
<domenkozar[m]>
I think each builder knows which inputs matter
<samueldr>
(I knew about mirrors, and didn't bring that up because I didn't know that detail)
<qyliss>
Yeah having a warning would make sense
<adisbladis>
samueldr: I'd suspect so
<qyliss>
if it were possible
<samueldr>
when does that notice get "acknowledged"?
<qyliss>
good question
<samueldr>
I know people would re-build twice and miss it if it's auto-acknowledged the first time it changes
<samueldr>
but then if you just warn ALL the time it's not useful either
<gchristensen>
the first time
<samueldr>
(I'm not against! just thinking)
<gchristensen>
I'dimagine the notice printing would be "FOD drv was not built but we have the output"
<adisbladis>
samueldr: Yep, it changes the hash
<adisbladis>
(of the drv)
<samueldr>
to my 2 minutes thinking, that sounds like a warning line that's going to be lost among the output on builds
<samueldr>
what I mean is: is there a way to help it not getting lost?
<gchristensen>
only really matters when you're iterating on a thing, so not sure it matters a lot
<samueldr>
even sometimes the TOFU gets lost when there is a lot of logging
<adisbladis>
Do we know of other systems that has this same property? What do they do?
__monty__ has quit [Quit: leaving]
<samueldr>
(just want to re-iterate, most of the time when I "challenge" an idea, it's to understand it better, not to shoot it down)
<gchristensen>
(I don't feel shot down)
<qyliss>
I think if it were brightly coloured I'd see this sort of thing most of the time while iterating
<qyliss>
Sometimes I'd miss it, but it would definitely help.
<gchristensen>
yeah I don't think it needs to be front and center pretty much ever
<qyliss>
It doesn't have to be perfect.
<gchristensen>
just visible enough to catch your eye if you're hammering on a thing and wondering why it won't move, imo
<qyliss>
Yeah
<gchristensen>
in fact I'd expect users to almost *never* see it, since users would almost always substitute
<samueldr>
would a change in stdenv flood with warnings?
<samueldr>
(on a rebuild)
<gchristensen>
yes
justanotheruser has quit [Ping timeout: 258 seconds]