gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
<gchristensen> I have a problem and I think my only solution is `requiredSystemFeatures = [ "impure" ];`
<gchristensen> forgive me nix store, for I have strayed from the sandbox
<clever> gchristensen: :D
<clever> gchristensen: but how do you stop other pure builds from running on that impure machine?
<gchristensen> the seventh field of /etc/nix/machines is mandatory features! built in to nix :D
Sonarpulse has joined #nixos-chat
<gchristensen> here is what I'm thinking about, clever, maybe you have some ideas
<gchristensen> I want to set up a integration testing lab, where a build might SSH to a test machine and erase then install, test, then erase nix
<gchristensen> or create a server on some host for the test
<gchristensen> host -> hosting company
<gchristensen> it is really abusing Nix for this...... but ...... I don't know, I could muscle through Jenkins or builbot I guess?
<samueldr> other than being impure, what's making you think nix wouldn't would be better than those?
<gchristensen> it would give the illusion of "oh its just a nix project" when in reality it is a dark, evil nix project
<gchristensen> whereas any jenkins etc. projects are inheritly dark and evil
<samueldr> that was my followup question, what makes you think it would work better in those :)
<samueldr> (though I understand how they *can* be used for such use cases by design)
lassulus_ has joined #nixos-chat
<clever> gchristensen: or https://buildkite.com/ could be used as well
<gchristensen> yeah, buildkite may work
<gchristensen> one issue is the build matrix is massive
lassulus has quit [Ping timeout: 260 seconds]
lassulus_ is now known as lassulus
<clever> gchristensen: buildkite accepts a yaml file of jobs, and you can upload that yaml file from another buildkite job
<clever> gchristensen: if you run `buildkite-agent pipeline upload` in a job, it will upload the `.buildkite/pipeline.yml` to the central service, and add more jobs to the build
<clever> gchristensen: i think you can also give that a filepath, and generate the yaml based on code you ran
<gchristensen> interesting
<clever> an example of such a file
<clever> you can either generate it once and put it in git like iohk does, or you could generate it within a job, and upload it dynamically
<clever> gchristensen: the agents: field in the above yaml is also used to limit which build slaves will run a given step
<gchristensen> turning this question around, does this get me something an impure nix wouldn't?
<clever> gchristensen: it can run on a system that currently lacks nix, so it doesnt have to ssh into such a machine
<clever> gchristensen: though you could also just make qemu images of each distro, and run it inside a derivation
<gchristensen> yeah, so this is sort of an easy beginning to a follow-up question of doing deploys of nixos to real hardware in a test lab
<clever> gchristensen: and if you ran 3 buildkite agents debian, ubuntu, and redhat, and the redhat goes offline, it just pauses running the redhat jobs
<clever> while if it was impure with nix trying to ssh into each, it will fail jobs needlessly
<gchristensen> true
<clever> id also rather use buildkite when controlling hardware over ssh+ipmi to test full installs
<clever> rather then trying to cheat nix
<gchristensen> samueldr: clever has good points. what do you think?
<clever> buildkite or buildbot can both do most of the above, so its just a question of how much you hate python and/or single-point-of-failure setups :P
<clever> the buildbot "config" file is just a giant chunk of python that will instantiate objects and tie them together, and it is free to patch any function it wants
<clever> both buildkite and buildbot use build slaves you provide
<clever> and buildkite is a central service (free for open-source, paid for closed-source) that could go away at any point
<clever> buildkite also has a far better UI when compared to appveyor/buildbot/travis
<gchristensen> how about in the case of 100s of cases?
<clever> buildkite might have trouble with that many steps in a job, but you could just group a chunk of them (1 column or row from your matrix?) into a single buildkite step
<gchristensen> I hate being outside of the normal envelope for software X)
<samueldr> the agent system is a good plus
<gchristensen> an annoyance is there is no obvious way to slice the jobs in to groups I think
<clever> gchristensen: what would there be 100's of testcases for?
<samueldr> though, buildkite isn't OSS, right? the agent looks like it is, but not the service/interface, right?
<samueldr> (that would make it impossible to add *something* needed to group or slice jobs)
<clever> samueldr: yeah, the central service that manages things is closed-source
<clever> samueldr: but you can upload steps to it from the agent, so you can just generate a .yml file that describes the steps and what to run, and upload it
<samueldr> (I'm playing devil's advocate here, bouncing around possible hitches)
<clever> i can also see how buildbot and its python mess could possibly do what you said
<simpson> buildbot can do anything.
<gchristensen> right now I have ~50: echo {ubuntuartful,ubuntuwily,ubuntutrusty,ubuntuxenial,arch,centos7,centos6,debianjessie,debianstretch,debianwheezy,macos13},{daemon,nodaemon},{standardcert,customcert} | tr ' ' '\n'
<simpson> The downside is that you need to know Twisted if you want to add to it.
<clever> gchristensen: first thing you would be required to do, is split it up into 1 step per distro, and install+run the agent on each distro
<clever> that reduces it to just: echo {daemon,nodaemon},{standardcert,customcert} | tr ' ' '\n' inside that step
<gchristensen> yeah
<samueldr> :o xmlformat isn't stable
<samueldr> or whatever the right word, idempotent maybe?
<clever> samueldr: ive noticed that the tojson function in perl outputs different values every time, and i had to pipe it thru jq -S to make hydra happy
jD91mZM2 has joined #nixos-chat
<MichaelRaskin> gchristensen: why would you need impurity for your test? just do it as a success condition in a fixed-output derivation…
<MichaelRaskin> Of course, if you want details, you will need to upload the to an scp target under the name "$(basename "$ou")-details.tar.gz" or something like that…
Guest21883 has joined #nixos-chat
<sphalerite> samueldr: big desktop machine at work and cheap chromebook for remoting in? :p
* sphalerite is still getting used to the whole "cattle" thing. I've got one server here that it feels kind of difficult to kill D:
<sphalerite> Goodbye, kickass-perlman! (got to love those docker-style autogenerated names)
Guest21883 has quit [Changing host]
Guest21883 has joined #nixos-chat
Guest21883 is now known as adamt
<adamt> sphalerite: Just stop petting the cattle :-)
dmc has joined #nixos-chat
<sphalerite> I suppose this one just needed to be a pet because of how I was using it (imperative experiments to get nixos working smoothly on scaleway servers)
adamt has quit [Quit: WeeChat 2.0]
Synthetica has joined #nixos-chat
<MichaelRaskin> Experiments = can always wipe and reinstall, right?
IdleBot_4bca4710 has joined #nixos-chat
<sphalerite> well it's the installation process that I'm working out.
<sphalerite> I've been "documenting" the process as a script that'll do it all for me, but, well, the artisanally-installed-by-hand thing feels special :p
MichaelRaskin has quit [Quit: MichaelRaskin]
adamt has joined #nixos-chat
<adamt> sphalerit: In general it's difficult to treat servers as cattle if you only have a single one. :P
<sphalerite> I've spawned and destroyed lots of them to test the script, but the one where I did it manually is special x)
capisce has quit [Read error: Connection reset by peer]
capisce has joined #nixos-chat
jtojnar has joined #nixos-chat
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-chat
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-chat
jtojnar has quit [Remote host closed the connection]
__monty__ has joined #nixos-chat
jtojnar has joined #nixos-chat
kini has quit [Quit: No Ping reply in 180 seconds.]
kini has joined #nixos-chat
adamt has quit [Quit: WeeChat 2.0]
Sonarpulse has quit [Ping timeout: 276 seconds]
<infinisil> Phew, the semester will be over tomorrow, should have some more time for Nix for a while then :D
Sonarpulse has joined #nixos-chat
jD91mZM2 has quit [Ping timeout: 240 seconds]
MichaelRaskin has joined #nixos-chat
IdleBot_4bca4710 has left #nixos-chat [#nixos-chat]
capisce has quit [Read error: Connection reset by peer]
capisce has joined #nixos-chat
dmc is now known as cmd
__monty__ has quit [Quit: leaving]
<samueldr> > We’ve got 3 major projects for dealing with JS applications, node2nix, yarn2nix, and yarn2nix
<samueldr> ouch
<MichaelRaskin> Two great problems, naming things and off-by-one errors try to mimic each other?
<joepie91> heh
<joepie91> one of them was meant to be npm2nix I think :)
<samueldr> I really thought there were two yarn2nix!
<samueldr> (or was)
<samueldr> is, they both look relatively active :o
<manveru> damn, i missed the rename to npm2nix
<samueldr> :)
<samueldr> that reply was riveting
<manveru> :D
<joepie91> so... there's 4 then?
<joepie91> lol
<samueldr> > Two great problems, naming things and off-by-one errors try to mimic each other?
<samueldr> in a way, this is even more true
<joepie91> hehehe
<MichaelRaskin> In reality, the three great problems are facets of the same problem: defining and verifying what it means that two things are the same… (which applies to them too, obviously)
<joepie91> the identity problem? :P
<MichaelRaskin> Yes
<MichaelRaskin> But if you just call it identity problem, some people might miss its relation to cache invalidation!
<samueldr> identity is a problem? I thought this one was `solved: solved`
<MichaelRaskin> Creating identity is easy. Recognizing identity when you get it from another source, though…
<joepie91> aaaaaa
<joepie91> I am going to dream of state machines tonighyt
<joepie91> tonight*
<joepie91> this project has *so many* of them
<joepie91> like, validly so, but still, aaaaa
<MichaelRaskin> And then, state machines are likely indeed the most understandable way to represent what is being done…
<joepie91> MichaelRaskin: I'm building the software for a Bitcoin/cryptocurrency ATM, so 1) lots of single-state hardware control, 2) single-state user interfaces, 3) bugs cost money, and 4) lots of possible error states that need totally different handling depending on where in the 'user flow' they occur
<joepie91> result: state machines that talk to state machines that talk to state machines that talk to state machines that...
<MichaelRaskin> So far you have just described a computer with keyboard and mouse connected via a USB hub
<joepie91> MichaelRaskin: bugs don't cost money there :P
<joepie91> at least not directly
<MichaelRaskin> I meant the number of state machines
<joepie91> ah, right
<joepie91> lol
<joepie91> but yeah, this thing is turning out fairly complex
<joepie91> learning a lot about the limitations of fsm implementations though