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
andi- has joined #nixos-dev
bhipple has joined #nixos-dev
justanotheruser has joined #nixos-dev
<gchristensen> samueldr: any interest in making a whole-cloth style.css? :P
abathur has joined #nixos-dev
<{^_^}> nix#3392 (by thkoch2001, 7 hours ago, open): License of style.css is GPL?
<samueldr> I could do that
<gchristensen> I'm not sure how different it needs to be...
<gchristensen> but I think ideally having teh style.css be lgpl like the rest of the repo would be idea
<gchristensen> l
<{^_^}> firing: HomepageUpdateStuck: https://status.nixos.org/prometheus/alerts
drakonis has joined #nixos-dev
<samueldr> gchristensen: we could directly integrate the CSS work previously done for the refreshed manual, maybe (probably) cutting the sidebar stuff
<gchristensen> let me get back to you on that tomorrow?
<samueldr> sure
<abathur> [[ "$1" == "$HOME/src" || "$1" == "~/src" ]]; echo $?
<abathur> sigh
<abathur> man
<gchristensen> eh?
<abathur> side by side windows, didn't realize which my cursor was in
<gchristensen> ah hehe
<gchristensen> you might want to `realpath` $1 :)
<genesis> ^^
<abathur> eh, trying to rewrite a test for oilshell that breaks on macos/nixos because it is asserting hard-paths
<abathur> like
<genesis> if you like abathur and review, i can propose you a PR :D
<genesis> s/abathur shell
<abathur> echo ~{/src,root}
<genesis> (with a realpath $1 inside)
<abathur> so I'm really just trying to figure out some way *other* than shell expansion to validate the platform-independent path that expanding the tilde is going to yield for the test
<abathur> or some better arrangement of the words I just wrote
drakonis has quit [Ping timeout: 256 seconds]
drakonis has joined #nixos-dev
bhipple has quit [Ping timeout: 240 seconds]
bhipple has joined #nixos-dev
<genesis> echo $HOME/src | jq -R '. | @sh'
bhipple has quit [Read error: Connection reset by peer]
bhipple has joined #nixos-dev
drakonis has quit [Ping timeout: 256 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.7.1]
ixxie has quit [Ping timeout: 240 seconds]
ixxie has joined #nixos-dev
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-dev
das_j has quit [Quit: killed]
Scriptkiddi has quit [Quit: killed]
ajs124 has quit [Quit: killed]
das_j has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
ajs124 has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
Taneb has quit [Quit: I seem to have stopped.]
Taneb has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.7.1]
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Read error: Connection reset by peer]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 255 seconds]
justanotheruser has joined #nixos-dev
abathur has quit [Ping timeout: 255 seconds]
orivej has quit [Ping timeout: 256 seconds]
bhipple has quit [Ping timeout: 265 seconds]
<{^_^}> firing: HomepageUpdateStuck: https://status.nixos.org/prometheus/alerts
cole-h has quit [Ping timeout: 255 seconds]
q3k has quit [Ping timeout: 272 seconds]
bennofs has quit [Ping timeout: 272 seconds]
ixxie has quit [Ping timeout: 255 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
orivej has joined #nixos-dev
danderson has quit [Quit: leaving]
danderson has joined #nixos-dev
ris has quit [Ping timeout: 258 seconds]
Jackneill has joined #nixos-dev
q3k has joined #nixos-dev
__monty__ has joined #nixos-dev
justanotheruser has quit [Ping timeout: 265 seconds]
<domenkozar[m]> hmm updating to 20.03 fails my nixos tests
<domenkozar[m]> seems like python is trying to format my perl :D
<domenkozar[m]> is there something I have to opt in?
<{^_^}> firing: HomepageUpdateStuck: https://status.nixos.org/prometheus/alerts
psyanticy has joined #nixos-dev
<domenkozar[m]> ah nixosTest already uses python
tilpner_ is now known as tilpner
bhipple has joined #nixos-dev
bhipple has quit [Remote host closed the connection]
<{^_^}> https://github.com/NixOS/rfcs/pull/64 (by Infinisil, 9 weeks ago, open): [RFC 0064] New Documentation Format for nixpkgs and NixOS
<niksnut> I don't see how it's relevant
<gchristensen> aminechikhaoui, niksnut:adisbladis and I have some fairly minor (and yet, sort of major!) change to NixOps in a PR, and we'd like to talk about it some -- make sure we're on the same page -- synergising -- and other business metaphors before we go too far. can you both take a look? https://github.com/NixOS/nixops/pull/1245
<niksnut> the documentation format has very little to do with the quality of the documentation
<{^_^}> nixops#1245 (by grahamc, 2 days ago, open): Deploy Targets: Policy/Behavior-free Deployment Hooks (auto-rollbacks, drain events, etc.)
<niksnut> gchristensen: looks good to me, though maybe it would be better to have those hooks in NixOS rather than NixOps
<adisbladis> niksnut: The intent is to let it stew a bit and mature in Nixops and then move it into NixOS
<adisbladis> Since both me and gchristensen thinks this may be RFC material
<niksnut> ok
<adisbladis> Sounds reasonable?
<gchristensen> I agree with infinisil's comment about the deploy-prepare, also
<infinisil> niksnut: Not directly no, but that post says that the docs we have are in bad shape
<infinisil> And me and many others are discouraged from writing docs due to docbook
<gchristensen> niksnut: to that effect, we have this PR changing switch-to-configuration: https://github.com/NixOS/nixpkgs/pull/82139#pullrequestreview-371134271
<niksnut> infinisil: sure, and others (e.g. me) would be discouraged if we use markdown
<infinisil> Which is why I'm pushing for a poll in that RFC, so we can know which format would be preferred by most :)
<infinisil> Markdown probably won't be a candidate though, since the requirements are hardly met for it
<domenkozar[m]> ...> /nix/store/52ks4xs341kpzxlqf17jn8bqipx5cb62-grub-2.04/sbin/grub-install: error: cannot find a GRUB drive for /dev/xvda. Check your device.map.
<domenkozar[m]> seems like ec2 deploys are broken with 20.03?
<domenkozar[m]> seems like a sin from 19.09 :)
<domenkozar[m]> ah probably needs nixops release
<domenkozar[m]> that adds t3 with nvme
<gchristensen> that will be exciting
<domenkozar[m]> boot.loader.grub.device = lib.mkForce "/dev/nvme0n1";
<domenkozar[m]> workarounds it
<{^_^}> #62824 (by jluttine, 39 weeks ago, open): Upgrading EC2 from 18.09 to 19.03 fails
<domenkozar[m]> niksnut: infinisil really the problem is that changing docs structure is currently too much work
<domenkozar[m]> I wanted to do it a few times, but with docbook it's a huge time sink
<domenkozar[m]> implementing the four quadrants in docbook.... good luck
<domenkozar[m]> and it's not the format, but the tooling
<domenkozar[m]> as I keep repeating myseelf ^^
<domenkozar[m]> (without much effect)
<domenkozar[m]> nginx: [emerg] cannot load certificate "/var/lib/nginx/fullchain.pem": BIO_new_file() failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/var/lib/nginx/fullchain.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)
<domenkozar[m]> seems like nginx got sandboxed?
<adisbladis> domenkozar[m]: File permissions maybe? Looking at the nixos module it doesn't look like any sandboxing is done
<domenkozar[m]> it's owned by nginx user :/
<domenkozar[m]> ah mess up with keys group
<adisbladis> I wonder if setting ReadOnlyPaths=/path/to/cert.pem in the nginx unit would fix this
<adisbladis> Regardless of screwed up permissions
<{^_^}> firing: HomepageUpdateStuck: https://status.nixos.org/prometheus/alerts
<infinisil> domenkozar[m]: I personally at least am most bothered by the format
<infinisil> But yeah tooling could definitely be better too
<infinisil> Especially the thing about putting docs right next to the relevant code
<Profpatsch> If the docs build were somewhat more granular we could switch to a nix-based build instead of that makefile thing that dumps files in-tree
<Profpatsch> which then leads to stale files for the nix build if you forget to clean before running the nix build …
abathur has joined #nixos-dev
<genesis> what about create some pkgs/top-level/appimages-packages.nix like pkgs/top-level/lua-packages.nix to manage short recipe as https://github.com/NixOS/nixpkgs/issues/38037#issuecomment-478687733 and don't poluate nixpkgs with such thing ? setting global unfree licence on it to prevent building/caching ?
abathur has quit [Ping timeout: 240 seconds]
phreedom has quit [Remote host closed the connection]
abathur has joined #nixos-dev
phreedom has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
<genesis> oki that's working.
justanotheruser has joined #nixos-dev
abathur has quit [Ping timeout: 258 seconds]
abathur has joined #nixos-dev
cole-h has joined #nixos-dev
dongcarl has joined #nixos-dev
<genesis> #82158 , for discussion
<{^_^}> https://github.com/NixOS/nixpkgs/pull/82158 (by bignaux, 3 minutes ago, open): [wip] top-level: add appimage-packages.nix
<aminechikhaoui> gchristensen I like the idea in https://github.com/NixOS/nixops/pull/1245, I needed that sometimes at work, not for rollback but having targets to know when we run deploy and if it fails etc ..
<{^_^}> nixops#1245 (by grahamc, 2 days ago, open): Deploy Targets: Policy/Behavior-free Deployment Hooks (auto-rollbacks, drain events, etc.)
<aminechikhaoui> for me personally, I think getting the units dependencies right would be the challenge, but I have that problem in all systemd services setup
<aminechikhaoui> maybe some NixOS tests to show the behavior on a couple of examples would be nice to have also
<infinisil> aminechikhaoui: Yeah systemd dependencies I struggle with too..
<adisbladis> aminechikhaoui: I have some units you can look at built on top of that PR
<edef> hmm, i'm feeling profiles/headless.nix is a little confused about its purpose
<edef> it's imported solely by profiles for cloud virtual machine targets
<edef> which all set console=ttyS0 (except for Brightbox, but i think that's because it's an undermaintained fork of the EC2 code)
<edef> it disables serial getty, which is then ~impossible to override cleanly, despite targeting places where serial can definitely be interactive (GCE)
ixxie has joined #nixos-dev
<edef> it sets panic=1 and boot.panic_on_fail but most of the profiles that import it duplicate that themselves
<andi-> edef: I agree.. slightly different topic but I'd like to see proper serial-only support in nixpkgs. Right now I've to configure multiple locations with my desired baud rate and the serial interface that should be used.
<edef> the division of responsibilities among the cloud stuff seems really weird in general
<edef> all of them mess with sshd individually
<edef> they also all have this thing of sticking an /etc/nixos/configuration.nix into the image, which is at best confusing on production deployments
<adisbladis> Omg
<adisbladis> That needs to die
<andi-> throw "this is not a real config"
<niksnut> why shouldn't it be a real config?
<edef> niksnut: { imports = [ <nixpkgs/nixos/modules/virtualisation/google-compute-image.nix> ]; } is certainly not "a real config"
<niksnut> it's certainly the intent that you can create an EC2 instance and run nixos-rebuild inside it
<edef> and i am not shipping my entire repository to a machine where i should be *getting paged* if libnixexpr is ever even invoked
<edef> niksnut: i think of the EC2 images we ship with releases as something akin to the live CD
<edef> niksnut: they're demo systems to some degree, they're not what i'll actually build my production systems off of
<andi-> I think for an EC2 instance that is supposed to be mutated by calling nixos-rebuild that is actually fine. If you intend to not have that file on your custom images you can override the `configFile` attribute to whatever you want.
<andi-> And that is what I meant with the throw line above
<niksnut> right
<edef> i'm obviously fine with the live CD coming with a neat little default /etc/nixos/configuration.nix, nicely commented to explain what things you might want to do with it, etc
<edef> but even if you're just using nixops, libnixexpr shouldn't ever be invoked on the target system
<andi-> adisbladis: what is your concern about that file being there?
<yorick> edef: also, the aws images do a nixos-rebuild from user data during boot
<edef> i hope to never use that feature
<yorick> but yeah, the nix evaluator memory requirements mean we have long given up on evaluating anything on ec2
<adisbladis> andi-: Exactly what edef pointed out about the nixops case
<gchristensen> infinisil: "The rollback behavior you described there is pretty much how I implemented it here" it doesn't seem to implement the one-time boot then confirm case?
<infinisil> Ah no indeed
<infinisil> It just does a boot switch
<gchristensen> gotcha
<{^_^}> firing: HomepageUpdateStuck: https://status.nixos.org/prometheus/alerts
<arianvp> question about the new python test infra
<arianvp> in the old perl stuff, I remember a call to wait_for_unit would implictly start the server
<arianvp> is this still the case? I see in many tests the vm is explicity start with myvmtest.start()
<arianvp> before claling myvmtest.wait_for_unit("defualt.targt")
claudiii has joined #nixos-dev
<rnhmjoj> do you have any explanation for how a derivation depends directly on something which is not in the buildsInputs?
<rnhmjoj> a recent bump of python3Packages.protobuf broke monero-gui, which doesn't have (explictly) a dependency on protobuf, let alone on the python bindings
<adisbladis> arianvp: Yes that's still the case
abathur has quit [Ping timeout: 260 seconds]
<jtojnar> rnhmjoj via monero
<rnhmjoj> jtojnar: that's strange because monero builds but monero-gui does not
<jtojnar> rnhmjoj how did you determine protobuf is at fault?
<jtojnar> for me it looks like some kind of linking error
<rnhmjoj> git bisect
<arianvp> adisbladis: danke
<rnhmjoj> this commit appears to be the first bad: d8d9358c041d2f2af9655090d8eba24c177fe989
<jtojnar> hmm, monero uses static libs
<rnhmjoj> protobuf shouldn't be
<jtojnar> rnhmjoj but if you link against a static library you need to also link against all the things it depends on
<jtojnar> I would suggest building monero as dynamic library instead
<zimbatm> edef: quick question; is the gerrit nixos module that you submitted in your PR something that's already running in prod for you?
<zimbatm> feel free to PM me if you want to discuss a bit more about the implementation
<edef> zimbatm: it is, yeah
<zimbatm> I pushed a few changes on the PR, hope it's ok
<edef> i was expecting that / hoping for that
<zimbatm> I have a few more lined-up that I cherry-picked from my own branch
<zimbatm> ok
<zimbatm> in that case I will continue tomorrow and ping you when it's ready and we can then discuss on what to keep or not
<edef> ack
<zimbatm> ty
<edef> i assume you're cool with me squashing stuff (probably tomorrow), i'll Co-authored-by you in
<edef> so far i've only been running this in *prod* for a few days, with essentially 2 users
<edef> there's def work to be done in terms of making this work with replicas etc
<zimbatm> yeah no problem, I don't really care about ownership anyways
drakonis has joined #nixos-dev
<zimbatm> on my side I have been running gerrit with ~20 users and CI pulling from it
<zimbatm> we have a large repo with git-lfs
<zimbatm> there's definitely some tuning to do on the JVM and also the number of threads available
<zimbatm> I haven't touched replicas yet
<zimbatm> we were using a docker container and it's starting to be annoying to manage => nixos!
<zimbatm> we are using SSH quite a bit so I will have to add support for that
<zimbatm> it's also running in Google cloud
<zimbatm> too bad the Google LB doesn't support both HTTPS and TCP on the same instance
<edef> hmm, damn
<edef> i was hoping that'd be supported
<zimbatm> there is a TCP load-balancer that supports TLS termination
<zimbatm> which means no HTTP/2 negociation
drakonis has quit [Ping timeout: 256 seconds]
<edef> i was considering using IAP rather than the Google OAuth plugin
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 256 seconds]
Jackneill has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
ris has joined #nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
ixxie has quit [Ping timeout: 268 seconds]
<arianvp> aszlig: ping
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 256 seconds]
<arianvp> question: Why do nixos tests only output the VM build log in nice html when the test _succeeds_ ?
<arianvp> e.g. why does a failed test fail the build
<arianvp> s/e.g./i.e./
<arianvp> this means we never get to see that juicy html output to inspect a failed test
<arianvp> niksnut: I git-blame'd my way through and saw you disabled it at some point to fix issues with hydra
<gchristensen> it breaks the model to have a successful build which failed
<gchristensen> kind of annoying
<samueldr> there is/was something used for hydra-uses IIRC at one point
<arianvp> yeh but it's also a shame that we have all this nice code to show pretty hierachical build logs
<arianvp> and then I Cant view them when a test failed
<samueldr> I agree
<arianvp> (locally too)
<gchristensen> I agree
<arianvp> maybe we can add a flag to ignore failures locally or something?
<gchristensen> how about --keep-failed, instead
<samueldr> https://nixos.org/nix/manual/#ssec-relnotes-2.0 >> Failed build caching has been removed. This feature was introduced to support the Hydra continuous build system, but Hydra no longer uses it.
<arianvp> TIL keep-failed
<samueldr> what does hydra do now, with failed builds, if anything?
<gchristensen> probably never attempts to redo them, since the database already has a record of that build failing
<niksnut> didn't the hierarchical build logs get removed already?
<samueldr> I meant to keep the VM logs
<arianvp> keep-failed doesn't keep the outputs, it keeps the .drv buiild script it seems?
<arianvp> niksnut: nope they're still there
<samueldr> arianvp: should keep /tmp stuff
<gchristensen> arianvp: it does keep the outputs in /nix/store until they're garbage collected, and it keeps the tmp dir in /tmp
<niksnut> should get rid of them
<gchristensen> niksnut: oh?
<niksnut> we already deleted most support for nested logs (e.g. the gnu make patch)
<gchristensen> huh
<niksnut> and the support in nix
<arianvp> im talking about hierachical test logs, not build logs
<arianvp> or is that the same?
<niksnut> that was more or less the same thing
<arianvp> ah
<niksnut> it used the same xslt hackery
<arianvp> I liked it because currently with the linear nixos test logs it's really hard to figure out which test step failed
<arianvp> but yeh if we dont feel like supporting it perhaps we should remove it
<arianvp> (or come up with something better)
<gchristensen> or add it back to GNU Make and other tools >:)
<arianvp> hmm but it doesn't look that hacky to me at all?
<arianvp> what part is hacky eelco
<arianvp> only 136 lines of xslt >:)
<arianvp> (no honestly; it doesn't actually look that bad to me. )
<arianvp> gchristensen: keep-failed doesnt do the job, as the part that generates the log.xml and log.html isn't called when the vm test failes. alas
<gchristensen> ah
<gchristensen> it could probably tohugh
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 240 seconds]
<niksnut> so the only place where we still have the nested logs is in the VM tests
bhipple has joined #nixos-dev
orivej has joined #nixos-dev
<{^_^}> firing: HomepageUpdateStuck: https://status.nixos.org/prometheus/alerts
<aszlig> arianvp: pong
abathur has joined #nixos-dev
<aszlig> arianvp, niksnut: ah, yeah, having access to the output paths of failed builds in hydra would be nice... especially in tests it would actually help a lot, eg. for providing test reports and/or videos
<aszlig> for my deployment tests i usually work around this by touching nix-support/failed, but that makes it annoying to restart a failed build
bhipple has quit [Read error: Connection reset by peer]
bhipple has joined #nixos-dev
Jackneill has joined #nixos-dev
bhipple has quit [Read error: Connection reset by peer]
Jackneill has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
<jtojnar> gchristensen do we want the maintainer teams to be first class?
<gchristensen> jtojnar: I think that would be cool
<gchristensen> though a bit trickier
<gchristensen> for example, github can't request reviews from a team afaik
<jtojnar> it should be easy for ofborg
<{^_^}> ofborg#421 (by jtojnar, 15 weeks ago, open): maintainers: Add support for teams
<gchristensen> :o
<gchristensen> we'd need to make similar updates to hydra and the nixos website generator I think
<jtojnar> yup
<jtojnar> (by first class I mean usable directly in meta.maintainers and allowing teams being members of teams)
<gchristensen> right
<gchristensen> I think it may be too early to go that way
<gchristensen> and that we can always do something more fancy later, what do you htink?
<jtojnar> sounds fine to me
<gchristensen> it might be cool, for example, for ofborg to be able to tag an actual NixOS orga team
<gchristensen> should I just press merge then? :P
<jtojnar> gchristensen should we have default type and membership?
<gchristensen> hmm probably
<gchristensen> probably "open" and "interest group" by default? :)
<jtojnar> also maybe membership is too similar to members
<gchristensen> true
<jtojnar> we could just add a comment like # visit foo.company/jobs if you want to join
<gchristensen> hehe, yes that is cute :)
<gchristensen> ideally eventually ofborg could *require* that an existing member approved it
<gchristensen> so having the data exist to manage that would be nice, but not critical
<gchristensen> maybe policy instead of membership?
<gchristensen> not sure
<jtojnar> having ofborg check it would be nice but not sure if it is worth the work
<gchristensen> right
<lovesegfault> jtojnar: I have an interesting update on the zoom-us issue
<lovesegfault> if I open a zoom link on firefox it works
<lovesegfault> if I launch from the cli I get that error
<jtojnar> or just open : bool
<gchristensen> jtojnar: that could work
<jtojnar> validating the the type attr would be more useful I think since it is easy to make a typo
<gchristensen> true
<gchristensen> so maybe we can just assume a policy
<gchristensen> that if it is a "business" type, the existing members should probably approve
<gchristensen> for example
<lassulus> a.
<lassulus> ups
<jtojnar> lovesegfault any specific actions, DE, logged in? I could not repro in terminal.
<lovesegfault> jtojnar: I'm on sway, but I suspect the issue has to do with this, one moment
myskran has joined #nixos-dev
<lovesegfault> I _think_ if I disable this it will work
<lovesegfault> I had repro'd this before
<jtojnar> yeah, that's what I would suspect
<jtojnar> oh, right zoom-us does not use wrapGAppsHook
<jtojnar> I think we should just patch GTK to work without that
abathur has quit [Ping timeout: 256 seconds]
<lovesegfault> jtojnar: no more wrapGApps?
<jtojnar> it will be still necessary for icons unfortunately
<lovesegfault> 😞
<jtojnar> but at least it will not crash from that particular issue
bhipple has joined #nixos-dev
<jtojnar> gchristensen should we also add github attr for the GitHub team mapping?
orivej has quit [Ping timeout: 268 seconds]
<jtojnar> I think it makes most sense to merge it as is for now and introduce other attributes as needed