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
justanotheruser has joined #nixos-dev
gchristensen has joined #nixos-dev
erictapen has joined #nixos-dev
<{^_^}> resolved: RootPartitionLowDiskSpace: https://status.nixos.org/prometheus/alerts
<tom43422> Dandellion: If Traefik 1 is not going to receive security updates for the period that 20.03 is expected to receive security updates, that'd be an argument in favour of 20.03 including Traefik V2.
<tom43422> Dandellion: That said, v1.7.24 was released 19 days ago, suggesting it's currently receiving updates which is nice!
drakonis has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 260 seconds]
erictapen has quit [Quit: leaving]
bhipple has quit [Ping timeout: 264 seconds]
drakonis has joined #nixos-dev
bhipple has joined #nixos-dev
drakonis_ has quit [Ping timeout: 256 seconds]
bhipple has quit [Ping timeout: 264 seconds]
bhipple has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 260 seconds]
<Dandellion> tom43422: yep, they apparently changed their minds and are now supporting traefik 1 until 2021. Ill edit the comment with this extra information!
<tom43422> Dandellion: (I'm biased and disappointed. :) I run stable, want to move to a memory-safe HTTPS/TLS proxy like Traefik, but would like a recent version to save me incurring the v1 -> v2 migration cost. I'll just cherry-pick it into my nixpkgs fork.)
<Dandellion> yeah, im going to have to do this too, which is pretty annoying :/
<Dandellion> maybe we could make a traefik2 module and package and have that backported if that's more acceptible
<gchristensen> it is quite late for this sort of thing
<drakonis1> 20.03 should be out extremely soon
m1cr0man has quit [Ping timeout: 240 seconds]
<drakonis1> so we're well beyond the point of including things into it
<tom43422> SGTM.
<globin> you could provide an overlay for 20.03 for traefik2 becoming obsolete with 20.09/master :)
<Dandellion> I didnt think overlays could change modules
<tom43422> If I wanted to add a NixOS module (to master!) to provide backups for particular directories to be used by other NixOS modules (e.g. an image store would define its upload dir as being to-be-backed-up), am I best doing that in an RFC or just a pull-request? The implementation would be flexible (could be btrfs snapshots, rsync, restic, etc.)
<globin> Dandellion: you can always use disabledModules to disable the 20.03 module and add provide a replacement in the overlay repository
<gchristensen> tom43422: sounds like something worth prototyping a while outside of nixos before upstreaming
<tom43422> gchristensen: Will do.
bhipple has quit [Ping timeout: 264 seconds]
bhipple has joined #nixos-dev
<colemickens> Which scenario do y'all is the most important: launch an Azure instance from a webpage with a custom Nix config (looks cool, limited real-world value), copy an existing VHD into your subscription and boot it (boring, important, surprisingly annoying in Azure), make it really polished to upload reliably with the in-tree scripts (good deal of the way there, a few more knobs and some docs would serve many folks, but I don't
<colemickens> know if would-be NixOS users already have image-management flows in Azure)
<colemickens> I guess another option is, and I don't think I'm interested in it, fixup/rewriting the Azure NixOps backend.
<gchristensen> is there a way we(foundation) could manage and upload the images for users
<gchristensen> instead of users having to do it themselves
<colemickens> to what scope though? build/upload/own custom images? own "gold" images they can replicate from?
<samueldr> I think it's been a while that there is a desire to "support" azure, but no one knows where to start from
<colemickens> or do the sit-down with Azure to get official platform images ala Ubuntu?
<gchristensen> official platform images would be coolest:)
* gchristensen 's heading to bed, though
<samueldr> I think all your questions can be answered by "yes" :)
<colemickens> we did merge in some stuff in-tree. it should be relatively easy to "az login" and get a VM with a custom image booted in a matter of minutes.
<gchristensen> samueldr++
<{^_^}> samueldr's karma got increased to 206
<colemickens> there's even an asciinema demo.
<samueldr> no, colemickens++
<{^_^}> colemickens's karma got increased to 20
<gchristensen> colemickens++
<{^_^}> colemickens's karma got increased to 21
<colemickens> okay. I'll see if that still requires human contact.
mmlb has quit [Remote host closed the connection]
mmlb has joined #nixos-dev
mmlb has quit [Client Quit]
mmlb has joined #nixos-dev
mmlb has quit [Quit: The Lounge - https://thelounge.github.io]
mmlb has joined #nixos-dev
teto has quit [Ping timeout: 265 seconds]
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #nixos-dev
danderso1 has joined #nixos-dev
clever_ has joined #nixos-dev
danderson has quit [*.net *.split]
clever has quit [*.net *.split]
makefu has quit [*.net *.split]
makefu has joined #nixos-dev
evanjs has quit [Quit: ZNC 1.7.5 - https://znc.in]
evanjs has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.8]
bhipple has quit [Remote host closed the connection]
orivej has joined #nixos-dev
phreedom has quit [Ping timeout: 240 seconds]
phreedom has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
Cale has quit [Ping timeout: 260 seconds]
Cale has joined #nixos-dev
drakonis has joined #nixos-dev
danderso1 is now known as danderson
drakonis_ has quit [Ping timeout: 256 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 246 seconds]
Jackneill has quit [Ping timeout: 260 seconds]
__monty__ has joined #nixos-dev
Ericson2314 has quit [Quit: killed]
jtojnar has quit [Quit: killed]
domenkozar[m] has quit [Quit: killed]
Irenes[m] has quit [Quit: killed]
layus[m] has quit [Quit: killed]
colemickens has quit [Quit: killed]
timokau[m] has quit [Quit: killed]
thefloweringash has quit [Quit: killed]
rycee has quit [Quit: killed]
arcnmx has quit [Quit: killed]
worldofpeace has quit [Quit: killed]
dtz has quit [Quit: killed]
jonge[m] has quit [Quit: killed]
tokudan[m] has quit [Quit: killed]
vaibhavsagar has quit [Quit: killed]
aanderse has quit [Quit: killed]
doronbehar[m] has quit [Quit: killed]
rnhmjoj has quit [Quit: killed]
Nyanloutre[m] has quit [Quit: killed]
mkg20001 has quit [Quit: killed]
alienpirate5 has quit [Quit: killed]
michaelpj has quit [Quit: killed]
Dandellion has quit [Quit: killed]
Ox4A6F has quit [Quit: killed]
bachp has quit [Quit: killed]
abbradar[m] has quit [Quit: killed]
matthewbauer has quit [Quit: killed]
roberth has quit [Quit: killed]
emily has quit [Quit: killed]
masaeedu[m] has quit [Quit: killed]
bennofs[m] has quit [Quit: killed]
yegortimoshenko has quit [Quit: killed]
pkolloch[m] has quit [Quit: killed]
ma27[m] has quit [Quit: killed]
nocent has quit [Quit: killed]
Jackneill has joined #nixos-dev
jtojnar has joined #nixos-dev
Jackneill has quit [Read error: Connection reset by peer]
sogatori has joined #nixos-dev
Jackneill has joined #nixos-dev
colemickens has joined #nixos-dev
matthewbauer has joined #nixos-dev
worldofpeace has joined #nixos-dev
dtz has joined #nixos-dev
pkolloch[m] has joined #nixos-dev
michaelpj has joined #nixos-dev
roberth has joined #nixos-dev
vaibhavsagar has joined #nixos-dev
emily has joined #nixos-dev
Dandellion has joined #nixos-dev
timokau[m] has joined #nixos-dev
doronbehar[m] has joined #nixos-dev
Ericson2314 has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
yegortimoshenko has joined #nixos-dev
rnhmjoj has joined #nixos-dev
aanderse has joined #nixos-dev
Nyanloutre[m] has joined #nixos-dev
bennofs[m] has joined #nixos-dev
arcnmx has joined #nixos-dev
layus[m] has joined #nixos-dev
jonge[m] has joined #nixos-dev
mkg20001 has joined #nixos-dev
alienpirate5 has joined #nixos-dev
ma27[m] has joined #nixos-dev
abbradar[m] has joined #nixos-dev
nocent has joined #nixos-dev
tokudan[m] has joined #nixos-dev
Irenes[m] has joined #nixos-dev
Ox4A6F has joined #nixos-dev
rycee has joined #nixos-dev
bachp has joined #nixos-dev
thefloweringash has joined #nixos-dev
masaeedu[m] has joined #nixos-dev
<andi-> curious, what is hydra.ngi0.nixos.org? Just found that in the org repo
m1cr0man has joined #nixos-dev
m1cr0man has quit [Ping timeout: 265 seconds]
__monty__ has quit [Read error: Connection reset by peer]
__monty__ has joined #nixos-dev
m1cr0man has joined #nixos-dev
sogatori has quit [Remote host closed the connection]
Bunogi has joined #nixos-dev
<talyz> domenkozar[m]: Hi! Was I invited / added to the committers group? :) I can't find any notice of this and I'm not currently in the group..
<domenkozar[m]> strange, sent another invite :)
<talyz> domenkozar[m]: thank you, it worked this time :)
luc65r has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
teto has joined #nixos-dev
teto has quit [Ping timeout: 246 seconds]
teto has joined #nixos-dev
luc65r has quit [Ping timeout: 272 seconds]
luc65r has joined #nixos-dev
ixxie has joined #nixos-dev
luc65r has quit [Ping timeout: 272 seconds]
luc65r has joined #nixos-dev
luc65r has quit [Ping timeout: 272 seconds]
luc65r has joined #nixos-dev
<worldofpeace> Jan Tojnar: do you intend to close this PR https://github.com/NixOS/nixpkgs/pull/85169 ?
<{^_^}> #85169 (by prusnak, 19 hours ago, open): inkscape: 0.92.4 -> 1.0 (rc1_2020-04-09_09960d6f05)
<jtojnar> worldofpeace I think we can leave it
<jtojnar> and change the mine to focus back on lib2geom
clever_ has quit [Changing host]
clever_ has joined #nixos-dev
clever_ is now known as clever
<nh2> worldofpeace samueldr: Sorry, it seems I still don't really understand how Hydra works. I'm looking at https://hydra.nixos.org/job/nixos/release-20.03/tested.
<nh2> What am I missing?
<nh2> The last failing eval was https://hydra.nixos.org/build/116588668 that failed with `elementary-videos`. The next eval is green (https://hydra.nixos.org/build/116589448), but if I click on it under "Changes", the "88661b to 708cb6" says that the only diff is a user manual update.
Shados_ has joined #nixos-dev
sorear has quit [Ping timeout: 240 seconds]
Shados has quit [Read error: Connection reset by peer]
sorear has joined #nixos-dev
<clever> error: unrecognised flag '--help'
<clever> Try './hydra/bin/hydra-eval-jobs --help' for more information.
<clever> lol
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis1 has quit [Ping timeout: 246 seconds]
clever has quit [Ping timeout: 260 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: 246 seconds]
clever has joined #nixos-dev
clever has joined #nixos-dev
clever has quit [Changing host]
<arianvp> errr
<arianvp> the python test driver doesn't have an interactive console to debug tests?
<arianvp> this is a pretty bad regression compared to the old perl one
<arianvp> or hmm
<arianvp> it should, according to the docs
<arianvp> but nixos-run-vms doesnt bring up a python prompt
<arianvp> also python dumps core when you abort nixos-run-vms with C-c
<flokli> arianvp: what about result/bin/nixos-test-driver?
<arianvp> aahh that works
<flokli> and TBH, that's exactly what running-nixos-tests-interactively.xml points you to ;-)
<arianvp> so the docs are just slightly run?
<arianvp> oh no I cant read
<arianvp> lol
<flokli> yes
<flokli> :-P
<arianvp> flokli++
<{^_^}> flokli's karma got increased to 26
<arianvp> beautiful
<arianvp> When I run acme's test_script in the interactive driver pebble.service fails to start
<arianvp> interesting :P
justanotheruser has quit [Ping timeout: 246 seconds]
<arianvp> do test runs persist state across runs when you run them interactively? It's complaining some file on disk already exists
<gchristensen> yeah, in ./ like .ova files or something
<arianvp> aah great thanks
<gchristensen> yep
<gchristensen> and maybe something in /tmp ... not 100% sure
<gchristensen> :x
<arianvp> that's unfortunate though. as some tests create state files that make subsequent runs fail. hmm
<worldofpeace> I think /tmp/vm-state-machine
<arianvp> yep! thanks worldofpeace
justanotheruser has joined #nixos-dev
cole-h has joined #nixos-dev
Shados_ has quit [Quit: Shados_]
Shados has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 256 seconds]
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 272 seconds]
drakonis2 has joined #nixos-dev
drakonis1 has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 256 seconds]
drakonis2 has quit [Read error: Connection reset by peer]
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
<domenkozar[m]> arianvp: I wrote a patch that allows you to ssh in
<domenkozar[m]> but it was reverted as it sometimes made the VM hang
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 272 seconds]
drakonis1 has joined #nixos-dev
drakonis is now known as drakonis_
drakonis1 is now known as drakonis
<michaelpj> Ericson2314: recently found myself wanting `evalPackages` (i.e. packages built for the evaluating system, useful if you need to build something to do IFD for a derivation you will build on a different platform), is this something you've thought about? It would be something like stage -1, right?
<gchristensen> oh my
<clever> error: a 'x86_64-darwin' with features {} is required to build '/nix/store/0yp27c9ic8xz2lbg4z0w4bq7va7c5ip6-nix-tools.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}
<clever> without an evalPackages, you wind up needing a darwin machine to eval a release.nix
<Ericson2314> michaelpj: I've seen that done before by a client, you can ask shlevy . That was for a problem with hydra eval + IFS + remote builders that has sense been fixed
<Ericson2314> in a meeting now so better talk about it later though
<michaelpj> i.e. you can end up with "eval on linux -> build on darwin -> run on aarch64" if you're crazy (which we might be)
<michaelpj> if you're trying to be thorough with your release.nix
<michaelpj> Ericson2314: I'd be interested in your thoughts, it seems like an issue that would bite anyone doing any significant amount of IFD. Which is maybe an argument that you should Not Do That, but I think it makes sense conceptually
<gchristensen> +1 to not doing that ( ._.) :)
<arianvp> I never understood how IFD works. with IFD nix-instantiate and nix-store --realise are not distinct separate steps anymore
<arianvp> ?
<arianvp> does instantiation trigger realisation ?
<gchristensen> the evaluator stops evaluating to build some stuff, to then use in the evaluation
<gchristensen> yeah
<arianvp> sounds dirty :)
<arianvp> (but also useful)
<gchristensen> ,IFD arianvp
<{^_^}> arianvp: import-from-derivation (IFD) is when you evaluate nix from a derivation result, for example `import (pkgs.writeText "n" "1 + 1")` will evaluate to 2. This is sometimes problematic because it requires evaluating some, building some, and then evaluating the build result. It has been described as "such a nice footgun."
<arianvp> "such a nice footgun" :)
<gchristensen> exactly
<clever> arianvp: callCabal2nix is the most public use of it that i can think of
<infinisil> A better fitting name for IFD would be derivation-dependent evaluation
<clever> arianvp: it just runs cabal2nix on a foo.cabal, then loads the resulting default.nix with callPackage
<clever> infinisil: yeah, you can do a lot more then import from it
drakonis has quit [Quit: WeeChat 2.8]
<arianvp> ,FOD
<tilpner> infinisil: Not quite, I think import from builtins.fetchGit should count, but it's not a derivation
<arianvp> ah doesn't work for fixed-output derivation :P
<michaelpj> lots of the uses are some variant of "programmatically turn this non-Nix description of how to build something into a Nix description of how to build it, then build that"
<clever> import, importNative, exec, pathExists, readFile, findFile, and readDir
<infinisil> tilpner: Then it's arguably not IFD exactly because of that
<clever> all of those builtins can take a derivation
<tilpner> infinisil: No, it's not by definition. But perhaps it should be?
<gchristensen> > builtins.hashString "sha256" ",FOD"
<{^_^}> "a3bb7e250c60545038a87ebe835d3a41fb11a98fdbc526c8dc2d52f070907c88"
<gchristensen> ,FOD = a3bb7e250c60545038a87ebe835d3a41fb11a98fdbc526c8dc2d52f070907c88
<{^_^}> fod defined
<michaelpj> yeah, if you include the builtin fetchers then IFD is pretty crucial to a lot of stuff that we do
<clever> ,fod
<michaelpj> `import (builtins.fetchTarball ...)` <- I think strictly this is IFD, right?
<arianvp> exec, what is that? sounds very scary
<{^_^}> a3bb7e250c60545038a87ebe835d3a41fb11a98fdbc526c8dc2d52f070907c88
<clever> ,exec arianvp
<{^_^}> arianvp: builtins.exec i̢s a ͡h͞ìd̢d́e̢n͡ ̕u̢n̢safe̷ i̛m͠pu̴r̡e ̶Nix ̴2̛.0 ̡f̀ea͡t͜ure to ͢e̷x̧ecut͏e ̧ar̴b͟itŕary ̷c͡omm̨and̴s d̵u͟ri͡ng҉ ͡Ni҉x e̢val̶u͜a͞ti͞on̡. Doņ'̕t̕ use̸ it̴!͟ E̴n̵ab͠l̛e ̕wi̶t͏h̛ ̛` `--option allow-unsafe-native-code-during-evaluation true`,͜ M̡o͝re͡ ͜inf͜ò: https://github.com/NixOS/nix/commit/0bb8db25
<arianvp> oh nononono
<infinisil> Oh
<gchristensen> michaelpj: that is not IFD, since builtins.fetchTarball does not create a derivation
<clever> michaelpj: builtins.fetchTarball isnt a derivation, so its not really IFD
<clever> michaelpj: but it is an eval-time fetch, which can still be costly
<infinisil> Yeah tilpner, I guess yeah that should be labeled as IFD after all, even if it isn't a derivation
<tilpner> Is that text zalgo'd, or is that my urxvt being weird?
<clever> tilpner: yes
<arianvp> it is
<gchristensen> tilpner: it is zalgo'd to emphasize the eldritch horror you're getting in to
<infinisil> Hmm
<arianvp> so you're telling me I should use this to deploy to kubernetes during buildt-ime. got it
* gchristensen literally dies
<tilpner> It's glitchy text rendering and zalgo, wonderful
<rnhmjoj> ahahah. i had no idea nix had an unsafePerformIO
<michaelpj> fine, replace it with the nixpkgs `fetchZip` and it's the same. Or some other FOD
<infinisil> What is the characteristic of IFD that makes people want to avoid it?
<mdash> haha alacritty actually renders it, nice
* gchristensen dies harder
<michaelpj> and "it's not a derivation but it still does work at evaluation time"... sounds pretty similar to me :D
<clever> infinisil: having to spend 2 hours building 3 GHC's just to eval a drv file
<arianvp> infinisil: it is a bit confusing to me. I always understood nix-store as only understanding .drv files and being language agnostic
<clever> infinisil: which may happen if you do the wrong eval in `nix repl`
<arianvp> but apparently it's a bit more complicated than that
drakonis has joined #nixos-dev
<clever> arianvp: it all happens before nix-store gets involved
<arianvp> so the evaluator calls nix-store --realise on-demand basically?
<clever> arianvp: at eval time, the evaluation process suspends, asks the daemon to build a thing, then reads from the result and continues the eval
<gchristensen> infinisil: well it is slow, but also it is super valauble to be able to send a .drv and 100% know it is a self-contained build instruction
<gchristensen> (without having done any builds)
<clever> store->buildPaths(drvs);
<infinisil> gchristensen: How is the latter point not a thing for IFD?
<arianvp> but whatever .drv comes out of an eval that uses IFD will not be self-descriptivve anymore right?
<clever> arianvp: the drv is still fully describing the build
<gchristensen> infinisil: you can't produce the .drv without building
<arianvp> say I have nix expr A which imports drv B and produces drv A'
<arianvp> does A' describe the full build?
<clever> arianvp: but values generated by a build, are embeded within the drv
<arianvp> ahh so it will substitute the outPath ?
<infinisil> gchristensen: But once you did build it, it would still be a self-contained build instruction
<arianvp> in the resulting .drv?
<clever> arianvp: for example, stdenv.mkDerivation { name = builtins.readFile (pkgs.runCommand "foo" {} "echo ohgodno > $out"); }
<clever> arianvp: this will run an echo, to create a file, then read that file, and bake the final string into another drv
<gchristensen> infinisil: beinga ble to produce the instruction without building is super valuable
<clever> arianvp: and that other drv, is just a normal drv, as-if you had just done `name = "ohgodno";`
<clever> arianvp: but, you can now involve any langauge you want, in the creation of that string
<arianvp> got it
<clever> that build will still have to respect the normal sandbox rules, and cant do network
<infinisil> gchristensen: I guess one thing is that without IFD you can instantiate derivations without having write access to /nix/store
<clever> infinisil: yeah, if nix-instantiate is in read-only mode, it will compute the hash of every drv, but not actually write them
<clever> but IFD requires building a thing, which requires a write
<infinisil> Should flakes be considered to use IFD?
<gchristensen> flakes don't use IFD
<infinisil> gchristensen: Can flakes be evaluated without building or write access to the store?
<gchristensen> yeah, I think so
<infinisil> Ah, it writes to ~/.cache/nix I guess?
<gchristensen> yeah
* infinisil nods
<infinisil> I guess you still need to download something to be able to evaluate stuff though
<clever> /nix/store/l62drw37qqh3dyzc2zj3rbp2y7jpxa6x-nix-2.4pre0_0000000-dev/include/nix/util.hh:17:20: fatal error: optional: No such file or directory #include <optional>
<clever> finding myself unable to build hydra today...
<niksnut> infinisil: don't think so, flakes are downloaded into the store
<niksnut> so you need write access
<infinisil> Ah
<gchristensen> ack
<infinisil> So it's the same as fetchTarball
<infinisil> in that regard
<infinisil> (and co)
<niksnut> yes
<michaelpj> it's not clear to me that there's a fundamental difference btween "run this expensive build to get your nix expr" and "download this massive file to get your nix expr", for suitably large files and bad connections. But in practice it's much easier to make the former take a long time
<clever> michaelpj: also, with downloads, you typically know the size at the start, and can give a progress
<infinisil> michaelpj: A fundamental difference between them (usually) is that the former is not a fixed-output derivation
<michaelpj> you could download a file full of URLs and hashes, and then download all of those :) which would also defeat the progress monitor (but is perverse)
<michaelpj> infinisil: most of the uses of fancy IFD I've seen have been fixed-output
<clever> michaelpj: reading that file into nix is IFD
<michaelpj> the advantage being something more like "don't check in all this generated nix code"
<gchristensen> you have been gifted a great gift of not the nigtmare IFD I've seen
<gchristensen> like that one guy whose nix-shell took 8 hours to enter
<infinisil> michaelpj: Yeah, though there's also the prominent haskellPackages.callCabal2nix which uses IFD without a fixed-output derivation
<infinisil> (as an example)
<clever> gchristensen: when i was looking into snack (incremental haskell in nix), it took 48 hours just to eval the project
<gchristensen> lol I remember that
<clever> gchristensen: and it did have IFD in it too
<clever> in the 48 hours it took to not even finish, i refactored it to take ~15mins
<michaelpj> `builtins.fetchTarball` can be called without a hash, too
<rnhmjoj> infinisil: would you mind reviewing my pr #79877? i know you like improving error messages and this modules doesn't seem to have a maintainer
<{^_^}> https://github.com/NixOS/nixpkgs/pull/79877 (by Infinisil, 8 weeks ago, open): Improve callPackage error message!
<clever> yeah, its impure, but its at eval time, so the result of that impurity gets locked into the .drv file
<infinisil> Oh, but one big advantage of flakes (I think) is that you can run everything in pure evaluation mode, which doesn't allow IFD, except through the flake input concept, which is necessarily fixed-output
<clever> if it changes, you get a new .drv, so the nix-daemon doesnt notice the impurity
<clever> its jsut a different build
<infinisil> rnhmjoj: Wrong number? :P
<rnhmjoj> infinisil: oops, it's #83171
<{^_^}> https://github.com/NixOS/nixpkgs/pull/83171 (by rnhmjoj, 3 weeks ago, open): nixos/users: validate password hashes
<michaelpj> clever: but the same is true for other IFD that isn't fixed-output
<clever> michaelpj: but once those are built once, the answers is in the store, and shouldnt change again
<clever> michaelpj: there is also `repeat = 1`, which will enforce them giving the same answer
<niksnut> infinisil: pure mode does allow IFD
<niksnut> maybe it shouldn't, but that would be a big change
<infinisil> Oh!
<niksnut> hm, or maybe I'm confused myself :-)
<clever> [clever@system76:~/apps/hydra]$ nix show-config | grep allow
<clever> allow-import-from-derivation = true
<clever> infinisil: you can always turn it off
<niksnut> yeah I think it's still allowed
<michaelpj> I think allowing it if it's fixed-output seems fine
<michaelpj> (to be clear, I endorse the policy that all IFD should be fixed output. Probably.)
<clever> michaelpj: that would play nicely with niv
<{^_^}> nix#2270 (by edolstra, 1 year ago, open): Restrict fixed-output derivations
orivej has quit [Ping timeout: 264 seconds]
<NinjaTrappeur> 0/ Is there a way to generate a self-signed TLS certificate for a nixos test other than https://github.com/NixOS/nixpkgs/blob/6d445f8398d2d585d20d9acacf00fd9d15081b3b/nixos/tests/common/letsencrypt/mkcerts.nix#L1 ?
<gchristensen> what sort of options are you thinking?
<NinjaTrappeur> :/ I found several ocurrences like this one https://github.com/NixOS/nixpkgs/blob/6d445f8398d2d585d20d9acacf00fd9d15081b3b/nixos/modules/services/networking/xrdp.nix#L125 . Would it worth to refactor all these self-signed certificate hackes to a nixos module?
<NinjaTrappeur> /hackes/hacks
orivej has joined #nixos-dev
<gchristensen> yikes!
<gchristensen> how many ... exactly ...? I don't think we should do this at all! :o
<gchristensen> :x
<NinjaTrappeur> less than 10 to be fair
<b42> NinjaTrappeur: another ugly hack is to use security.acme but set security.acme.server to e.g. localhost so it genereates self-signed cert but doesn't contact LE servers :X
<NinjaTrappeur> I want to run a service that need TLS to work in a nixos test. How would you do that?
<NinjaTrappeur> b42: ah! I'm lazy, that's a really appealing idea :D
<b42> :)
<gchristensen> we shouldn't do it because it almost guarantees we're doing the wrong thing for users who actually know things / care about TLS
<NinjaTrappeur> gchristensen: we're doing that in matrix-synapse, etcd, ircd, xrdp and nntp-proxy
<NinjaTrappeur> +1
<NinjaTrappeur> That said, it make sense in nixos tests
<niksnut> it's also useful for bootstrapping letsencrypt
<gchristensen> yeah so for bootstrapping letsencrypt it is the right thing to do :)
<NinjaTrappeur> Maybe we could factor that out via a nix function living in nixos/tests.
<NinjaTrappeur> niksnut +1
<aanderse> agreed, saves a deploy
<infinisil> Moving to here from #nixos-chat
<gchristensen> srk, infinisil: I was thinking it'd be nice to automatically mark packages broken in a timely manner. for example, if they don't build for an entire month, automatically trigger a PR to nixpkgs tagging the maintainer and marking it as broken. letting this run continuously
<gchristensen> that way it isn't a massive push during a release to "fix as many as possible" then "mark all the rest"
<infinisil> Sounds like a good idea
<srk> indeed
<srk> my current idea is a tool (let's call it nixpkgs-mark-broken) that can adjust meta as needed for $package
<infinisil> The idea of using an auto-generated pkgs/top-level/broken.nix is also nice in that it allows things to be unmarked automatically if wanted
<srk> querying all packages is not trivial tho
<gchristensen> I can help with all of this, of course, one of the things I've mentioned in the past is having an event feed out of hydra -- so you could "subscribe" (say, rabbitmq or whatever) and get notified when builds finish
<srk> (I'm doing event feed for nixpkgs commits btw)
<srk> to solve the issue at hand I was thinking -> query all packages -> look which packages aren't unfree && don't have nar(info) in cache, mark those as broken
<niksnut> gchristensen: that should be pretty easy now with a postgres -> ... bridge
<gchristensen> niksnut: yeah, true!
<infinisil> srk: Ah, so it checks the narinfo for all commits for like 1 month, and if none of the commits have it cached, mark as broken?
<srk> infinisil: (by issue I mean the one for 20.03)
<infinisil> (which one?)
<srk> infinisil: that one is easy in that respect - checkout 20.03 and look at cache
<gchristensen> niksnut: it would be best if it could keep a connection open to the rabbitmq server, which should be easy, too, now. though if there were a protocol other than rabbitmq that people liked and didn't require us to run a server, that'd be nicer :P
<infinisil> srk: Ah I see
<infinisil> Yeah for a release just checking one commit should work
<infinisil> gchristensen: HTTP?
<infinisil> Well still needs a server, but probably much less complicated than rabbitmq
<srk> WS & SSE :)
<srk> if we have rabbitmq we can add $x as well
<srk> on top of that
<infinisil> WS & SSE?
<srk> websockets & server-sent events
<infinisil> Ah, yes
<srk> what's the good way to query all packages btw? I'm trying without evaluation by following callPackage. while fast it won't get all of em
<infinisil> srk: You'll only want the packages hydra attempts to build
<infinisil> Which I think should be available relatively easily
<gchristensen> infinisil: can you give this a quick read? https://gsc.io/snaps/b5b857f5-8ff9-42a8-a738-a34f30c4b57a.png wip docs on reviewing maintainer additions (validating github IDs to come)
<infinisil> srk: recurseIntoAttrs instructs hydra to recurse into things like pythonPackages for example
<srk> infinisil: right, makes sense
<srk> just need to follow release.nix I guess
<infinisil> gchristensen: I'm no GPG expert, but that seems pretty solid
<gchristensen> cool
<infinisil> gchristensen: Have you thought about automating this process though?
<gchristensen> infinisil: I have
<gchristensen> gonna write the docs first :P
* srk back tomorrow
<gchristensen> see ya, srk!
<srk> o/
<infinisil> Docs for manual process first so we know how an automated process should look?
<gchristensen> yeah, and in case ofborg is down and people want to merge anyway
<gchristensen> I
<gchristensen> don't like it when people do that, but that is motivation to do better :P
<infinisil> Hm, how about a maintainer script?
<infinisil> maintainers/scripts/verify-maintainer-key
<infinisil> Then people can just run that instead of having to do stuff manually, and it can be called by ofborg
<gchristensen> ofborg doesn't call programs like that, it is very careful about not accidentally exposing itself to a malicious PR --
<gchristensen> and GPG is tricky because it requires netowrk access
<gchristensen> but yeah, putting the validation logic in a script would be good too -- then it'd be a bug if ofborg fell out of sync
<infinisil> Hmm, how about running the maintainer script from the base branch?
<infinisil> Trust chain kind of thought
<gchristensen> yeah
<infinisil> Oh, even cooler: Use the base branch, but only run the maintainer script if the last commit that modified it was signed by you
<infinisil> (or other core members)+
<gchristensen> that sounds nicely flexible
justanotheruser has quit [Ping timeout: 250 seconds]
justanotheruser has joined #nixos-dev
<gchristensen> infinisil: how about this one : https://gsc.io/snaps/d743608b-06e6-4a06-8869-54cdc9daf464.png
<infinisil> Looking sound
* gchristensen writes some for maintainer teams
abathur has joined #nixos-dev
<gchristensen> I quite like that there is a team-list.nix and maintainer-list.nix neither of which have a significant amount of "list" :P
<infinisil> Hehe
<infinisil> team-list does quite a bit though!
<pie_[bnc]> the solution to qt version problems is to just...use cmakeWithQ4Gui instead of cmakeWithGui
<etu> gchristensen: But listing of gpg keys ;)
<gchristensen> hehe
danielrf[m] has joined #nixos-dev
<infinisil> Very nice
<qyliss> Why are we even storing the long key ID and the fingerprint?
<qyliss> The long key ID is just half of the fingerprint
<{^_^}> #85247 (by grahamc, 1 minute ago, open): Maintainer team
<qyliss> err, 40% of the fingerprint
<qyliss> gchristensen: am I right in reading that a company wants to create a closed team in Nixpkgs?
<gchristensen> oh cool, this even works: gpg --recv-keys "F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0"
<gchristensen> qyliss: right, a company wants to make a team to represent their company -- and add it as a maintainer to a few packages
<qyliss> interesting
<qyliss> makes sense, I suppose
<gchristensen> cool :)
<gchristensen> niksnut: https://github.com/NixOS/nix/pull/3494 looks nice, and I think is ready to go
<{^_^}> nix#3494 (by cleverca22, 1 hour ago, open): log all ifd
<qyliss> clever++
<{^_^}> clever's karma got increased to 392
<drakonis> neat, you can't say which packages they want to maintain?
<gchristensen> clever++
<{^_^}> clever's karma got increased to 393
<gchristensen> drakonis: I'm going to leave it up to them :P for one, it isn't my place. for two, I don't know
<drakonis> aight
jared-w has quit [Ping timeout: 260 seconds]
jared-w has joined #nixos-dev
<Valodim> is there a bot that checks commits from maintainers on github against their specified pgp fingerprint? I'm guessing there isn't?
ixxie has quit [Quit: Lost terminal]
<gchristensen> not yet
<arianvp> NinjaTrappeur: so what you used to be able to do is use the letsencryptr helper module standalone to use it as a CA for your tests
<arianvp> and acme.nix was just one of the tests (the only one ) using it
<arianvp> However, this kind of got muddled when acme module was switched to lego. the helper module isn't completesly standalone anymore
<arianvp> it's on my list of many things to fix that again
<arianvp> so then you can have a proper CA that can give you certs using ACME in your tests
<arianvp> you could see how acme.nix does it, but you'll duplicate some code that should be abstracted away probably
lovesegfault has quit [Quit: WeeChat 2.8]
<NinjaTrappeur> arianvp: in the end I wrote a small lib in charge of generating a self signed certificate. I then append it to the security.pki.certificates on the client using that service.
<NinjaTrappeur> It's part of the xmpp nixos test I'm updating. I'll ping you when I'll PR that.
<NinjaTrappeur> The idea is to leverage this utility for the other nixos tests.
freepotion has joined #nixos-dev
lovesegfault has joined #nixos-dev
<freepotion> Hey all! May someone look at my PR, please (and merge it if possible): https://github.com/NixOS/nixpkgs/pull/82903 Thanks! O:3
<{^_^}> #82903 (by freepotion, 3 weeks ago, open): ivan: add full iconset
freepotion has quit [Remote host closed the connection]
luc65r has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 256 seconds]
<gchristensen> Valodim: thanks for bringing that up
__monty__ has quit [Quit: leaving]
evanjs- has joined #nixos-dev
evanjs has quit [Ping timeout: 265 seconds]
justanotheruser has quit [Ping timeout: 258 seconds]
justanotheruser has joined #nixos-dev
janneke has quit [Remote host closed the connection]
janneke has joined #nixos-dev