worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ https://discourse.nixos.org/t/nixos-20-09-release/9668 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 20.09 RMs: worldofpeace, jonringer | https://logs.nix.samueldr.com/nixos-dev
<supersandro2000> hexa-: also what did I want to do about ansible? Update to a new version? I forgot it already, again.
<supersandro2000> I created https://github.com/NixOS/nixpkgs/pull/118290 with all the easy updates and some prep already
<{^_^}> #118290 (by SuperSandro2000, 24 seconds ago, open): Ansible updates
<supersandro2000> and ansibe-lint update should be in staging
copumpkin has quit [Quit: Hmmm]
<supersandro2000> well, if nix wouldn't use flakes then I could try something 🤷
<supersandro2000> and downloading a none curl release version requires autoconf to generate configure but that is a depedency loop
copumpkin has joined #nixos-dev
<gchristensen> are the nixcon 2020 videos uploaded anywhere?
<supersandro2000> gchristensen: https://www.youtube.com/c/NixCon/videos
<gchristensen> just the one mega-live-stream
<supersandro2000> oh rc3 2020
orivej has joined #nixos-dev
ris has quit [Ping timeout: 240 seconds]
Sigyn has quit [Read error: Connection reset by peer]
Sigyn has joined #nixos-dev
evils has quit [Ping timeout: 252 seconds]
lukegb has quit [Quit: ~~lukegb out~~]
lukegb has joined #nixos-dev
mmlb has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
tomberek has quit [Ping timeout: 240 seconds]
AlwaysLivid has quit [Ping timeout: 240 seconds]
plumm has quit [Ping timeout: 240 seconds]
cjb has quit []
jonringer has quit [Ping timeout: 258 seconds]
plumm has joined #nixos-dev
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-dev
cole-h has quit [Ping timeout: 252 seconds]
rajivr has joined #nixos-dev
MichaelRaskin has quit [Ping timeout: 268 seconds]
FRidh has joined #nixos-dev
ris has joined #nixos-dev
<ris> is r-ryantm now targeting staging? #118086
<{^_^}> https://github.com/NixOS/nixpkgs/pull/118086 (by r-ryantm, 2 days ago, open): qpdf: 10.2.0 -> 10.3.1
MichaelRaskin has joined #nixos-dev
<sterni> ris: It does a rebuild check and chooses the target depending on that
<sterni> it determined 593 total rebuild path(s) so I guess the treshold is > 500
<sterni> you can change the target branch via the github UI easily though
<ris> i think it might have miscalculated the rebuilds
<ris> ofborg says <100
<ris> think i'll rebase it
<sterni> you don't need to
<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]
copumpkin has joined #nixos-dev
<supersandro2000> hexa-: not really tbh
<supersandro2000> and the package created by the tests works fine with the current nix-channel
<supersandro2000> but the rebuild one does not
<supersandro2000> I couldn't get it to ignore tests but I think something in the fetching code in nix broke
<supersandro2000> so I can't verify if the tests are bad or the binary but I think the later which would hold the channel
<hexa-> 16:38 <hexa-> it is peculiar, that it is a file:// url that times out
jonringer has joined #nixos-dev
FRidh has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
justanotheruser has joined #nixos-dev
<symphorien[m]> can I get some opinions on https://github.com/NixOS/nixpkgs/pull/115332 ? There is a conflict but I'd like some feedback before I solve it.
<{^_^}> #115332 (by symphorien, 3 weeks ago, open): nixos/users: require one of users.users.name.{isSystemUser,isNormalUser}
cole-h has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
__monty__ has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
mkaito has joined #nixos-dev
mkaito has quit [Quit: WeeChat 3.1]
orivej has joined #nixos-dev
andi- has quit [Ping timeout: 268 seconds]
andi- has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 240 seconds]
pmy_ has quit [Ping timeout: 240 seconds]
copumpkin is now known as sassafras
sassafras is now known as copumpkin
pmy has joined #nixos-dev
<sterni> why can I execute pkgsCross.armv7l-hf-multiplatform.pkgsHostTarget.stdenv.cc on x86_64-linux?
<sterni> like shouldn't that be a compiler that runs on armv7l and produces binaries for armv7l?
<samueldr> sterni: because `stdenv.cc` is the cc used for compiling
<samueldr> and you're asking for a stdenv that compiles on x86_64-linux
<sterni> oh wait do I need to use targetPackages
<samueldr> (I think)
<samueldr> I'm not sure, it's not exactly always all clear to me :)
<samueldr> it hasn't clicked yet for me
<sterni> so stdenv is always BuildHost probably
cole-h has quit [Ping timeout: 260 seconds]
<{^_^}> #118147 (by peterhoeg, 2 days ago, merged): zigbee2mqtt: 1.16.2 -> 1.18.2
<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?
<sterni> > builtins.valueSize pkgs.zigbee2mqtt / 1024 / 1024
<{^_^}> 5
<sterni> > (1.0 * builtins.valueSize pkgs.zigbee2mqtt) / 1024 / 1024
<{^_^}> 5.39334
<sterni> may be a coincidence though
<sterni> i don't know honestly
<hexa-> sterni: there was a bash script in there accounting for ~150k LoC
<sterni> uh oh
<gchristensen> https://github.com/NixOS/nixpkgs/commit/574c4a7468cc4d3621a62378ece6959a8b51a4bf I really wish we could just flip the switch and block direct pushes
zowoq[m] has joined #nixos-dev
jonringer has quit [Remote host closed the connection]
zowoq[m] has left #nixos-dev [#nixos-dev]
<lassulus> couldn't we just poll everyone and just flip it if most people agree?
<lassulus> or is a rfc the right way?
<sterni> I think there is not enough consensus for that atm
<{^_^}> rfcs#79 (by dasJ, 23 weeks ago, closed): [RFC 0079] No more direct pushes to master and release branches
<lassulus> I had the feeling there was one already :D
<samueldr> it's not a situation of being able to "flip" it, but a situation where it breaks workflows for people still going through the PR dance
<samueldr> IIRC some kind of merges become impossible
<samueldr> then cherry-picking to stable will become arduous enough that some individuals stated they just won't do it
<lassulus> so we have it on for technical reasons but as a community we decided to "don't do it unless not possible otherwise" ?
<sterni> I mean the github PR workflow is a bit convoluted
<sterni> just today I did a one word typo fix in docs on master
<sterni> and I was briefly considering if I should open a PR
<domenkozar[m]> you can use github edit button for that
<domenkozar[m]> I find it pretty sweet
<samueldr> lassulus: mostly yes
<samueldr> (organically grown community direction)
<domenkozar[m]> it's also reasonable to expect that removing power will yield resistance
<domenkozar[m]> but we're really at the point where we need to push through the next phase
<MichaelRaskin> Need towards what end?
<domenkozar[m]> there's been almost 200 commits just today
<domenkozar[m]> the fact that anything works is a miracle to me
<MichaelRaskin> Well, the curse and the blessing come together here
<MichaelRaskin> What is the number of commits this week affecting a single package?
<sterni> domenkozar[m]: I guess the appeal of pushing to master directly is mostly not using the github ui :p
<MichaelRaskin> If we could have «merge after checks pass», one could at least use this mess only once per PR and not twice
<domenkozar[m]> github supports that
<MichaelRaskin> (given that checks are the only useful thing in PRs for most commits)
<sterni> I think one major hindrance for a PR policy is the state of the eval check
<domenkozar[m]> that it can take time?
<sterni> that is not really avoidable
<sterni> mostly the problem is that eval fails when eval fails on master
<sterni> which means that CI is read for PRs that fix evaluation errors
<MichaelRaskin> domenkozar[m]: I do care what _GitHub_ supports. If it is not enabled, it is not there.
<domenkozar[m]> I don't understand, it is enabled if checks are required
<domenkozar[m]> then the dropdown for merge button includes "merge once checks pass"
<MichaelRaskin> Can we have it enabled without hard-requiring build checks to pass?
<domenkozar[m]> Nope
<domenkozar[m]> but we want to require those?
<MichaelRaskin> Nope
<domenkozar[m]> why not?
<MichaelRaskin> I do not want Chromium build timeout to be passing
<MichaelRaskin> I also do not want the entire workflow to be messed up for Chromium when Google invents a way to make the build even more expensive
<domenkozar[m]> oh not build checks, evals checks, etc
<samueldr> auto merge after tests pass button is a feature of refined github, no?
<MichaelRaskin> Does that thing appear once we make at least one of the checks required?
<samueldr> a browser-side extension
<domenkozar[m]> samueldr: no, that's just github
<domenkozar[m]> MichaelRaskin: exactly
<MichaelRaskin> But I cannot then ask it to merge only if _build_ checks also pass, right?
<domenkozar[m]> it will be merged after required checks pass
<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> sure
<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]> gh pr create --title "Pull request title" --body "Pull request body"
<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]
plumm has quit [Quit: Textual IRC Client: www.textualapp.com]
srk has quit [Ping timeout: 240 seconds]
srk has joined #nixos-dev
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev