<gchristensen>
LnL: thank you for checking! :) nice to have that function be many hundred lines smaller now.
<{^_^}>
[ofborg] @grahamc pushed 0 commits to generic-builder-v2: https://git.io/fjJzA
<LnL>
yeah definitively
<gchristensen>
there is an astonishing amount of low hanging fruit here which could be made better
<gchristensen>
like replacing a single unwrap with a nicer type would be a good start
<gchristensen>
LnL: what would you think about having https://github.com/nixos/ in the allowed-uris list for ofborg's build?
<gchristensen>
then hydra could be built by ofborg
<gchristensen>
(it would not allow this for nixpkgs)
<samueldr>
could this be a queryable builder setting, that when a build is queued, it knows to ask "I need to be able to read $thing", this allows you to put things like github.com/grahamc (whoever that fella is) in your builders, and ofborg would queue only to those?
<samueldr>
(maybe hard to implement?)
<gchristensen>
that would be cool
<gchristensen>
so then builders could opt-in to that sort of thing
<samueldr>
though having a builder allowing e.g. github.com/grahamc shouldn't make all builds able to use it
<gchristensen>
right
<gchristensen>
I think I can do a thing with topic queues and wildcards
<samueldr>
builders are self-organizing and just pick whatever's on top of the queues they subscribe to?
<samueldr>
sorry, this sounds like a question, but it's more I'm not 100% confident if the description is a good one
<gchristensen>
right, at the moment that is how they work
<gchristensen>
no support for even required system features like KVM :)
<LnL>
gchristensen: what do you mean by that exactly, the hydra repo?
<gchristensen>
so ofborg could be CI for Hydra
<LnL>
don't see why it would need that
<LnL>
problem is that github.com/NixOS is basically the same as github.com because of prs
<gchristensen>
it has to fetch nixpkgs
<gchristensen>
right now, builds can't fetch nixpkgs
<gchristensen>
ah hrm that is true
<LnL>
given that I think the way hydra inputs work might be better
<gchristensen>
yeah. right.
<gchristensen>
a bit annoying....
gchristensen has left #nixos-borg ["WeeChat 2.2"]
gchristensen has joined #nixos-borg
<gchristensen>
though it would still require either a trusted reviewer, or a trusted author
<gchristensen>
so a sketchy source URL like a PR would require a trusted user approving it
<LnL>
yeah, disadvantage is that you get duplication or even mismatches
<gchristensen>
going back to your point about basically th same b/c of PRs, we'd have the same security there as we do for building PRs on nixpkgs -- so maybe it is fine?
<LnL>
depends on who can trigger it
<gchristensen>
everybody in the known-user list
<gchristensen>
exactly as who can trigger builds on nixpkgs
<LnL>
might be fine, but all those people will be able to run arbitrary (linux) build then
<gchristensen>
true.
<gchristensen>
I guess it would be better to make that sandboxing strongerand just go all the way on that
orivej has joined #nixos-borg
<gchristensen>
coming back to a project with a ton of little scripts and no memory of how to use them ...
<gchristensen>
always a thing.
<MichaelRaskin>
Just imagine how you would write them from scratch, this might be a better approximation than you expect.
<gchristensen>
a good idea
<gchristensen>
I found the best few lines:
<gchristensen>
if [ -e ./result ]; then
<gchristensen>
echo "Not running nix-build ./vm.nix even though you might want me to."
<gchristensen>
nix-build ./vm.nix
<gchristensen>
else
<MichaelRaskin>
Writing the same code in the same way without remembering I already have this written. Twice.
<gchristensen>
nix-build ./vm.nix
<gchristensen>
fi
<MichaelRaskin>
Misleading messages 101
<LnL>
lol
<gchristensen>
+ ls /dev/fd
<gchristensen>
ls: cannot access '/dev/fd': No such file or directory