<gchristensen>
niche use case, but is there a way to use remote builders but not xfer the result back? :)
<vcunat>
gchristensen: do you know --build-host and --target-host in nixos-rebuild?
<gchristensen>
I don't...
<gchristensen>
but I think I should
<vcunat>
> So, if you only specify --target-host both building and activation will take place remotely (and no build artifacts will be copied to the local machine).
<gchristensen>
:D
<vcunat>
IIRC it's a relatively new feature
<yegortimoshenko>
gchristensen: it would be less work to add a new platform in the future if at least one evaluation had `platform = "unknown"` or something to the same effect
<gchristensen>
yegortimoshenko: if you check out my "fix" commit, it already makes adding new platforms fairly easy enough, because we can fully evaluate the package on an arch even if it doesn't support it
<vcunat>
hmm, I'm not sure if we wouldn't get problems in stdenv already
<yegortimoshenko>
vcunat: i see, but still currently to make grahamcofborg tests pass one can just make sure that their derivation evaluates on all supportedPlatforms
<yegortimoshenko>
that makes adding a new platform to supportedPlatforms difficult
<vcunat>
yes
<vcunat>
we could evaluate on more of them
<yegortimoshenko>
solution is to ensure that grahamcofborg evaluates derivation at least once with invalid platform
<yegortimoshenko>
like "unknown", or "undefined"
<vcunat>
yes, that should be cheaper
<yegortimoshenko>
or "grahamcofborg-linux"
<vcunat>
except if stdenv doesn't evaluate, you won't even get meta
<vcunat>
or anything inside mkDerivation
<vcunat>
(thanks to laziness)
<vcunat>
so we would probably have to introduce such dummy stdenv... but that might actually have other uses - for platform-neutral stuff, e.g. typically meta
<yegortimoshenko>
vcunat: i think it's worthwile, i'll try
<yegortimoshenko>
(to evaluate, and then i'll open an issue)
<vcunat>
+1
yegortimoshenko has quit [(Remote host closed the connection)]
yegortimoshenko has joined joined #nixos-dev
<Profpatsch>
pierron_: lol, I discovered the splitString function, saw the note “NOTE: this function is not performant and should never be used.” and instantly knew it’s something you wrote and use in your parser abomination. :)
<Profpatsch>
The blame “checks out” :P
<pierron_>
Profpatsch: I don't think I used it in the parser.
<pierron_>
Profpatsch: but the Nix builtin I added can be used to make splitString more efficient
pie_ has quit [(Remote host closed the connection)]
<pierron_>
Profpatsch: the TOML file type did not exist at this time ;)
<vcunat>
guessed almost correctly :-)
<Profpatsch>
pierron_: When I look at the code: is that n² or n³? oO
<pierron_>
Profpatsch: substring are cheap, as they are implemented as dependent strings. However the string comparison does not work on atomized strings, and is as complex as the matched pattern.
<pierron_>
Profpatsch: so O(np), if strings were the only perf issue.
<pierron_>
Profpatsch: and O(r²) for constructing the output list.
<Profpatsch>
Okay; then it may be enough for a quick hack.
<Profpatsch>
Or I just fix the generator.
orivej has joined joined #nixos-dev
<pierron_>
Profpatsch: maybe adding regexSplit would be better.
pie_ has quit [(Ping timeout: 256 seconds)]
simpson has joined joined #nixos-dev
pie_ has joined joined #nixos-dev
Sonarpulse has joined joined #nixos-dev
<yegortimoshenko>
how do i evaluate something eagerly?
<gchristensen>
--strict
<yegortimoshenko>
gchristensen: thanks!
<yegortimoshenko>
gchristensen: does grahamcofborg have an issue tracker or should i file an issue against nixpkgs?
<gchristensen>
grahamc/ofborg :)
<yegortimoshenko>
:-)
<Sonarpulse>
vcunat: master should be merged back into staging, right?
<vcunat>
Sonarpulse: it could be
<vcunat>
is it important?
<Sonarpulse>
vcunat: or did you merge master into staging before the merge of staging into master?
<Sonarpulse>
ah yes, nevermind then
<vcunat>
I don't think I did that
<vcunat>
last merge I see is ~24h ago
<Sonarpulse>
vcunat: ah orivej did
<Sonarpulse>
well as long as it happens
<vcunat>
yes, 7c58e8dfc2b
<Sonarpulse>
vcunat: I'm trying to decide if it even matters whether theres one commit that master and staging both pointed to at some point
<vcunat>
I don't know any advantage of that
<Sonarpulse>
in principle, the refog doesn't matter after the fact wrt computing the most recent common ancester
<Sonarpulse>
OTOH, I just rebased my big cross pr on your staging merge
<vcunat>
and you avoid the risk of a fast-forward merge :-)
<Sonarpulse>
both so its up to date with mater
<Sonarpulse>
*master
<Sonarpulse>
and so I can build it and compare against the master eval, as a kind of no good state
<Sonarpulse>
*known good
* Sonarpulse
cannot type today it seems
<vcunat>
:-) I sometimes merge master exact versions that were evaluated by Hydra to staging, to simplify the comparisons
<Sonarpulse>
vcunat: right so I think if master evals that exact merge commit
<Sonarpulse>
then we *should* do the fast-forward merge
<Sonarpulse>
then ideally we have a single commit in both master and staging that both jobs evaled
<vcunat>
Sonarpulse: the problem is that you swap the first-parent history semantics
<vcunat>
I find that one useful
<Sonarpulse>
vcunat: that's a fair ergonomic
<Sonarpulse>
*argument
<Sonarpulse>
vcunat: maybe immediate --no-ff merge master into staging
<Sonarpulse>
so at least the same tree hash was evaled by both jobs
<Sonarpulse>
but the first parent property is still preserved
<vcunat>
yes
<vcunat>
I use --no-ff this way for some PRs, too
<Sonarpulse>
vcunat: cool, that might be a good policy then
<Sonarpulse>
I just had to make the merge, so my PR to staging didn't show up with extra commits
<vcunat>
yes, that happens :-)
goibhniu has quit [(Ping timeout: 255 seconds)]
<copumpkin>
niksnut: any idea if the warning message thing is enough to disqualify it from being a "bugfix" release? :) I'm mostly trying to get stable mac builds of that thing for downstream usage, but if you think it's too risky, I'll lay off
<copumpkin>
but when I think gnutar, I don't really think of crazy risky features getting added in small releases
<gchristensen>
copumpkin: is there a bug-fix patch we can apply to stable?
<copumpkin>
yeah, I suppose. It just seemed easier to bump to 1.30, which includes the bug fix, gets rid of another ad-hoc patch we threw in for a CVE, and fixes a couple of other bugs. It also adds one warning thing, but that seemed pretty harmless to me
__Sander__ has quit [(Quit: Konversation terminated!)]
<Sonarpulse>
gchristensen: is grahamcofborg no longer auto?
<niksnut>
copumpkin: I'm not strongly opposed but I'd prefer putting it in staging-17.09 so it can be folded into other mass-rebuild changes
<niksnut>
otherwise inflicting a full rebuild/redownload on everybody seems a bit excessive
<copumpkin>
hah I initially submitted it to staging-17.09 but folks told me that didn't work
<niksnut>
why not?
<copumpkin>
so I repointed the PR to release-17.09
<copumpkin>
not sure!
<copumpkin>
anyway, I can send it anyhwere
<Sonarpulse>
gchristensen: thanks!
<vcunat>
niksnut: the telling was that the Hydra job was disabled
<vcunat>
(mass rebuilds for 17.09 seem rather rare after the release point anyway)
<copumpkin>
how do we feel about mass darwin rebuilds on 17.09? when I backport the sandbox things to 17.09 I'll also need to cause some mass rebuilds there
<gchristensen>
Sonarpulse: looks like staging doesn't eval, maybe merge master in
<copumpkin>
niksnut: so I can point the PR back at staging-17.09 but I think the job would need to be reactivated, and the branch probably needs a merge from release-17.09 because it seems kinda forgotten
yegortimoshenko has quit [(Ping timeout: 248 seconds)]
orivej has quit [(Read error: Connection reset by peer)]
ma27 has quit [(Ping timeout: 240 seconds)]
orivej has joined joined #nixos-dev
<gchristensen>
Sonarpulse: whatever you merged to staging wasn't the latest master P
<gchristensen>
:P
<vcunat>
copumpkin: I don't expect 17.09 makes much difference between darwin and linux wrt. mass rebuilds
<vcunat>
except that Hydra is weaker for darwin, but I don't think that's a major difference
<vcunat>
(it only slows the process down)
<copumpkin>
yeah, I guess I'm just saying that if we want mass rebuilds to go to staging for 17.09, I'll need staging-17.09 turned back on because I'll be making a few mass rebuilds for darwin
<gchristensen>
iirc you can trigger a one-off eval for a disabled jobset
<copumpkin>
even if we ignore the whole gnutar thing
ma27 has joined joined #nixos-dev
<copumpkin>
ah
orivej_ has joined joined #nixos-dev
orivej has quit [(Ping timeout: 255 seconds)]
<Sonarpulse>
gchristensen: oh I know
<gchristensen>
oh ok
<Sonarpulse>
it was the commit of staging being merged into mastr
<Sonarpulse>
talking to vcunat above it would be convenient to have a new rule that we always did: