<timokau[m]>
Could we rebrand "No attempt" as a success? I think that would be more intuitive and would show a nice "all checks succeeded" checkmark on packages that are explicitly marked as broken on some platform.
<MichaelRaskin>
I think the problem is that right now there is no need to distinguish broken and other platform-specific evaluation errors
<timokau[m]>
What do you mean by that?
<MichaelRaskin>
Passing wrong parameters from the top level and getting an assertion failure
<MichaelRaskin>
(or having wrong defaults for a platform and getting an assertion failure)
<timokau[m]>
Oh you mean `No Attempt` doesn't always mean "explicitly disabled"?
<MichaelRaskin>
Yes
<MichaelRaskin>
Or at least not «intentionally disabled»
<timokau[m]>
The error message in the "intentionally disabled" case is pretty clear though, so a simple regex could fix that right?
<MichaelRaskin>
Probably, especially if we are OK with «dependency unsupported on a platform» indistinguishable from «package unsupported»
<timokau[m]>
Yes I'd say those two are equivalent
<timokau[m]>
What I want from ofBorg is to know "does this PR cause regressions", so as long as the package didn't build on a platform before the PR that's a success for me
<MichaelRaskin>
I think there were a few discussions about «did it even build before»
<timokau[m]>
Long-term I think we should have infrastructure that automatically marks broken builds as broken, but that'd be a big project. For now just setting "No Attempt" as a success would be a simple to implement quality of live improvement :)
<MichaelRaskin>
Long-term it would be nice to have an actual UI suitable to the task instead of GitHub with random weird limitations…
<MichaelRaskin>
speaking of regexes, a list of all lines «^builder for [-_./a-zA-Z0-9+]\+ failed» from the log would be nice…
<ekleog>
ofborg might, with appropriate development effort, start building the same package at master just before&after the merge and tag the differences, I guess
<MichaelRaskin>
Hm. I wonder if abusing fixed-output derivation semantics would allow to provide nix-build testing for ofborg. Accept credentials to a throaway GitHub account over a local network, create a repository, run tests.
<MichaelRaskin>
I am afraid to try writing any code for ofborg because I don't understand how to test it safely.
<LnL>
Is anybody else having trouble loading the logs?
<LnL>
Unhandled Promise Rejection: SyntaxError: The string did not match the expected pattern.
<samueldr>
arianvp: plausible, 3.3G left for /tmp, depending on whether other builds were happening at the time
<samueldr>
gchristensen: would it make sense to have only /tmp on that tmpfs, and keep user files (and var files) on the non-tmpfs-tmpishfs? especially considering the ofborg checkouts which are taking a good chunk off that space
jacereda has joined #nixos-borg
<jacereda>
Hi... Anyone knows what "This PR breaks listing of package outputs after merging." means?
jacereda has quit [Ping timeout: 245 seconds]
<samueldr>
that the PR breaks listing of package outputs, and this was verified after merging with master...
<samueldr>
there might be multiple causes
<samueldr>
it's basically doing a `nix-env -qa` IIRC