<sterni>
you can just change the target in the github UI
<sterni>
it's pr'd against a common parent commit of both master and staging
<sterni>
forgot the correct term again
<ris>
ok will try that
<ris>
that's some smart thinking if it does that deliberately. looks like it worked.
<maralorn>
Sooo … I am wondering. How much trust does one need to earn to get hydra job-restart rights? Is there a semi-welldefined policy for it?
<maralorn>
Because for us Haskell maintainers only peti has it and he has a functioning work-life-balance …
<sterni>
ris: 2021-03-22 23:17:34 ryantm sterni: r-ryantm's PRs are committed against a merge base of staging and master, so you should be able to retarget them by clicking edit at the top of the PR and changing the target branch.
<FRidh>
maralorn: I triggered an eval for you.
<ris>
nice
<maralorn>
FRidh: That’s nice. thank you.
<FRidh>
ris: sterni: normally, 500+ should target staging. With r-ryantm a lower threshold was set, because of the higher amount of PR's
<maralorn>
Although it wasn‘t very urgent now. It was more of a general question.
<FRidh>
maralorn: I think you best ask this to peti or gchristensen. No policy here as far as I know
<ris>
FRidh: interesting. the only downside is it makes it harder to review. in this case it does look like it miscalculated because there are under 50 rebuilds according to ofborg
<FRidh>
Right, its a trade-off. Staging is always inconvenient, though if you're lucky there is a stdenv at least ready.
FRidh has quit [Quit: Konversation terminated!]
<aminechikhaoui>
If someone incorrectly re-installed nix after just removing /nix/store, would nix verify --all be enough to get the state up to date ?
justanotheruser has quit [Ping timeout: 250 seconds]
<hexa->
supersandro2000: something with curl.h? do you have seen something concrete?
orivej has joined #nixos-dev
evils has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
copumpkin has quit [Read error: Connection reset by peer]
<supersandro2000>
previously the zigbee2mqtt update caused a stack overflow which is no longer reproducible. Hopefully it is fixed. If not please do a revert.
<gchristensen>
whew interesting
<hexa->
which is weird, because the derivation is now 100kb bigger
<sterni>
derivation file size is not that relevant
<sterni>
the stack overflow is most likely caused by thunks accumulating
<sterni>
and uneveluated thunks reserve a lot more size than their actual value very often ime
<sterni>
i. e. when you accumulate a lot of data in nix it can be a good idea to builtins.seq or even deepSeq it at every step to limit the stack size
<hexa->
thunks?
<supersandro2000>
chunks?
<symphorien[m]>
a sort of placeholder for still-not-evaluated values in lazy languages
<hexa->
he said thunks multiple times :)
<hexa->
ok
<sterni>
> builtins.valueSize pkgs.zigbee2mqtt
<{^_^}>
5655332
<samueldr>
>> The term originated as a humorous, incorrect, past participle of "think". That is, a "thunk value" becomes available after its calculation routine is thought through, or executed
<sterni>
hexa-: how big where you saying the drv file was?
<domenkozar[m]>
If you enable auto-merge for a pull request, the pull request will merge automatically when all required reviews are met and status checks have passed. Auto-merge prevents you from waiting around for requirements to be met, so you can move on to other tasks.
<MichaelRaskin>
We kind of have multiple classes of PRs
<MichaelRaskin>
What you describe is much more single-class
<domenkozar[m]>
this is opt-in per PR
<domenkozar[m]>
so those that don't fit, can't use this optimization
<domenkozar[m]>
sterni: oh there's also way to create prs from cli if you want to avoid web ui
<sterni>
still extra steps involved where I can somewhat relate that it is annoying
<domenkozar[m]>
oh there's no denying it's annoying
<MichaelRaskin>
Wait, auto-merge is only for requirement threshold which is the minimal threshold absolutely enforced for all PRs, tight?
__monty__ has quit [Quit: leaving]
<sterni>
in the end I think if some questions regarding PR workflow are answered we can forbid it sufficiently well and I think ppl will eventually adjust to the brave new world
<sterni>
(maybe one could write a post commit hook that translates pushes to release branches into PRs lol)
<domenkozar[m]>
it's like with clothes
<domenkozar[m]>
when you're at home you can be naked
<domenkozar[m]>
when you go to the public, it's gets annyoing and you have to dress up :D
<MichaelRaskin>
Although at many places some people are pretty succesful at reducing the enforceable amounts of dressing up
<ekleog>
sterni: I'd be afraid of forcing backporting to release branches to go through PRs, at least until we have a button on github that automatically cherry-picks a merged PR into a release branch PR
<ekleog>
(people are already not caring enough about backporting, so making the process even harder is not going to be god for stable)
<ekleog>
good*
<domenkozar[m]>
ekleog: we could have a script for that
<domenkozar[m]>
that could be filled in via the cherry-pick
<domenkozar[m]>
at least the process is documented and automated
<domenkozar[m]>
we could then even make a github actions bot that does this
andi- has quit [Ping timeout: 258 seconds]
<domenkozar[m]>
like comment on a commit: @cherrypick release-20.09
<domenkozar[m]>
there's so much that could be built if we really embraced what github offers :)
<domenkozar[m]>
g2g
<MichaelRaskin>
Or if someone was bold enough to add merge capabilities to OfBorg
<samueldr>
MichaelRaskin: nice to hear you volunteering for the task!
andi- has joined #nixos-dev
<MichaelRaskin>
If I do it, it will only work with Monotone…
<ekleog>
I feel like this point comes back literally every few weeks, but: in this discussion, has bors been considered? I'm thinking it might be easier to add the merge feature to bors/homu than to ofborg, which currently isn't designed for that
<ekleog>
well, to add the backport feature* (the merge feature already being there)
<ekleog>
(note that here I'm not even suggesting using bors to run tests, though it could definitely happen too, only suggesting using bors to handle the merge itself — bors would also solve the “auto-merge-after-tests” issue if we wanted it to, but it would require first agreeing on a set of obviously wanted tests)
<MichaelRaskin>
Hm, is there any auto-merge that can be instructed to auto-merge based on a specified set of checks?
<ekleog>
I'm not sure bors/homu are able to run a set of checks that would be specified on the merge line yet, though that'd be awesome (@bors r+ if-still-works="nix-build . -A coreutils")
<MichaelRaskin>
That's surely too much
<ekleog>
if the set of checks is static and not dependent on the PR itself, then yes bors is able to do it
<MichaelRaskin>
I just mean the checks we already have, something like «build.x86_64-linux»
<ekleog>
(it also automatically does rollup to test multiple PRs at once for slow-to-run tests, and automatically bisects when a rollup fails to indentify the problematic PR)
<MichaelRaskin>
You mean checks can be chosen per-PR ?
<ekleog>
I don't think checks can be chosen per-PR, no; if the checks are the same for all PRs then bors can
<MichaelRaskin>
Ah
<ekleog>
(and it _might_ be possible to patch bors to support per-PR checks, though I'm not 100% sure about that as I haven't looked much into it)
<MichaelRaskin>
I meant something like «this must build on aarch64, that can get a gray there»
FRidh has quit [Quit: Konversation terminated!]
<ekleog>
actually it looks like it's just pushing to a branch and then looking at the github status, so it can probably be done by having our own github status that does the thing we want, though it might be hard to make it configurable in the acceptance message
<MichaelRaskin>
Yeah
<MichaelRaskin>
Yay, we have got to the stage where we have conflicting sources of build checks for a single PR…
<ekleog>
actually that'd combine pretty awesomely with ofborg if we can get ofborg to CI bors' staging branch: bors would ensure that master always passes ofborg checks, and ofborg would check eval for continued working and the like
<lovesegfault>
heelo
<lovesegfault>
I, too, want bors
<MichaelRaskin>
I am in favour of enabling more or less whatever that makes merging fresh PRs less of a dance
<ekleog>
I wonder, quick show of hands: who would be in favor/against/wouldn't care about an RFC 1. preventing direct pushes to master (not yet release branches), 2. preventing direct merges to master, 3. integrating bors with, as only check, ofborg's eval check? (and then as future work making it easy to backport straight from the `@bors r+` and possibly integrating more tests if/when we feel ready
<ekleog>
about it)
<lovesegfault>
in favor of all
<MichaelRaskin>
opposed
<MichaelRaskin>
Is it possible to enable bors merges without making them the only way?
<lovesegfault>
I believe so
<MichaelRaskin>
I am generally in favour of enabling some automation and only making it mandatory when enough people have seen its behaviour and consider it understandable
<ekleog>
good idea indeed, thank you :)
<ekleog>
gchristensen: semi-related to the above discussion, but possible to answer without context: as you changed hydra quite a bit recently, how hard do you think it would be to make hydra add github statuses to the commits it builds, succeeding if the channel moves forward and errorring out if it doesn't?
cjb has joined #nixos-dev
jonringer has joined #nixos-dev
cjb has quit [Read error: Connection reset by peer]
cjb has joined #nixos-dev
justanotheruser has quit [Ping timeout: 246 seconds]