gchristensen changed the topic of #nixos-borg to: https://www.patreon.com/ofborg https://monitoring.nix.ci/dashboard/db/ofborg?refresh=10s&orgId=1&from=now-1h&to=now "I get to skip reviewing the PHP code and just wait until it is rewritten in something sane, like POSIX shell. || https://logs.nix.samueldr.com/nixos-borg
tilpner has joined #nixos-borg
<gchristensen> infinisil: I'm not sure why https://github.com/NixOS/nixpkgs/pull/54577 was merged?
<{^_^}> #54577 (by alyssais, 10 hours ago, merged): Mark LibreOffice dependencies as Darwin-compatible
<gchristensen> oh, nvm
<infinisil> gchristensen: Ah, I assumed that ofborg was just messed up there, was it not?
<gchristensen> all the "Neutral" checks are timeouts
<gchristensen> its all good :) (ofborg wasn't messing up though :))
<infinisil> Ah I see
<gchristensen> once eval problems are merge blockers, then build failures can become red X's
orivej has quit [Ping timeout: 240 seconds]
Mic92 has joined #nixos-borg
orivej has joined #nixos-borg
<Mic92> now with the new shiny github ci integration the toolbars might be no longer required: https://logs.nix.ci/?attempt_id=ad48208e-429d-4c25-a6b3-7c3d86c4a38a&key=nixos%2Fnixpkgs.54574
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-borg
orivej has quit [Ping timeout: 240 seconds]
<{^_^}> [ofborg] @grahamc pushed 2 commits to fixup-tests-darwin: https://git.io/fhKdd
<{^_^}> [ofborg] @grahamc opened pull request #309 → Fixup tests darwin → https://git.io/fhKdF
<{^_^}> [ofborg] @grahamc merged pull request #308 → autotag Pantheon → https://git.io/fhody
<{^_^}> [ofborg] @grahamc pushed 2 commits to released: https://git.io/fhKdb
<{^_^}> [ofborg] @grahamc merged pull request #309 → Fixup tests darwin → https://git.io/fhKdF
<{^_^}> [ofborg] @grahamc pushed 3 commits to released: https://git.io/fhKF8
<gchristensen> I think I have to add a database to ofborg :(
<MichaelRaskin> On the bright side, it will allow ofborg to make presentation decisions freely?
<samueldr> lol
<gchristensen> even worse!
<MichaelRaskin> And even have its own dashboard useable without connection to GitHub?
<samueldr> gchristensen: database through an API over rabbitmq I guess?
<samueldr> such an API could be useful for being ninja'd by MichaelRaskin
<samueldr> (depending on what you store in it)
<gchristensen> oh that'd be cool / good
<samueldr> pretty sure the whole STOMP thing could allow for it to be working good
<gchristensen> I hate that you just made that idea very workable! :P
* samueldr won't dig up the logs from the inception of the web interface
<samueldr> though I know everything was made to be more KISS, there is value in not having stateful data
<gchristensen> I'm sort of imagining a sqlite backend + https://www.rabbitmq.com/tutorials/tutorial-six-python.html
<MichaelRaskin> I have a bad feeling about SQLite for ofborg usage pattern…
<MichaelRaskin> You might actually hit concurrency limitations…
<gchristensen> I'd imagine a single process doing the reading / writing
<gchristensen> maybe not a nice idea if we're doing web interface
<MichaelRaskin> And you also don't control the pattern of incoming PR notifications
<gchristensen> what do you mean?
<gchristensen> that is true, but is that important?
<MichaelRaskin> Do you handle the PR notification one-by-one or in parallel?
<gchristensen> hmmm yeah, in parallel
<gchristensen> but the writes would be pretty low
<MichaelRaskin> Well, writes need all the reads to finish, then block all the reads
<MichaelRaskin> Multiple-writers many-readers is exactly what SQLite is _not_ intended for
<gchristensen> tell that to expensify! haha
<gchristensen> what would you suggest, MichaelRaskin?
<MichaelRaskin> Well, if you are OK with relying on your nodes not dying, there is a universal answer to all DB questions: PostgreSQL.
<MichaelRaskin> (I guess PostgreSQL with logical replication might sometimes be an answer if you are OK with relying on a moderate number of nodes not dying at once)
<gchristensen> guh I'm not real interested in keeping state forever :P I like how logs just disappear after a few days.
<MichaelRaskin> I escpecially like that for PRs with longer discussions and comapring the impact of differnt approaches and looking what breaks in which case wait where are my logs
<gchristensen> yeah
<gchristensen> I know
orivej has joined #nixos-borg
<infinisil> gchristensen: ofborg does a merge before it does the builds and checks right? Would be cool if it would expose a git repository with a branch for each PR, which has the merged version in it, so people can reproduce the build (with derivation hashes the same)
<MichaelRaskin> The merge is done on the local builder,though
<gchristensen> github's api does (usually) provide a merge commit
<MichaelRaskin> (I should start running an ofborg builder again; for that I should actually get around to finding where to repair the soldering in my GB Brix'es motherboard RAM slot…)
<infinisil> gchristensen: Hmm, but I guess that one updates as master changes, whereas ofborg doesn't run the build again
<gchristensen> true
<samueldr> or expose the pair of commits for the merge?
tilpner has quit [Ping timeout: 246 seconds]
tilpner has joined #nixos-borg
ekleog has quit [Quit: WeeChat 2.2]
ekleog has joined #nixos-borg
<flokli> samueldr: yesterday I was tinkering with ofborg-viewer. I couldn't get live compilation working with the provided shell.nix and what's provided in README.md. Am I missing something?
<samueldr> flokli: I don't know, let's see
<flokli> I was able to build through default.nix, but feedback loop is quite long with that…
<samueldr> flokli: I think I may have an idea
<samueldr> flokli: what the error?
<flokli> samueldr: so, there is no shell.nix, but just the default.nix
<samueldr> yeah
<flokli> and just executing bin/webpack as the readme says, complains about ../node_modules/.bin/webpack not existing
<samueldr> yep
<flokli> which is ok I guess, as I never ran npm install, yarn install or whatnot
<samueldr> yep
<flokli> but npm and yarn want to install webpack
<samueldr> I think I know
<samueldr> nix-shell works fine with the default.nix
<samueldr> yarn install would work...
<flokli> and they fail over it, when trying to do that with nix
<samueldr> ... except that there is an issue with "scripts.preinstall" in package.json
<flokli> can we provide a working environemnt through nix-shell, given we already package all javascript dependencies through yarn.nix anyhow?
<flokli> (plus some tooling on how to update these ofc)
<samueldr> maybe, no idea
<flokli> javascript packaging is always so much joy, lol
<samueldr> to get you started you could, for now, apply this patch, nix-shell, yarn install then bin/webpack-dev-server should work https://gist.github.com/4bd6dbd7ab9afcca4e0359dcbede1c85
<samueldr> I need to figure out why that was added
<samueldr> and maybe a better "story" for hacking on the js ecosystem :/
<samueldr> providing deps through nix and nix-shell, I never had to do it yet, and not sure how to make it pleasant to work with
<samueldr> (not that yarn install is more plreasant)
<samueldr> (but for users less invested in nix it works better imho)
<flokli> nice, it works
<samueldr> the codebase is... weird
<flokli> yes
<samueldr> I was trying something I had in mind, it works, but it's... not the best imho
<gchristensen> lol!
<gchristensen> :) it works a treat!
<samueldr> yes!
<flokli> I wanted to add a dark mode
<gchristensen> I tried makin git in Elm
<samueldr> ah!
<gchristensen> Elm's debugger haaaated it.
<samueldr> flokli: I can guide you
<samueldr> for the better approach
<flokli> I know the sass foo
<flokli> and tweaked some colors
<samueldr> it's less
<samueldr> :)
<flokli> yeah, I know
<flokli> sins of the past
<flokli> I'm just not sure whether I grok the rest of the infrastructure to make something like dark mode configurable
<samueldr> make it (1) add `dark-mode` to body's classes, and only override colours with .some-selector { .dark-mode & { color: ... ; background-color: ...; } }
<flokli> yes
<flokli> but the colors are a bit weird