worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 BETA Announced https://discourse.nixos.org/t/nixos-20-03-beta/5935 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
claudiii has quit [Quit: Connection closed for inactivity]
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
<gchristensen> jtojnar: yeah, I agree, we can add more later :)
<gchristensen> jtojnar: were you going to add a type field to your existing PR?
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-dev
<genesis> nix-env still try to pre-evaluate commented variables in comments, in Commands block :|
<samueldr> they're just strings, to nix
<genesis> yes, i donno how this works really internally, i progress step by step.
<genesis> i'd hacked some stuff this days anyway.
<genesis> i don't find how to add some native pkgs to a extraInstallCommands in a buildFHSEnv
<genesis> lookiing pkgs/build-support/build-fhs-userenv/default.nix , i don't see that possible without modify how this is done currently
<genesis> i should extract then build-fhs i guesse.
<{^_^}> firing: HomepageUpdateStuck: https://status.nixos.org/prometheus/alerts
evanjs has quit [Quit: ZNC 1.7.5 - https://znc.in]
evanjs has joined #nixos-dev
<{^_^}> resolved: HomepageUpdateStuck: https://status.nixos.org/prometheus/alerts
<genesis> i try to add something here, a kind of fixup phase, but i'm inside a let, i donno the more elegant to do
<genesis> ho man i forget again the extract is done by the wrap thingy
<genesis> i've to do it in appimageTools.wrapType2, add some fixup phase with buildinputs, but i don't want to add to extraPkgs and use the extraInstallCommands
<clever> Program terminated with signal SIGSEGV, Segmentation fault.
<clever> #0 0x00007f8c9c8a73b0 in ffi_StorePath_to_string () from /nix/store/i8im8z62d5x2vymx9gf8qlkzaplg2ppm-nix-2.4pre7250_94c93437/lib/libnixrust.so
<clever> genesis: the rough area of my segfault in hydra
<clever> gchristensen: oops, ^^
<gchristensen> heh.
<gchristensen> oof
<gchristensen> thanks!
<genesis> can i arbitrary add a phase or hook in a block ?
bhipple has quit [Ping timeout: 265 seconds]
<infinisil> genesis: What's a block?
<infinisil> Depends on how appimageTools works
<infinisil> Lemme see
<genesis> i'd like a buildInputs = [ desktop-file-utils autoPatchelfHook ];
<genesis> then this will not get populate in the buildFHSEnv
<genesis> and i dont want to default some function but provide a hook on them (so not extraInstallCommands, or a pre-hook)
<infinisil> Not really getting it..
<genesis> if i understand -but i'm a bit tired a 4AM- i derived a stdenv.mkDerivation from let buildFHSEnv = callPackage ./env.nix { }; in
<genesis> ./pkgs/build-support/build-fhs-userenv/default.nix
<genesis> was just try to demonstrate how i can extend the builder usefully to answer a review.
<genesis> hum i could perhaps do same than in haxe-package.nix
<genesis> ho no it's not same case
<genesis> if i do something like extraInstallCommands = attrs.extraInstallCommands or '' <mystuff> ${attrs.extraInstallCommands}'' but i don't solution the buildInputs, not really clean.
<genesis> anyway night.
drakonis has quit [Ping timeout: 256 seconds]
zarel_ has quit [Ping timeout: 265 seconds]
zarel has joined #nixos-dev
myskran has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
drakonis has joined #nixos-dev
cole-h has quit [Ping timeout: 260 seconds]
betawaffle has quit [Quit: Oh noes, my ZNC!]
betawaffle has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.7.1]
lovesegfault has quit [Quit: WeeChat 2.7.1]
Jackneill has joined #nixos-dev
ris has quit [Ping timeout: 265 seconds]
__monty__ has joined #nixos-dev
lovesegfault has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-dev
lovesegfault has quit [Client Quit]
lovesegfault has joined #nixos-dev
psyanticy has joined #nixos-dev
<{^_^}> firing: RootPartitionLowDiskSpace: https://status.nixos.org/prometheus/alerts
<{^_^}> resolved: RootPartitionLowDiskSpace: https://status.nixos.org/prometheus/alerts
phreedom has quit [Ping timeout: 240 seconds]
Guest30 has joined #nixos-dev
<Guest30> Hi there. What keeps unstable channel from upgrading? I found nixfmt (really indispensable for me) broken and an unbreaking PR merged on GitHub (https://github.com/NixOS/nixpkgs/commit/e9f89e0fb6546532df9872e68dd7668341cd66df). But the channel have not integrated it for 8 days.
<domenkozar[m]> nixos-unstable?
<domenkozar[m]> or which channel?
<domenkozar[m]> https://status.nixos.org/ disagrees about 8 days.
<Guest30> nixos-unstable
<gchristensen> looking at https://status.nixos.org/, it looks like nixos-unstable hasn't updated in 4 days, and clicking "nixos/trunk-combined/tested" and then clicking Constituents, it looks like the iso_minimal has been broken by some i686 muslc compilation problem(???): https://hydra.nixos.org/build/114271609
<NinjaTrappeur> Guest30 http://howoldis.herokuapp.com/
<NinjaTrappeur> too slow :)
<Guest30> I mean the commit was 8 days ago but not the whole channel
<Guest30> gchristensen thanks for your help.
<gchristensen> the commit was likely a recent merge or something, but the channel is not 8 days old
<Guest30> It looks like channel is healthy but why would this merge be blocked?
<gchristensen> look at the build link I sent :) that is why
<Guest30> Yes, I looked at it.
<gchristensen> hm it seems the build has succeeded since. let's try restarting it
<Guest30> So typically how long would it be blocked? Or is there any approximated expectation that I can make?
<gchristensen> Guest30: https://status.nixos.org/grafana/d/LhIq8iLWk/channel-updates?orgId=1&from=now-90d&to=now the second graph from the top should give you some good insight into past performance
<Guest30> Thanks. I forgot the presence of it.
<gchristensen> no worries :) it is fairly new in the scheme of things
myskran has joined #nixos-dev
phreedom has joined #nixos-dev
abathur has joined #nixos-dev
myskran has quit [Ping timeout: 265 seconds]
Guest30 has quit [Ping timeout: 256 seconds]
<arianvp> aszlig: the ping was for the fact that I'm planning to remove resolver.nix for the ACME tests.
<arianvp> we replaced its use with the DNS mock server that Letsencrypt provides in their integration test suite tool Pebble
<arianvp> and was wondering whether you were still actively using it for other things
<aszlig> arianvp: well, i'm using it for other things, but i could simply copy it over to the corresponding projects
<aszlig> arianvp: would be interesting though, whether someone else is also using it, because i'm not only using it for ACME tests
<aszlig> but more generally to get a fully working DNS setup in VM tests
<arianvp> im just not sure if parsing those from extraHosts is the right approach. what was the rationale for that instead of adding a nixos option for configuring the records?
<aszlig> arianvp: the rationale for that was to have a "more or less reasonable" default
<infinisil> arianvp: slightly relevant might be https://github.com/NixOS/nixpkgs/pull/81945
<{^_^}> #81945 (by Infinisil, 3 days ago, open): Introduce `networking.hostFiles` option
<aszlig> of course, for more detailed DNS configuration i wrote an abstraction a few years ago
phreedom has quit [Remote host closed the connection]
<arianvp> cool
phreedom has joined #nixos-dev
Guest30 has joined #nixos-dev
Guest30 has quit [Remote host closed the connection]
justanotheruser has quit [Ping timeout: 265 seconds]
<Profpatsch> infinisil: before we add too many options to generator functions, we should think about either making them into their own primitives or their own types.
<Profpatsch> Because the semantics quickly go down the drain.
<Profpatsch> It should always be possible to have a good intuition what a generator does for which corner cases, which goes away if there are more than one or two flags
<infinisil> Hm maybe, though then we could have an exponential number of different generators
<infinisil> 2^(number of on-off flags)
<infinisil> I think for these duplicate keys the interpretation is pretty straight forward, but global properties will be a bit more tricky
<infinisil> Looking at https://en.wikipedia.org/wiki/INI_file#Varying_features it seems global properties and duplicate keys are probably the only features we'd need
<Profpatsch> infinisil: that’s why I said that boolean flags usually turn on my alarms and it took me ~20 minutes to review that PR
<Profpatsch> infinisil: If you have global options, you don’t need another flag, you just concatenate a key-value file with an ini file
justanotheruser has joined #nixos-dev
<Profpatsch> I suspect this is going to be fairly complicated because we started assuming a 1:1 mapping of the config types to generators?
<Profpatsch> That’s a mistake imho
<Profpatsch> Same problem that you have in Haskell with pretty-printing typeclasses.
<Profpatsch> If you really want the 1:1 mapping, there needs to be another layer
<Profpatsch> toINI is already the wrong interface if you want a global section. Because you can’t go from (attrs (attrs string)) to a global section without adding a hack that treats a certain heading as as special.
<Profpatsch> what you want there is data like (record { global = attrs string; sections = (attrs (attrs string)); } ) instead
<Profpatsch> So one layer of wrapping
<Profpatsch> btw https://github.com/Profpatsch/nixperiments/tree/master/simple-types can represent that type as I wrote it, without having to resort to the ugly submodule hack
sogatori has joined #nixos-dev
<infinisil> Yeah thought of that too
<infinisil> Though the interface for the {global,sections} thing is a bit non-intuitive if all you need is non-global sections
<infinisil> Also makes transitioning from a global-section-less type to one with a global section hard
<infinisil> Which wouldn't be a problem if there was a special _global section
<infinisil> Profpatsch: ^
justanotheruser has quit [Read error: Connection reset by peer]
<{^_^}> firing: RootPartitionLowDiskSpace: https://status.nixos.org/prometheus/alerts
<infinisil> Profpatsch: I made the changes you suggested for #82208, good to merge now? :D
<{^_^}> https://github.com/NixOS/nixpkgs/pull/82208 (by Infinisil, 13 hours ago, open): lib/generators: Add toINI option for duplicate keys
<Profpatsch> infinisil: sure, already Accepted
<Profpatsch> infinisil: Hm, yeah, true, but then you can have a union of either ini or ini-with-global-section
<Profpatsch> which probably doesn’t work with structured types in the nixpkgs types.nix, because the checks are shallow :(
<infinisil> Profpatsch: `attrsOf (attrsOf ...)` should work, no?
<infinisil> Because _global will just be a section name that gets treated specially
<aanderse> infinisil: thanks for implementing! Profpatsch: thanks for feedback and review!
<infinisil> :D
<Profpatsch> infinisil: yeah, special section name is the hack.
<Profpatsch> But I …guess… we could add it. It’s a tradeoff.
<Profpatsch> Like I said. Kitchen sink :)
justanotheruser has joined #nixos-dev
<aanderse> Profpatsch keeps making me hungry when he says that... because there is a local place that has a great pizza called "the kitchen sink"
<Profpatsch> aanderse: great to see this used in the wild
<Profpatsch> we are slowly moving in the direction of dropping string concatenation in favor of more structure :+1:
claudiii has joined #nixos-dev
orivej has joined #nixos-dev
<garbas> hey! nixos.org will be - in next minutes/hours - moved to netlify. we had to put few redirect in place to make this transition happen. if you see content not being available or worse some tooling not working please ping me or niksnut
cole-h has joined #nixos-dev
drakonis has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 255 seconds]
orivej has joined #nixos-dev
ixxie has joined #nixos-dev
myskran has joined #nixos-dev
abathur has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 258 seconds]
myskran has quit [Quit: myskran]
Guest30 has joined #nixos-dev
Synthetica has joined #nixos-dev
<Synthetica> Is someone working on sagemath 9.0? Seems to be a pretty big update, since it switches from py2 to py3
<gchristensen> nice
Guest30 has quit [Remote host closed the connection]
<Profpatsch> Synthetica: maybe we can use adisbladis poetry2nix for that?
<Synthetica> Profpatsch: I don't know, maybe? Do they even use poetry as a build system? I can't find an indication for that in the source tree
<Profpatsch> idk, I try to keep my distance from python packaging ;)
<adisbladis> You're probably gonna have an uphill battle in regards to overrides packaging sagemath using poetry2nix
<adisbladis> OTOH you're gonna have to do that work anyway
<adisbladis> Synthetica: Upstream don't have to use poetry for poetry2nix to make sense
<adisbladis> When I packaged pretix/pretalx for nixcon I used an early version of it to manage the environment (upstream uses plain setuptools)
Guest30 has joined #nixos-dev
<Guest30> Hello. Is there anyone who would like to take a look into PR https://github.com/NixOS/nixpkgs/pull/80931? I have requested for quite a long time and I think it's mature enough to merge.
<{^_^}> #80931 (by LEXUGE, 2 weeks ago, open): smartdns: init at 30
Guest30 has quit [Ping timeout: 265 seconds]
Jackneill has quit [Remote host closed the connection]
avn has joined #nixos-dev
abathur has joined #nixos-dev
<samueldr> is there a reason --store local?root=... is not documented in the nix manual?
<samueldr> (other than no one got around to it)
<samueldr> wondering if it should not be relied upon
<srk> not a lot of docs for chroot stores indeed
<srk> even for nix run --store
<LnL> there's a bunch of useful stuff in the commit messages, putting those together in a store uri section would be nice
abathur has quit [Quit: abathur]
<samueldr> though, with the silence I assume no reason not to rely on it
<srk> no reason not to - it's just namespace/chroot + bind mount anyway
<samueldr> it could have been like the `nix` command, new "unstable" (open to changes) feature
<LnL> also FYI, I think local?root=/foo is the same as /foo now
<srk> I wonder if content addressed store makes this irrelevant
ris has joined #nixos-dev
<{^_^}> firing: RootPartitionLowDiskSpace: https://status.nixos.org/prometheus/alerts
abathur has joined #nixos-dev
justanotheruser has quit [Ping timeout: 272 seconds]
lovesegfault has quit [Quit: WeeChat 2.7.1]
psyanticy has quit [Quit: Connection closed for inactivity]
sogatori has quit [Remote host closed the connection]
ixxie has quit [Ping timeout: 256 seconds]
lovesegfault has joined #nixos-dev
ixxie has joined #nixos-dev
bhipple has joined #nixos-dev
ixxie has quit [Ping timeout: 260 seconds]
drakonis has quit [Quit: WeeChat 2.7.1]
drakonis has joined #nixos-dev
orivej has joined #nixos-dev
bhipple has quit [Ping timeout: 268 seconds]
bhipple has joined #nixos-dev
Jackneill has joined #nixos-dev
<infinisil> Thinking about access permissions for /run/keys (or similar)
<infinisil> Ideally user paul should only be able to list the keys he has access to
<infinisil> Such that he can't learn information about other keys (their name and size)
<infinisil> And that kind of requires having a hierarchy like /run/keys/{paul,alice,...}
<infinisil> Where each of those directories contains that users keys
<samueldr> do they need to be able to *list* them?
<samueldr> (maybe they do!)
<infinisil> samueldr: Unfortunately you can't read a file if you can't list all parent directories
<samueldr> you can traverse a directory without being able to list its contents
<samueldr> -r+x
<infinisil> From my testing that doesn't seem to work
<infinisil> Oh
<infinisil> wait no I used -x+r
<infinisil> Oh yeah that works :o
<samueldr> but don't think that I dismiss outright that listing can be a requirement
<samueldr> it just makes it easier to implement that way
<infinisil> samueldr: Although actually that's still kind of an information leak
<infinisil> As people can try random file names to see if they exist
<infinisil> For a path that doesn't exist you get "No such file or directory", whereas if it does exist but you can't access it you get "Permission denied"
<samueldr> right
<samueldr> UUIDs for secrets names? :)
<infinisil> Hmm...
<samueldr> though yeah, in that case you're right, it's leaky
<infinisil> I did think about using a separate nix store for secrets
<infinisil> Maybe just -r'ing /nix/store could work
<infinisil> And /nix/var/nix/profiles/per-user could store the secret profile for each user!
<infinisil> And you get atomic switches for free
<infinisil> GC for free, rollbacks for free
<infinisil> transfer with nix-copy-closure for free
drakonis has quit [Quit: WeeChat 2.7.1]
drakonis has joined #nixos-dev
<infinisil> I kind of doubt -r on /nix/store works though
<infinisil> Lemme try..
<infinisil> Yeah I think that works!
Jackneill has quit [Remote host closed the connection]
<infinisil> It doesn't quite *feel* right to use a separate Nix store for secrets, but I currently don't see any problem with it
bhipple has quit [Read error: Connection reset by peer]
<infinisil> Idea for solving nix#8: Just use different Nix stores!
<{^_^}> https://github.com/NixOS/nix/issues/8 (by edolstra, 7 years ago, open): Support private files in the Nix store
<infinisil> And for this to be useful, stores should be able to easily link between each other
<infinisil> Well it's not easy actually
<infinisil> But I think it would be a decent solution
<drakonis> that sounds like fun.
<lovesegfault> SEVEN YEARS
<lovesegfault> :O
<drakonis> one month until EIGHT YEARS :O
claudiii has quit [Quit: Connection closed for inactivity]
cocreature has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
cocreature has joined #nixos-dev
<{^_^}> firing: RootPartitionLowDiskSpace: https://status.nixos.org/prometheus/alerts
lovesegfault has quit [Quit: WeeChat 2.7.1]
<infinisil> Using a separate nix store seems to be rather tricky
<infinisil> The chroot makes symlinks not point to the right store
<infinisil> Meaning you probably always need to chroot to use any paths in it
bhipple has joined #nixos-dev
<LnL> for trivial builds you don't need a chroot tho
drakonis has quit [Ping timeout: 268 seconds]
<LnL> I think using a separate storeDir for secrets would be a good option
<infinisil> LnL: The specific problem I have is that I try to use `nix-env` to install a set of secrets for a user, but then $root/nix/var/nix/profiles/per-user/root/secrets-1-link points to /nix/store/...
<infinisil> Not $root/nix/store/...
<infinisil> (after forcing nix-env to work at all by specifying the profile path manually with -p)
<LnL> I mean local?root= vs local?store=
<infinisil> Ohh
<infinisil> Didn't know about local?store=
<LnL> that works fine as long as you don't want to build nixpkgs stuff
<infinisil> LnL: Nice, that works!
<LnL> NIX_STORE_DIR, NIX_STATE_DIR and NIX_LOG_DIR where there before store uris where introduced
<LnL> setting those is equivalent to --store local?store=$NIX_STORE_DIR&state=$NIX_STATE_DIR&log=$NIX_LOG_DIR
<infinisil> Ah and default values are /nix/store, /nix/var/nix and /nix/var/log respectively
<LnL> yep exactly
<gchristensen> secrets shouldn't appear in a .nix file anyway :/
<infinisil> gchristensen: They'd just be imported by one
<LnL> the diverted/chroot store was introduced to keep /nix/store and avoid rebuilds, but that should be completely irrelevant for secrets
<infinisil> So I'm thinking about this for https://github.com/Infinisil/nixoses
<infinisil> One problem I now see with using a /nix/store is that creating secrets from non-files would be more complicated
<infinisil> E.g. using vault to get the secrets
<infinisil> Or install them
<LnL> and completely keeping secrets out of /nix/store seems a great option to avoid accidentally exposing stuff
bhipple has quit [Ping timeout: 256 seconds]
<infinisil> Oh yeah, permissions are problematic too
<infinisil> Would have to make sure to chmod/chown all the time after a store import
<infinisil> Eh yeah, probably a bad idea, Nix isn't designed for this
<gchristensen> +1
<abathur> I've pondered playing with an alt store to see how well Nix can work for "building" content, but I think it's probably moot until recursive nix shakes out a bit more
<infinisil> abathur: "building" content?
<abathur> well, an example, which is just a subset of my interest, would be like, a job that will render a set of video master files into a set of multi-resolution outputs, with dependencies on the profiles used to render them, the masters, and the toolchain (i.e., ffmpeg)
<infinisil> Why an alt store for that and not the normal one?
<LnL> yeah, but templating stuff with both nix and hcl is kind of awkward
justanotheruser has joined #nixos-dev
bhipple has joined #nixos-dev
<abathur> the normal store would work, of course, but it's just conceptually and pragmatically separate from my installed software; if it worked it seems like it'd be nice to GC thems separately, etc.
<samueldr> don't tell that to clever who used nix to OCR pdf files for further processing all as distinct nix builds :)
<infinisil> I see
<LnL> it's pretty easy to build stuff outside of /nix/store with what I mentioned, you just can't use nixpkgs
<infinisil> I still didn't quite get that, why is this the case?
<abathur> infinisil: re?
<infinisil> LnL