<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.
<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
<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>
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
<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
<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
<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
<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.