gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
<gchristensen> macs :(
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 252 seconds]
lassulus_ is now known as lassulus
orivej has quit [Ping timeout: 240 seconds]
sir_guy_carleton has joined #nixos-dev
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
Sonarpulse has joined #nixos-dev
sir_guy_carleton has quit [Quit: WeeChat 2.0]
Sonarpulse has quit [Quit: Leaving]
<LnL> niksnut: I think I found another bug with upgrade-nix :/
<LnL> canonPath(profileDir) fails for relative symlinks, error: not an absolute path: 'profile-2-link'
<niksnut> LnL: urgh
<LnL> oh wait, you don't get there in the good case
<LnL> still a bug, but not as bad as I initially thought
makefu has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<domenkozar> hey, could someone proofread new weekly?
<domenkozar> should be on preview in a few seconds
<makefu> sure, i can have a quick look
<makefu> domenkozar: i think it is 'the nix ecosystem docs'
orivej has joined #nixos-dev
<domenkozar> the title barely fits on my extra-wide lcd :P
<sphalerite> is " There is nothing impossible to they who will try." a specific quote? Sounds rather awkward
<domenkozar> it was "Him" originally
<domenkozar> by alexander the great
<makefu> not sure about "artefact" vs "artifcat"
<sphalerite> domenkozar: maybe "those" or "them" in that case :)
<domenkozar> ah
<domenkozar> makefu: well british vs US english
<domenkozar> I left it as original author intended
<domenkozar> sphalerite: good point, that's balkan english :-)
<makefu> but it is ok if its upstream
<sphalerite> "to save some the boilerplate we" there's an "of" missing there, but that error's just carried over from upstream so it might be worth fixing there as well
<domenkozar> corrected
<makefu> there is an extra " at the end of the paragraph
<makefu> related xkcd https://xkcd.com/859/
<domenkozar> yikes, sorry for the pain
<domenkozar> makefu: sphalerite: thanks, all good now? :)
<sphalerite> makefu: " there you go it's over now
<ekleog> domenkozar: there's “ now?" I hope this helps!” at the end of “A way to develop software with Nix” ?
<sphalerite> ^
<makefu> sphalerite: thanks!
<domenkozar> ah
<domenkozar> today is one of those days isn't it :)
<domenkozar> ok all fixed.
obadz has quit [Ping timeout: 246 seconds]
<domenkozar> :blushes:
<domenkozar> thank you niksnut :)
<niksnut> domenkozar: do you know why that NAR is corrupt?
<domenkozar> not yet, going to investigate now
<domenkozar> it's strange because they are referenced by hash
<domenkozar> so it could be something like interrupted connection
<domenkozar> and both client and server got the wrong hash
<domenkozar> but how would that corrupt the header?
<niksnut> I'm guessing that something got truncated from the start of the NAR prior to compression
<domenkozar> yeah it's truncated
<domenkozar> will release cachix that actually checks exit code of the streaming process :-)
MichaelRaskin has left #nixos-dev [#nixos-dev]
<niksnut> but how do you truncate from the start?
<niksnut> I mean, it a process gets interrupted you would expect it to be truncated at the end
<domenkozar> diffing newly created nar and extracting the corrupted one they have the same contents in the begining
<domenkozar> but it's also unclear to me why is then nar header different, still looking into that
<niksnut> so the file size is the same?
<domenkozar> nah, the original file is about 5 times longer
<domenkozar> $ du -sh /home/ielectric/Downloads/a8d3c42efa059d0ebdfdae7f1c8fe98935dbe293c960c7507d462bac85f6c610.nar
<domenkozar> 26M /home/ielectric/Downloads/a8d3c42efa059d0ebdfdae7f1c8fe98935dbe293c960c7507d462bac85f6c610.nar
<domenkozar> $ du -sh src.nar
<domenkozar> 169M src.nar
orivej has quit [Ping timeout: 252 seconds]
obadz has joined #nixos-dev
<andi-> Who can I ping regarding the box `ike`? It is stalling jobs big time.. The longest job is running for >12days :/ It keeps on stalling more jobs.
<LnL> niksnut: ^
<LnL> not sure who else can update the machines list
pepesza has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in]
<gchristensen> andi-: yeah I was looking at that this morning
ekleog has quit [Quit: back soon]
<gchristensen> andi-: niksnut is looking in to why they're stalled
<andi-> gchristensen: thank you for the update (& thanks niksnut ;-))
<domenkozar> gchristensen: I forgot again. What's your method to access nixos tests vm?
<gchristensen> https://github.com/tumblr/jetpants/tree/master/testing#entering-a-test-vm should move that to the official docs :})
<domenkozar> although foobar password is something you've setup right?
<domenkozar> I wonder if we can just put that into base image for nixos tests
<domenkozar> :O
<domenkozar> it has rootkit anyway installed
<domenkozar> so why not have another
<domenkozar> gchristensen: I'd like to get this upstream
<domenkozar> but first, think if the other solution is better
<domenkozar> I think this method gives a bit better UX, since you don't need to do anything to access those machines
<domenkozar> it just exposes by default
<domenkozar> the whole network
<gchristensen> I agree
<domenkozar> the drawback is that it's a bit impure
<domenkozar> probably existing tap0 would fail the test
<gchristensen> yeah that is tough :/
<domenkozar> might be an issue on machines that run multiple tests at the same time
<gchristensen> the "foobar" thing is a silly thing, doesn't feel good
<domenkozar> well vms have rootkit anyway
<domenkozar> but it's network isolated from the host
<domenkozar> could offer this as a flag
ekleog has joined #nixos-dev
goibhniu has joined #nixos-dev
<gchristensen> andi-: so those jobs should be restarted now
<andi-> gchristensen: ok
<gchristensen> found a cyclical deadlock in the download :)
<domenkozar> :o
<domenkozar> that's x,y, and z?
<gchristensen> each vertical slice is a histogram of the duration builds have been running for
<gchristensen> so these are the same jobs, taking about six hours: https://screenshotscdn.firefoxusercontent.com/images/8d0d595d-f6cb-4dba-9aa3-a890583ff8e1.png
<gchristensen> https://screenshotscdn.firefoxusercontent.com/images/c2d0e767-c022-4a43-8a50-541a63c05b39.png this is the set of builds which were stuck on Ike
<gchristensen> so these are the same jobs, taking about six hours: https://screenshotscdn.firefoxusercontent.com/images/8d0d595d-f6cb-4dba-9aa3-a890583ff8e1.png <- this is two different set of jobs, each taking about six hours.
<aszlig> hm, is my reality distorted at some point or do staging merges occur less frequently these days?
<aszlig> gchristensen: regarding entering the test vm: this would also imply that sshd needs to be running in the VM, right?
<aszlig> which for almost all tests isn't the case
<domenkozar> aszlig: btw thanks so much for letsencrypt nixos tests
<domenkozar> I'm using the infra to fake S3 :P
<aszlig> domenkozar: :-D
<domenkozar> like cachix functional test is 150 lines in total, testing the whole api against a real backend
<domenkozar> crazy :)
<domenkozar> api==cli
<domenkozar> really cool :)
<aszlig> domenkozar: if you're using nixops, this one might also be useful: https://github.com/headcounter/deployment/blob/master/modules/testing/nixops.nix
<domenkozar> heh
<domenkozar> yeah had similar thoughts
<domenkozar> but nowadays I'd inverse logic
<domenkozar> service.mymodule.privateIP
<domenkozar> and then set that with nixops
<domenkozar> and dummy values in tests
<aszlig> domenkozar: yeah, i started with something like that
<domenkozar> it can get hairy :)
<aszlig> domenkozar: but i'm using encryptedLinksTo, which is why i've written that module
<aszlig> domenkozar: oh, and for debugging tests with networking: https://github.com/headcounter/deployment/blob/master/modules/testing/tshark.nix
<domenkozar> heh
<domenkozar> right now I'm trying to ssh into nixos test vm
<domenkozar> but my old hack doesn't work
<domenkozar> vde_switch: Failed to open /dev/net/tun No such file or directory
<aszlig> at some point i thought about making VM tests more modular so that you can have "infrastructure" modules or something like that
<domenkozar> vde_switch: ERROR OPENING tap interface: tap0
<domenkozar> this does run on host right?
<Dezgeg> you can get almost-as-good vm debugging experience by passing a serial console over a unix domain socket
<aszlig> domenkozar: the vde_switch?
<domenkozar> ye
<aszlig> yep
<domenkozar> Dezgeg: I remember there are some issues with that
<domenkozar> hmmm, why would it fail opening tun then?
<Dezgeg> terminal size is probably wrong yes, and you don't get scp
<aszlig> domenkozar: what are you trying to do?
<domenkozar> Dezgeg: do you have a diff how to integrate that?
<domenkozar> aszlig: access qemu vm
<domenkozar> well mainly come up with something we can have in nixos
<aszlig> domenkozar: i mean, what was the command where you got that error?
<domenkozar> for debugging tests
<Dezgeg> but on the plus size, no configuration, just as root locate the correct nix-build-foo directory and connect to the socket
<Dezgeg> for nixos tests no, I've used it for runInLinuxVM stuff
<domenkozar> well sure, should be almost the same
<domenkozar> aszlig: passed -tap tap0 to vde_switch
<aszlig> Dezgeg: i think the main issue with attaching a serial device is that you need to set environment seperately
<Dezgeg> on nixos you can rely on starting an actual getty as a systemd service instead of some manual hack
<Dezgeg> what environment?
<aszlig> regarding ssh into a vm, i wrote something similar as well: https://github.com/headcounter/shabitica/blob/master/build-vm.nix
<aszlig> Dezgeg: like TERM, LANG, etc...
<Dezgeg> how is it different from any normal serial console login to nixos?
<aszlig> Dezgeg: the difference is that you get the environment of the test vm instead of the local environment
<aszlig> Dezgeg: ssh on the other side sets those variables
<Dezgeg> well sure there are some minor differences
<aszlig> Dezgeg: those can get pretty annoying, especially when you have a very minimal test machine
<domenkozar> hmm, maybe /dev/net is not allowed anymore in sandbox
orivej has joined #nixos-dev
<aszlig> also when you CTRL+c an application, SIGINT is sent to the corresponding pid
<domenkozar> yes :(
<Dezgeg> anyway, what I do here is pass this to qemu: -serial unix:$TMPDIR/ttyS1,server,nowait
<Dezgeg> then connect with something like: socat STDIO,raw,echo=0,escape=0x11 UNIX:/var/tmp/nix-build-vm-drv.drv-0/ttyS1
<aszlig> domenkozar: ah, yes, it's not available within the builder
<domenkozar> it used to be 2 years ago :D
<domenkozar> Dezgeg: thanks, let me try that.
<Dezgeg> and on nixos side you need a getty running on that port, that one I can't remember how to do offhand
<aszlig> Dezgeg: if i'm not mistaken this should kill socat on CTRL+c
<Dezgeg> no, it's in raw mode
<Dezgeg> with CTRL-Q to exit (escape=0x11)
<aszlig> Dezgeg: ah, right
<aszlig> Dezgeg: hm... let me try that... i still have the suspicion that SIGINT is then not delivered...
<domenkozar> Dezgeg: is it something like
<domenkozar> boot.kernelParams = [ "console=ttyS0" ];
<domenkozar> I remember the problem was you can't have multiple consoles
<domenkozar> at tests use one
<domenkozar> as*
<Dezgeg> I imagine it's just doing this but with s/false/true/: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/profiles/headless.nix#L13
<Dezgeg> but certainly it's possible to have multiple consoles with one taken by the testing stuff
<domenkozar> well it's the same console as for testing
<gchristensen> I really appreciate how incredibly talented and smart our community is ^.^
<Dezgeg> no, adding a second one will add ttyS1
<domenkozar> hmm, hoped that
<domenkozar> boot.kernelParams = ["console=ttyS1"];
<domenkozar> would add one :)
<domenkozar> and
<domenkozar> systemd.services."serial-getty@ttyS1".enable = lib.mkForce true;
<aszlig> Dezgeg: okay, SIGINT is getting delivered correctly
<domenkozar> aszlig: with tests infra?
<aszlig> domenkozar: i used the build-vm.nix posted before
<aszlig> something like SIGWINCH propagation and copying terminal attributes plus a few environment variables would be nice, but other than that it's preferable to the ssh-variant
<domenkozar> what's not clear to me is how to attach a serial console to that socket on the guest side
<Dezgeg> for nix-build ./nixos/release.nix -A tests.firewall.x86_64-linux you get in with socat STDIO,raw,echo=0,escape=0x11 UNIX:/tmp/nix-build-vm-test-run-firewall.drv-0/vm-state-walled/backdoor
<domenkozar> hvc1!
<domenkozar> Dezgeg: thanks, testing
<domenkozar> :O
<domenkozar> it works
<domenkozar> this is really good :)
* gchristensen refers back to my message from 45min ago
<domenkozar> :D
<domenkozar> Dezgeg: do you mind if I make a PR and document this?
sir_guy_carleton has joined #nixos-dev
<Mic92> fpletz: is it possible to configure rspamd with the rspamd.conf or do I have to use these includes?
<aszlig> domenkozar, Dezgeg: hm, maybe it makes sense to expose the device only when running in a nix shell
<domenkozar> aszlig: why not just always
<aszlig> domenkozar: to avoid allocating that tty every time a machine is spun up
<domenkozar> to avoid due to security or something else?
<aszlig> domenkozar: nah, security shouldn't be an issue, it's just a (very) little more overhead
<domenkozar> shouldn't make a difference with the long running times of just vm spinning up
<samueldr> aszlig: then the conditions in which the test executes changes (additional tty vs none) most shouldn't fail then, but the moment it does it would be a pain :)
<aszlig> samueldr: agreed
<domenkozar> so the good news is, this setup is very nice
<aszlig> s/^/domenkozar, /
<domenkozar> the bad news is, the reason why test was failing is a stupid PEBKAC
<Dezgeg> domenkozar: go ahead
<aszlig> hm, i'm searching a while now and i wonder why there isn't something very minimal that does exactly the same as SSH does (minus encryption, etc...)
<Dezgeg> yeah, I couldn't find anything either
<aszlig> Dezgeg: so maybe it's time to hack something together then
<Dezgeg> I mean telnet would work if only any of the clients accepted unix domain sockets
<aszlig> or we're just to stupid to search
<aszlig> Dezgeg: telnet already is too much, because it uses a different protocol
<aszlig> IMHO it should just be like: connect -> allocate pty -> set termattrs, env, whatnot and relay everything unchanged
<aszlig> probably in a different order though :-D
<Dezgeg> yes, but you need an out-of-band channel to deliver that information
<Dezgeg> (ideally)
<aszlig> yah, of course, just a serial device doesn't necessarily work
<aszlig> basically searching for something like mosh, minus udp+encryption
<cransom> would socat with a ton of options thrown at it do?
<aszlig> cransom: not really, because you would need signal handling on the client side etc... (as mentioned above)
<aszlig> as far as i can see socat doesn't support that
<aszlig> the signals need to be communicated OOB though
<aszlig> and/or multiplexed
<Dezgeg> maybe this works: https://github.com/clownix/cloonix_vsock
<aszlig> Dezgeg: hm, that looks promising
<aszlig> it even has file transfer
<aszlig> but other than that it looks like something we can use
<aszlig> and that hardcoded bash should probably fetched using getpwent
<aszlig> Dezgeg: okay, thanks... i think i'm going to fix those things and package it for nixpkgs
<aszlig> another thing is that it uses AF_VSOCK, so it shouldn't collide with other things in the guest
<aszlig> damn... there is currently no way to use AF_VSOCK in the guest and expose it via unix domain socket to the host :-/
<aszlig> so it's all done via an id (CID) assigned to a specific guest and you need /dev/vhost-vsock on the host as well
<grw>
phreedom_ has quit [Ping timeout: 256 seconds]
phreedom has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
Lisanna has joined #nixos-dev
Lisanna has quit [Client Quit]