das_j has quit [Remote host closed the connection]
Scriptkiddi has quit [Remote host closed the connection]
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
eraserhd has quit [Quit: WeeChat 2.6]
Guanin_ has quit [Remote host closed the connection]
orivej has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.6]
eraserhd has joined #nixos-dev
eraserhd has quit [Client Quit]
eraserhd has joined #nixos-dev
eraserhd has quit [Client Quit]
cjpbirkbeck has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
cjpbirkbeck has quit [Quit: Quitting now.]
teto has quit [Ping timeout: 244 seconds]
<clever>
Nov 21 04:56:26 nas hydra-queue-runner[16390]: querying info about '/nix/store/w5rc9dc6w6a7x0y43lsm1l9dn8l9lg91-script.ipxe' on 'http://nas.localnet:8081'...
<clever>
Nov 21 04:56:28 nas hydra-queue-runner[16390]: querying info about '/nix/store/1dp1b8v5f6r6ksqxvf8063bcvxs79w6k-ipxe-20190318-ebf2eaf' on 'http://nas.localnet:8081'...
<clever>
thoughtpolice: i'm seeing upwards of a 2 second delay between requests for hydra-queue-runner
FRidh has joined #nixos-dev
ckauhaus has joined #nixos-dev
__monty__ has joined #nixos-dev
<ckauhaus>
hey
<ckauhaus>
there's quite a bit of good stuff on staging-19.09
<ckauhaus>
would anyone like to merge that into release-19.09?
<FRidh>
ckauhaus: just cherry-picked a darwin fix to staging-19.09 and scheduled an evaluation. This should clean up the list of failures, better showing whether there are any regressions
Jackneill has quit [Remote host closed the connection]
<adisbladis>
Ericson2314: Can I pm you?
orivej has joined #nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
drakonis_ has joined #nixos-dev
kreisys has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
red[evilred] has joined #nixos-dev
<red[evilred]>
Speaking of nixops... has disnix been completely replaced by nixops now?
<samueldr>
aren't they solving different problems, with some overlap?
atriq is now known as Taneb
<samueldr>
I was under the assumption that nixops is more about deploying NixOS (and its configs) to machines, while Disnix is about deploying software using Nix to different kind of machines
<gchristensen>
I think it would be really good for the different output formats for NixOS tobe trivially accessible
<samueldr>
or nixos-rebuild build, I don't think it needs a new subcomand
<samueldr>
but... I'm thinking one step to the side, a kind of `nixos build` which is not tied to the NIX_PATH's <nixos-config> or default path of /etc/nixos/configuration.nix
<samueldr>
more of a plumbing type command
<samueldr>
where rebuild would basically be "nixos build, but with <nixos-config>"
<samueldr>
a theoretical `nixos build` could even use $PWD/configuration.nix as a default
<gchristensen>
seems great
<samueldr>
that'd make a second kind of well-known file to put at the root of repos, joining default.nix, shell.nix and release.nix... if it makes sense
<gchristensen>
+1
<samueldr>
what'd make this even better is if system types were somehow part of the modules system and extensible, so a repo could, in a self-contained manner, add a new system type to the command
<samueldr>
so something like `cd mobile-nixos; nixos build --type android-system` could be possible without the upstream nixpkgs implementing the type
<samueldr>
(that's still thinking out loud)
<samueldr>
I don't know if there are constraints that make this harder to, e.g. list system types
<gchristensen>
+1
<adisbladis>
gchristensen: You mind sending me those slides later? :)
<gchristensen>
adisbladis: let's PM :P
aminechikhaoui has quit [Ping timeout: 240 seconds]
<tilpner>
I don't know why I waited two years to replace the tiny SSD my laptop came with
<fuzen>
At least you get more for your money after 2 years
evanjs has joined #nixos-dev
<jtojnar>
everything segfaulting in gnome3-xorg test dues to missing schemas, wth?!
hexa- has quit [Quit: WeeChat 2.6]
<jtojnar>
hmm, another regression in set -u hooks
hexa- has joined #nixos-dev
<thoughtpolice>
Yeah, I can't say I've ever regretted my 512GB NVMe SSD. Pricey but so very, very worth it
Jackneill has joined #nixos-dev
<jtojnar>
I am hoping 1 TB will last me a while, that's four times the size of the current one
<thoughtpolice>
IME it should do fine. I don't think I've ever gone beyond like, 70% usage on my NVMe drive. To be fair, that drive is mostly my homedir, and /nix
<thoughtpolice>
And I don't even have auto GC turned on, I run it manually like, once every blue moon
<jtojnar>
here I go nix-collect-garbage for the eleventh time today
<jtojnar>
and every time it seems to remove less and less space, even though I deleted the result directories
<qyliss>
Do you have optimisation enabled?
<qyliss>
I bought a 480GB SSD a couple of days ago for €50
<jtojnar>
qyliss optimization of what?
<qyliss>
store optimisation
<qyliss>
nix-store --optimise and corresponding nix.conf option
<qyliss>
It hard links identical files in the store, thus saving (quite a lot of) space
<thoughtpolice>
Note that if you haven't enabled that by default it's going to hurt a lot the first time since it scans the whole store.
<jtojnar>
hmm, I did not thanks for the tip
<thoughtpolice>
It was dramatic for $WORK stuff previously though. Had a bunch of versions of some proprietary software installed (~40GB per install) and store optimization did a massive number on that
<thoughtpolice>
Since about 80% of the files were the same between versions
<jtojnar>
though I still do not understand why I had 6 GB free and after deleting results and collecting garbage I only have 2GB
<samueldr>
is nix having trouble emptying the trash folder?
<samueldr>
happened to me once with a broken ext4fs
Jackneill has quit [Remote host closed the connection]
<thoughtpolice>
domenkozar[m]: Thank you so much for fixing sandboxing in the install-nix-action. I just got it working for Eris and it was really easy!
<thoughtpolice>
Unfortunate issue: /dev/kvm is not available, so GitHub Actions cannot run NixOS tests :(
<qyliss>
Makes sense -- it'll be running in a VM already
<qyliss>
But sad
<jtojnar>
samueldr Might be the case I am getting `error: cannot link '/nix/store/.tmp-link-21956-501056849' to '/nix/store/.links/1q6am6fz3mrjycybf0zlagplii6drkrld1q2i67aiia3jx9fq8dx': Structure needs cleaning`
<jtojnar>
from nix-store --optimize
<samueldr>
jtojnar: in my case I had some other details in dmesg
<thoughtpolice>
Nested VM support is totally viable! But yeah, it sort of depends on several factors and I'm not surprised it's not there by default
<samueldr>
is there any advantage to the install nix action, rather than using the nix docker?
<thoughtpolice>
(In all honesty, it wouldn't surprise me if the GitHub Actions VM itself was a nested VM already)
<qyliss>
Oh is it? I thought it was an area still under heavy development.
<jtojnar>
samueldr right [180988.750786] EXT4-fs error (device dm-3): htree_dirblock_to_tree:1025: inode #4718604: block 19290157: comm nix-daemon: bad entry in directory: rec_len % 4 != 0 - offset=2170880, inode=4177036105, rec_len=33807, name_len=92, size=4096
<thoughtpolice>
samueldr: Yes, it actually works lol. I tried setting up Eris to use LnL's nix-docker image and it didn't quite work
<samueldr>
jtojnar: reboot, fsck, check the store, I guess
<thoughtpolice>
IIRC, it's something like this:
<samueldr>
thoughtpolice: weird, my action-nix-build works, though I'm using the *nix* docker image
<thoughtpolice>
In the new versions of Actions, when you use a container, they try to run a small node program to watch the container logs. Unfortunately, inside some musl-based environment, or nix-docker, this obviously won't work since it can't find glibc
<thoughtpolice>
Oh, really? It's probably because glibc is on that image, I'd guess?
<jtojnar>
is it possible that EXT4 gets corrupted when it runs out of space? This is not the first time (though I never had evidence)
<thoughtpolice>
They might have actually fixed that behavior since I saw it first supported
<samueldr>
alpine based, so I wouldn't know
<thoughtpolice>
It worked great with the original workflow tools (based on Hashicorp configs)
<samueldr>
I never have seen action-nix-build fail, but didn't use it with the "new style" actions when they were introduced, just recently
<samueldr>
yeah, those were much better imo to write and grok
<thoughtpolice>
Yeah, maybe they fixed it actually.
<thoughtpolice>
Which is nice! One other feature of the VM approach over the docker container is that sandboxing can really be enabled
<thoughtpolice>
Since systemd can't run in the container itself
<samueldr>
"vm approach" meaning "installing nix" here?
<thoughtpolice>
When using LnL's image I wasn't so worried about this since it's fairly "purified" on its own, but on a regular, non-handcrafted-distro image like Alpine, I might be a little more wary. Luckily domenkozar[m] fixed that too
<thoughtpolice>
Yeah
<samueldr>
yeah, hadn't thought about sandboxing, that's a fair point
<thoughtpolice>
It's confusing because in the new version of Actions you always pick a VM, but when you pick it you can optionally choose a container to run further after the VM starts. Sort of weird.
<samueldr>
extremely, and there's few notes about the interaction of both worlds
<thoughtpolice>
No tests is a bit unfortunate for Eris, though. Other projects of mine should work great, hopefully.
<thoughtpolice>
Yeah, I found the docs somewhat lacking at first. They revamped them a bunch recently
<thoughtpolice>
The old version really was a lot simpler but I can see how the new version is far better for things like matrix building
<jtojnar>
After fsck, I suddenly have 15 GB free
<domenkozar[m]>
thoughtpolice: yw :)
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<LnL>
thoughtpolice: what didn't work?
<thoughtpolice>
LnL: using your docker container for nix inside the New github actions. It worked with the Old github actions, however.
<LnL>
hmm, any idea what the problem might be?
<LnL>
seems like that should work
justanotheruser has quit [Ping timeout: 240 seconds]
v0|d has quit [Ping timeout: 265 seconds]
<thoughtpolice>
LnL: > In the new versions of Actions, when you use a container, they try to run a small node program to watch the container logs. Unfortunately, inside some musl-based environment, or nix-docker, this obviously won't work since it can't find glibc
<thoughtpolice>
But as samueldr noted, they might have fixed this behavior. Not sure.
<thoughtpolice>
The whole node program was doing something incredibly simple anyway so they could totally have done that
<LnL>
thoughtpolice: ah I see, that intentionally won't work unless they use the sidecar approach
<LnL>
but adding 2 symlinks to the container could be enough to get that functional
<samueldr>
I don't really know much about github actions, only that in the nine months I wasn't using it they changed everything :/