<julm>
as of me, I hate with a passion closed-source/for-profits infrastructures like Github's, especially when we have such a mature free/open source software infrastructure like Redmine/Trac/Gitlab/public-inbox/<you-name-it>. I don't know well what would be the costs to who of moving, nor if an alternative way of contributing can easily be set up and maintained in parallel? So for now I hold my nose and force
<julm>
myself to use/learn Github to be able to contribute to Nixpkgs and join you all :] Even though personnally I'd be more comfortable, able to search/follow/contribute offline, and somehow more in trust/control, with a git send-email workflow as organized/tested/improved in communities like Linux's or Git's
<edef>
yeah, we have a bunch of git-by-email enthusiasts here, me included
<edef>
and qyliss has been working on an excellent NixOS module for public-inbox
<edef>
(which has even caused a few upstream patches!)
<MichaelRaskin>
Last when I checked Redmine it was an issue tracker with no issue integration (but it is the best issue tracker I have ever used). But an issue tracker that is actually usable might be a disruption with unpredictable effects
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
tilpner has joined #nixos-dev
<ekleog>
commented, there's just the question of where the source is fetched from that arose when doing the sanity-check :)
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
<gchristensen>
Mic92: I'm very concerned about the side effects of using github actions :(
orivej has quit [Quit: No Ping reply in 180 seconds.]
<gchristensen>
we don't want to go back to what travis did to us
orivej has joined #nixos-dev
<gchristensen>
maybe all the evaluations could be moved in to github actions
<abathur>
gchristensen: what
<abathur>
erg
<abathur>
what'd travis do, if there's a short answer?
<gchristensen>
Travis gave out so few green checkmarks, that if Travis gave a PR a green check-mark, it inspired more "okay what is broken that let travis pass it?" than "okay good to merge"
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
<abathur>
ah, so ~run-consistency problems I guess
<gchristensen>
no, it was just too slow and nixpkgs too big that we would consistently be over limits
<abathur>
oh gotcha
<gchristensen>
anyway, ever since then with ofborg the "rule" has been green checkmark -> good to merge
<gchristensen>
red X -> don't merge
alp has quit [Remote host closed the connection]
<gchristensen>
there is a PR adding a github action which will build the manual with github actions, which I'm afraid will do the same thing as travis
<gchristensen>
additionally, there is a github action already which gives a very early green check, sometimes before ofborg has a chance to say it is pending
<gchristensen>
so this errodes the rule on both sides: a red X might mean merge
alp has joined #nixos-dev
<gchristensen>
a green check might not mean merge
<abathur>
it's good to make sure that the green check at least never lies
<abathur>
what action gives the early check?
<gchristensen>
the green check's clarity of signal is already erroded.
<gchristensen>
the github action to do the editorconfig check
<gchristensen>
I would like to remove the editorconfig check for that reason, until we can find a way to not errode the clearness of the green check signal
<gchristensen>
and again, the one that builds feels even more dangerous because that makes the signal even less clear
<abathur>
how is it getting to done before ofborg can say it's pending; is it more about latency and being on GH infra, or time to start an ofborg instance?
<LnL>
what if something goes wrong before reporting pending?
<abathur>
(I'm naively, having not taken the time to explore GH actions yet, wondering if you could have a GH action that basically just polls the ofborg status?)
<LnL>
(not a theoretical problem, this happened today)
<LnL>
yeah I also thought about that
<LnL>
but after thinking some more about it I don't think it's a good idea to depend on multiple things for checks
<LnL>
more infrastructure, that can interact with each other in unexpected ways
<Mic92>
gchristensen: Do you see a way how we could make adding new checks to ofborg easier?
<gchristensen>
I can imagine a few ways, yes, but I can't really get in to it today :(
<LnL>
I would say definitively
<LnL>
if only we had something to express unit of work in a nice way
<gchristensen>
LnL: lol
<gchristensen>
and btw I'm seriously not doing this from a perspective of "don't threaten my project". maintaining ofborg isn't really something I cherish my time on :P (I say, cleaning up a weird thing that happened by mistake)
<LnL>
yeah, moving everything to actions is an option
<LnL>
alltho I'm not sure that's trivial with how memory hungry evaluations are currently
<gchristensen>
right
<Mic92>
LnL: I work on reducing memory in nix-review by splitting up evaluations into smaller chunks
<Mic92>
It is slower but requires less memory
<Mic92>
Maybe I should also look into nix flakes evaluation cache, than it might be not that much slower
<gchristensen>
that would probably be an inappropriate use of flakes right now
<Mic92>
Yeah. That would require a check if flakes are enabled.
<ekleog>
gchristensen: if I may, the “green checkmark -> good to merge” rule is already eroded by github considering a “gray circle” reported by ofborg to be compatible with a green checkmark -- I've seen evaluation failures being hidden inside the green checkmark, and nowadays always open the green checkmark drawer to make sure the relevant derivations were indeed green and not gray (and also
<ekleog>
that they were run at all, as a successful evaluation without building also reports as green checkmark)
<gchristensen>
ekleog: that is literalyl on purpose
<gchristensen>
any gray circles are there on purpose to say "not great, but the confidence ofthis check isn't sufficient to block"
<gchristensen>
any checks which could possibly give a misleading red X was made to be a gray circle on failure
<ekleog>
Hmm… but then “green checkmark -> good to merge” is already not a rule, is it? (I'd be advocating more for a third “we don't know” status that I guess github doesn't provide us, but I'm more thinking along the lines of “having another too early checkmark isn't that bad an issue” right now)
<gchristensen>
yes it is
<gchristensen>
sorry, this is not a good time to meta-discuss it
<gchristensen>
for me, that is. if you want to have that discussion, by all means -- but I can't do it
drakonis has joined #nixos-dev
<gchristensen>
and it IS a bad issue, right now.
drakonis_ has quit [Ping timeout: 260 seconds]
<zimbatm>
gchristensen: let's revert then
<ekleog>
Well, all I can say is I don't feel confident merging a green checkmark after mere code review without first opening the checks drawer and checking that all the inner checkmarks are green, and investigating why those that aren't aren't -- so at least for me that rule hasn't worked since the day I noticed I was about to merge something that just didn't evaluate due to some unfree thing. That
<ekleog>
being said I definitely don't want to divert the subject, so I'll stop there :)
<gchristensen>
zimbatm: if you could, that would be really helpful
<gchristensen>
zimbatm: this topic always stresses me out so much, because of how hard I work to keep master green. it is so easy to add a github actions which is a good thing in principle, but is a bad thing in regards to the over all health of the project, and the trade-offs with adding that required check leave me stuck between many rocks and hard places, and a feeling that people don't respect or
<gchristensen>
understand the care I've taken
<Mic92>
zimbatm: I prepare something
<gchristensen>
^ I'm not saying that these things I say are true. I know it isn't generally true. it is just how I feel when these discussions happen
<gchristensen>
in circumstances liek today
justanotheruser has quit [Ping timeout: 252 seconds]
<zimbatm>
gchristensen: what's preventing us from enabling the branch protection?
<zimbatm>
Mic92: ok, ping me when it's ready if you want a review
<gchristensen>
zimbatm: look backwards in logs to the chat where I said this: 23:13 <gchristensen> colemickens: there is a somewhat unspoken subtext to this conversation around morals and depending on Microsoft/GitHub/non-foss software for a foss project. a perspective I deeply appreciate every time I can't fix an annoyance or problem, but also appreciate on the moral level.
<gchristensen>
and 23:15 <gchristensen> some people hold their nose and contribute in ways they feel okay about (thank you) and upsetting that workflow is upsetting on more than just a "but my control-key-heater workflow" level
<zimbatm>
I don't think that fear and doubt is a good way to take decisions
<gchristensen>
I don't think that is what is happening?
<gchristensen>
I actually do want to talk to you about this. could we do it tonight?
<gchristensen>
thank you a lot for going ahead with the revert, zimbatm Mic92
orivej has quit [Ping timeout: 246 seconds]
orivej_ has joined #nixos-dev
<zimbatm>
yeah, let's talk about it. I haven't followed the whole discussion.
<Mic92>
me neither
<zimbatm>
ping me when you are free
<gchristensen>
cool, we can talk about it together. thank you a lot
<gchristensen>
it sucks that I can't do it now. I want to do it now :(
<zimbatm>
well, there is a thing called work
<gchristensen>
so, so, so much of it, too
<zimbatm>
IMO we should stop being shy and enable the branch protections, force everything through ofborg
<gchristensen>
oh no, please, please wait for later :P
<edef>
but doesn't seem particularly urgent — it just showed up today because we were merging new nixpkgs into their tree, and your commit showed up in the merge conflict
<edef>
not sure what the consensus is like on replacing packages in that fashion — we still have rxvt and rxvt-unicode, for example
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
alp has quit [Remote host closed the connection]
<Mic92>
edef: is rxvt still maintained?
<edef>
no idea
<Mic92>
I would say nvi is not really high demand so we want to minimize the maintainance.
<Mic92>
Otherwise someone would had already fixed.
alp has joined #nixos-dev
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
<{^_^}>
ocaml/opam-depext#116 (by deliciouslytyped, 1 year ago, closed): Unnecessary request for escalation of privileges
<pie_>
actually - not sure why i thought you use ocaml
Jackneill has joined #nixos-dev
<ajs124>
drakonis1: true. but assuming we won't switch to anything else any time soon, even given all the discussions and available alternatives, it might still be worth trying out.
<drakonis1>
i believe it might be worth a try
<drakonis1>
but i dont want to become married to github
Cale has quit [Ping timeout: 256 seconds]
<emily>
we are already far more tied to github than one web app would make us
<emily>
ofborg uses the github api extensively
<LnL>
only on the reporting side, everything else is internal or webhooks
Cale has joined #nixos-dev
<emily>
isn't "issue/PR triage" in the same kind of category as "CI checks we rely on"? i.e., part of the developer-side workflow for dealing with stuff that's already locked in to GitHub
<drakonis1>
well, if we moved to something else
<drakonis1>
we could have ofborg use the apis
<drakonis1>
or write something that can do even grander things
Cale has quit [Ping timeout: 260 seconds]
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
<emily>
sure, I just don't think "having an app for people to help with triage" adds significantly more lock-in
<emily>
speaking of ofborg... is it having issue?
<emily>
s
<emily>
doesn't seem to have noticed any PRs for hours
<gchristensen>
cc cole-h
<cole-h>
Probably because we're still catching up on the queue after the oopsie earlier
<cole-h>
24 pending jobs vs 3 evaluators
<gchristensen>
cole-h: want to PR a change to ofborg's infra changing the 3 evaluators to 6?
<emily>
this does mean that all PRs currently have misleading green ticks
<cole-h>
Assuming it's just copy-paste of the other ones, sure.
<emily>
maybe ofborg should put up a "pending" check on all PRs before they even get evaluated?
<cole-h>
Yeah, we were talking about this yesterday/last night
<emily>
I guess it doesn't have the CI-specific tick, but the overall merge one is there
<cole-h>
Even with these additional evaluators, if the pace stays constant, it'll still take ~an hour to catch up (as opposed to 2 hours with just 3 evaluators).
<cole-h>
LnL: see above comment
<LnL>
ah
<LnL>
let's do it then, scaling back down isn't a problem right?
<cole-h>
Should be just removing those lines/reverting that commit, I'd assume.
<cole-h>
LnL: lol, we both started deploys. Cancelled mine, you go for it.
<samueldr>
nope, I don't even know where the bug is
<clever>
samueldr: i suspect its related to memory barriers and the gc library
<clever>
and you have to read assembly to even confirm where the issue is!
dongcarl has joined #nixos-dev
<julm>
strangely, `nix build foo`, defaults to construct the installation source from $NIX_PATH, not the current directory like `nix build`. So one has to use `nix build -f . foo`
<clever>
but its also not deterministic, and even building the same nix src, results in the bug going away...
orivej has quit [Quit: No Ping reply in 180 seconds.]
<{^_^}>
nix#3609 (by cleverca22, 31 seconds ago, open): fix segfault and type changing weirdness caused by use-after-free bugs, caused by lack of GC roots
<clever>
niksnut: cc ^^
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
<{^_^}>
nix#3212 (by LnL7, 28 weeks ago, open): install: configure and bootstrap synthetic.conf on darwin
<matthewbauer>
I'm hoping we can have an official answer soon to the question of "how do I install nix on macOS"
<matthewbauer>
Right now it's unclear what the safe way to do this is
<LnL>
yeah it's good to go now
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
cole-h has joined #nixos-dev
globin has quit [Changing host]
globin has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
cole-h_ has joined #nixos-dev
orivej has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
cole-h_ has quit [Client Quit]
cole-h has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
evils has quit [Quit: Lost terminal]
evils has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
alp has quit [Ping timeout: 260 seconds]
<colemickens>
matthewbauer: same, I am not a user but it feels bad to see it come up a bunch right now and know a bunch of potential users immediately have a roadblock
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
<abathur>
yeah
Cale has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]