sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.03 released! https://discourse.nixos.org/t/nixos-19-03-release/2652 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 19.03 RMs: samueldr,sphalerite | https://logs.nix.samueldr.com/nixos-dev
catern has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
niksnut has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
justanotheruser has quit [Ping timeout: 272 seconds]
drakonis_ has quit [Ping timeout: 252 seconds]
justanotheruser has joined #nixos-dev
justan0theruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 244 seconds]
drakonis1 has joined #nixos-dev
hedning_ has quit [Remote host closed the connection]
drakonis1 has quit [Quit: WeeChat 2.4]
drakonis_ has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis has quit [Ping timeout: 258 seconds]
drakonis1 has quit [Quit: WeeChat 2.4]
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
orivej has joined #nixos-dev
justan0theruser has quit [Ping timeout: 248 seconds]
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
Synthetica has joined #nixos-dev
lopsided98 has quit [Ping timeout: 248 seconds]
lopsided98 has joined #nixos-dev
niksnut has quit [Ping timeout: 245 seconds]
niksnut has joined #nixos-dev
emily has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-dev
nwspk has joined #nixos-dev
emily has joined #nixos-dev
<domenkozar[m]> LnL: is there non-interactive mode for nix-darwin?
<domenkozar[m]> and subquestion: would you approve of one? :)
<LnL> non-interactive?
orivej has quit [Ping timeout: 244 seconds]
<domenkozar[m]> not asking for input
orivej has joined #nixos-dev
<LnL> not following, what part?
<domenkozar[m]> Installing nix-darwin...
<domenkozar[m]> Would you like edit the default configuration.nix before starting? [y/n] n
<LnL> you can pipe yes to the installer
<LnL> I do that in the travis tests
johnny101 has quit [Remote host closed the connection]
johnny101 has joined #nixos-dev
init_6 has joined #nixos-dev
init_6 has quit []
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 272 seconds]
<domenkozar[m]> is there a no equivalent?
<samueldr> yes "n"
<gchristensen> "yes n"
<samueldr> (it would have been funny just to answer 'yes')
<gchristensen> lol
<LnL> you want yes, the edit question only happens for interactive shells
Jackneill has quit [Ping timeout: 248 seconds]
Jackneill has joined #nixos-dev
<Profpatsch> domenkozar[m]: btw we noticed that the Travis nix darwin installer sets up daemon mode. Is there a reason we don’t install as single-user mode on Darwin?
<Profpatsch> It takes nearly a minute to set up all build users.
<niksnut> https://github.com/NixOS/nix/issues/2925 <- this sounds like the end of nix on macos
<{^_^}> nix#2925 (by mroi, 16 minutes ago, open): /nix will not be writable on macOS Catalina
<Profpatsch> niksnut: Can’t we just give a new prefix?
<Profpatsch> The Schadenfreude is strong with this one, even though it’s childish.
<domenkozar[m]> Profpatsch: it used to be single-user
<Profpatsch> To tell it with n-gate words: “Apple continues the war against its own users”
<domenkozar[m]> then daemon became the default
<domenkozar[m]> and nix version got pinned
<domenkozar[m]> now it's stuck in 2017 :)
<Profpatsch> domenkozar[m]: Ah, you think we can update?
<Profpatsch> Single-user is the default again, right?
<domenkozar[m]> yes, but you're going to break some setups.
<niksnut> Profpatsch: using a different prefix means we would have to have a separate hydra instance and a separate binary cache for macos
<Profpatsch> What could the switch break?
<domenkozar[m]> well you can use different users with sudo, etc
<domenkozar[m]> I personally don't care and I think YOLO
<Profpatsch> domenkozar[m]: All of Travis is YOLO at this point
<domenkozar[m]> but I never did the change because there would be someone like usual to say "you should totally spend another 10h" to make this better service than Apple can provide :P
<Profpatsch> domenkozar[m]: If one is single-user and the other is multi-user by default, we don’t have any guarantees anyway.
<domenkozar[m]> if you feel like doing it, I'd support such breakage anyway.
<Profpatsch> If people really need multiuser, we can add nix-daemon as a separate setup.
<Profpatsch> Where both Linux and Unix install a daemon.
<domenkozar[m]> they can pin Nix version
<domenkozar[m]> so for those that want to be stuck in history it's oneliner
<Profpatsch> Or that
<Profpatsch> Ok, I’ll try to see what I can do.
drakonis_ has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
<aminechikhaoui> niksnut ugh, that's really annoying, every MacOS release comes with more challenges :/
<aminechikhaoui> But I don't get why we need a different hydra/binary cache, since the nix store is configurable, can't the macs have a different config for the store and still use the same binary cache ?
orivej has quit [Ping timeout: 248 seconds]
Jackneill has quit [Ping timeout: 248 seconds]
<gchristensen> NixOS containers with `autoStart = true` have `restartIfChanged = false; reloadIfChanged = true; restartTriggers = [ some-paths ];` if these paths change will it restart or reload?
Jackneill has joined #nixos-dev
<arianvp> gchristensen: if you figure out, please let me know in https://github.com/NixOS/nixpkgs/issues/49528 :)
<{^_^}> #49528 (by arianvp, 31 weeks ago, open): systemd: Interactions of `restartIfChanged, reloadIfChanged, stopIfChanged` is fragile
<arianvp> I think I opened that one up exactly when I was messing around with containers
<gchristensen> lol
<gchristensen> joy :D
orivej has joined #nixos-dev
<arianvp> The best part is > restartIfChanged never behaves as documented
<arianvp> if you wanna dive into the activation logic together to get it fixed, let me know
<arianvp> and to answer your question: Yes I think it will trigger a reload in this case
<gchristensen> what do you think it should do in this case?
<arianvp> reload if any of the files change
<arianvp> Hmm
<arianvp> restartTriggers isn't mentioned in the activation logic
<arianvp> only thing it does is set X-Restart-Triggers on the unit (in modules/system/boot/systemd.nix) which causes the file to be in the closure of the mentioned unit
<arianvp> so if the file changes, the unit changes too, triggering either a reload/restart/start-or-stop
<gchristensen> that seems reasonable
<arianvp> s/files/nix store path
<arianvp> so this is useful if you have an nginx config that you want to bind to the nginx unit
<arianvp> systemd.services.nginx.restartTriggers = [ pkgs.writeText "nginx.conf" "iamaconfig" ];
<arianvp> then if the content of nging.conf changes, nginx gets restarted/reloaded/stop-and-started
<gchristensen> right
<gchristensen> okay so restartTriggers is really just hinst towards whether to restart or reload
<arianvp> yes
<gchristensen> so it is like, "updateAction = restart | reload; updateTriggers = [ ... ]`
<arianvp> yes that would be a less confusing naming scheme to me
<gchristensen> I wonder what the use fo reload is
* arianvp greps for reloadIfChanged
<arianvp> some services support full reloading of config without restarts
<arianvp> but I'm not sure why we even have this implemented in nixos. systemd already has a "systemctl try-reload-or-restart" command
<gchristensen> ahh like sending nginx a hup or something
<arianvp> bigger question is. what's the difference between "restart" and "stop-and-start"
<arianvp> gchristensen: yes
<gchristensen> okay
<gchristensen> then I feel pretty confident that replacing reloadIfChanged = true; with restartIfChanged = true; plus adding config.environment.etc."containers/${name}.conf".source to the restartTriggers list is the right thing here
<arianvp> (im not sure if my explanation of stopIfChanged /restartIfChanged is correct in that issue)
<niksnut> aminechikhaoui: no, every binary cache has a specific store location
<niksnut> see the line 'StoreDir: /nix/store' in https://cache.nixos.org/nix-cache-info
<niksnut> also, the store location affects hash computation
<arianvp> gchristensen: aha , systemctl restart is wrong because it will start the old configuration binary
<niksnut> so nix-instantiate will produce different hashes given different store prefixes
<arianvp> instead of the new one. that's why stopIfChanged = true; is a sane default
<arianvp> it will stop the old one, and start the new one
<gchristensen> okay got to go for about 1h
<aminechikhaoui> niksnut oh I see. I still don't understand why we need the binary cache to expose a store dir path or why the derivation would depend on which store dir is used ?
<niksnut> because paths are not relocatable, e.g. a binary that has an RPATH referring to /usr/local/nix/store won't work if you move it to /nix/store
<aminechikhaoui> ohh
<aminechikhaoui> makes sense yeah
* samueldr wonders if POSIX mandates ability to write to /
<samueldr> or uh, UNIX even
<samueldr> as macOS is UNIX
<samueldr> if it does: will they lose unix cert or back out?
<samueldr> or maybe allow adding new firm links?
<aminechikhaoui> it doesn't seem like they really care it's a UNIX/POSIX :D
<samueldr> sure, that's kinda my point there, wondering if they're willing to lose it, there might be (commercial) users of macOS only allowing it since it's unix
<arianvp> I actually think macOS does allow for relocatable binaries
<arianvp> solaris supported it too iirc
<arianvp> something weird with RPATH dont remember exactly. but wish linux had it too
<arianvp> I got pretty far where I got everything except the shared object loader to be relocatable. but that's not enough
drakonis has joined #nixos-dev
<ekleog> there really are days where I wonder what the point of having /nix in / actually is apart from an extremist stance on “we're not regular package managers”
drakonis_ has quit [Ping timeout: 257 seconds]
<niksnut> ekleog: what would be a better location? /usr? /usr/local? /opt? /var?
<ekleog> /opt/nix would at least place the store in a location that's known by FHS
<ekleog> it's also where packages locally installed “in a batch” usually end up, in /opt/packagename (while other packages get installed split into /usr/local/*, but that wouldn't make sense for nix)
<ekleog> (I know I've got at least a friend who's blocked on an anti-nix stance, and whose last argument against trying has been “I don't want to use something that breaks FHS” because of things being in /nix and not eg. /opt -- not saying that's a reasonable stance but it's his)
<ekleog> now, all this is just idle ranting, I can't even think of a way to handle migration from /nix to /opt/nix in realistic conditions, so… we're most likely stuck with what we currently have :)
<niksnut> I mean, Nix breaks the FHS in every other way, so whether it's /nix or /opt/nix doesn't matter much
<ekleog> yeah totally, but sometimes people feel better having a place for “random stuff that we don't know what to do of” in /opt than in /
<niksnut> having said that, /nix/var should be /var/.../nix
<ekleog> ideally we'd be able to make relocatable builds for most packages, which would solve that issue as well as the unprivileged usage of a binary cache, but that's something that'd likely be awfully complex to implement
<gchristensen> arianvp: what did you think about that commit?
<gchristensen> niksnut: https://github.com/NixOS/nixpkgs/commit/b0b9a9da72d7fe557b50ba5919a956764e3a30ca does this look right to you? w.r.t. our prior conversation around nixos containers restarting when their bind mounts change
<niksnut> gchristensen: looks good to me
<niksnut> hm wait, what is containerConfig.path?
<gchristensen> I'm not sure what exactly it is :|
<gchristensen> X-Restart-Triggers=/nix/store/3iwsxb6ps64miiphhf0n63rf6dg46z36-nixos-system-buildkite-builder-grahamc-5-19.03.git.6eabdec
<niksnut> weird
<niksnut> because that causes the container to be restarted every time the NixOS configuration *inside* the container changes
<gchristensen> yeah
<niksnut> which defeats the original point
<niksnut> so then you might as well restart on any change (remove the restart trigger)
<gchristensen> hmm not sure
<gchristensen> because path could be a path to another point on disk, not managed by the host's nixos-rebuild. I think this is only part of the case where the container's config is defined by the host
<gchristensen> for example, containers deployed via nixops
<niksnut> yes, that's true
<gchristensen> so I think this will still do the right thing
<arianvp> niksnut: would you be open to changing the restartIfChanged / stopIfChanged foo to an enum? (See issue I linked)
<{^_^}> #62779 (by grahamc, 22 seconds ago, open): Restart declarative containers when their host environment configuration changes
<matthewbauer> does anyone know how to fix this: https://hydra.nixos.org/build/94417826 ?
<matthewbauer> a few more system doubles seem to have hit the log limit, can we increase it?
<samueldr> matthewbauer: I guess a PR upping max_log_size in https://github.com/NixOS/nixos-org-configurations/blob/master/delft/hydra.nix#L30 could be something
<matthewbauer> maybe we can just make the output smaller
<matthewbauer> i was hoping there was a per-job way to increase max_log_size
<gchristensen> what made the output go up?
<samueldr> slow creep it looks like
<samueldr> oof, the charts page of metric is heavy
drakonis_ has joined #nixos-dev
* samueldr thinks the log metric might not be looged
<matthewbauer> it adds 7 lines per derivation
<matthewbauer> but it was already pretty close to the limit before
<gchristensen> ouch, 7x is a lot
<gchristensen> what is the impact, evaluation-wise, of adding these?
drakonis has quit [Ping timeout: 252 seconds]
<niksnut> if you hit the log limit, it's an unsubtle hint that you need to produce less log output :-)
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
<gchristensen> with all the patches I'm accumulating on master, I am tempted to switch to unstable :x
<domenkozar[m]> should rename it to latest, that would make it more appealing :D
<gchristensen> we could come up with a name like Sid or Tumbleweed
<manveru> you could call it Achilles :)
drakonis_ has joined #nixos-dev
genesis has quit [Remote host closed the connection]
genesis has joined #nixos-dev
<gchristensen> eh I think I'll just apply patches to it
sir_guy_carleton has joined #nixos-dev
copumpkin has quit [Read error: Connection reset by peer]
copumpkin has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
drakonis has joined #nixos-dev
orivej has joined #nixos-dev
callahad6 is now known as callahad
sir_guy_carleton has quit [Quit: WeeChat 2.4]
tilpner has quit [Quit: WeeChat 2.4]
tilpner has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 248 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 248 seconds]
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 272 seconds]
drakonis1 has joined #nixos-dev
<dhess> samueldr: people used to run Linux/SunOS/other UNIX diskless workstations with their / mounted ro via NFS all the time.
<dhess> when disks were slower, smaller, less reliable, and more expensive.
<samueldr> right, but being able to is not equivalent to mandated, though was more of an idle thought
<dhess> well to be pedantic, you can boot macOS 10.15 with this feature disabled, so it's not mandated there, either.
<samueldr> when will they drop the unix?
<samueldr> and how? what part of macOS will stop being compliant?
<dhess> macOS will always be UNIX. They'll drop it and run their laptops on iOS/iPadOS before they make a drastic change like that to macOS.
<samueldr> (not being fascetious, genuinely curious)
<dhess> there's no point making major changes to macOS anymore. It's not a strategic platform anymore for them.
<dhess> This is reflected in the fact that new versions of macOS hardly have any new functionality. It's mostly just locking down what's there to try to make it more secure. Barely any new features compared to what's happening with iOS, Windows, Linux, Android, etc.
<dhess> If they remove UNIX functionality, there's no longer any reason for macOS to exist.
<drakonis1> so, we're on the cusp of doing away with macOS support after catalina releases?
<samueldr> [citation needed]
<drakonis1> cusp is not the right owrd
<drakonis1> word for this
<{^_^}> nix#2925 (by mroi, 10 hours ago, open): /nix will not be writable on macOS Catalina
<drakonis1> there we go
<samueldr> sounds like there are solutions to issues
<drakonis1> the solutions werent there when i last checked, but that looks like its solvable
<drakonis1> disregard what i said