justanotheruser has quit [Ping timeout: 265 seconds]
<abathur>
anyone feel like they have a good handle on how to convert between single-/multi-user installs? :)
justanotheruser has joined #nixos-dev
<abathur>
trying to sort out installing over an existing Nix volume on macOS; it seems to work fine when both installs are multi-user, but when the existing install is single-user it ends up with two nixes on PATH, one coming in through ~/.nix-profile; not sure if that means it's as simple as cleaning up any nix refs in a ~/*(profile|rc|env)?
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
<abathur>
ah, no, that wouldn't help
<abathur>
I suspect I need to reverse the nix-env invocations that install nix and cacert in the single-user install
<siraben>
I didn't see that problematic dependencies table before, heh
alp has joined #nixos-dev
orivej has joined #nixos-dev
FRidh has quit [Ping timeout: 264 seconds]
FRidh has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-dev
FRidh has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
ehmry has joined #nixos-dev
ris has joined #nixos-dev
greizgh has quit [Quit: greizgh]
greizgh has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
__monty__ has joined #nixos-dev
b42 has quit [Ping timeout: 260 seconds]
b42 has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
alp has joined #nixos-dev
ehmry has quit [Read error: Connection reset by peer]
ehmry has joined #nixos-dev
m1cr0man has quit [Read error: Connection reset by peer]
m1cr0man has joined #nixos-dev
alp has quit [Ping timeout: 264 seconds]
FRidh has quit [Quit: Konversation terminated!]
alp has joined #nixos-dev
orivej has joined #nixos-dev
<catern>
I'm again waiting for review on my PR, and don't have a good way to achieve it... I'm back to thinking some kind of tit-for-tat/karma system would be good...
<catern>
even if I had commit privs (I think I meet the requirements) that wouldn't help my PRs get reviewed faster (since it would be inappropriate to merge my own PRs without review)
<catern>
you'd gain karma by doing reviews, and you could associate a karma bounty with your PR, which someone who reviews the PR would gain
<catern>
(hm isn't that how Stack Overflow works? maybe a similar model)
<tilpner>
On StackExchange you gain points for good/accepted answers, and can theoretically lose points for bad answers
<mkaito>
I thought the only thing you lose on SO is your faith in humanity
<catern>
tilpner: yeah so I guess a full copy would also give you points for merging PRs (probably not a good idea to lose points for rejected PRs though)
<tilpner>
Your proposed model would incentivise quick and shallow PRs, if the reviewers goal is to maximise points. (I'm not saying people would necessarily do that, just that the incentives are different as long as review quality is not factored into the reward function)
<catern>
er, that is, points for your own PRs getting merged
<catern>
tilpner: oh, to be clear, I was only originally proposing that reviews and reviewing gain karma
<catern>
not PRs themselves, but of course, your critique also applies for reviews
<typetetris>
Some people collect points (if there is the possibility to do so) just for the sake of collecting points.
<mkaito>
have any of you considered a post-nixpkgs world using composable flakes and a nixos-core repo?
<MichaelRaskin>
Slashdot meta-moderation comes next?
<MichaelRaskin>
Yeah, that would be a mess collapsing back to a monorepo in a few months
<catern>
sure, points for the sake of points is good, because it has a side-effect of getting lots of PRs reviewed :)
<tilpner>
typetetris: Except these would not just be meaningless internet points, if they can summon attention to PRs you care about
<catern>
tilpner: that's true for StackOverflow though too
<mkaito>
is nixpkgs any less of a "mess"?
<tilpner>
There's also that weird privilege system on SE, which we should absolutely not replicate
<MichaelRaskin>
Yes, compared to attempts to split
<mkaito>
alright, guess I won't be expecting any help here then.
<MichaelRaskin>
I mean, you might find a true believer here
<catern>
I'm not tied to this idea specifically, what other ways are there to solve the problem? we want to get PRs reviewed faster; the most obvious direction to go there is, getting more people reviewing PRs. so how to make an incentive for people to review PRs? well, one easy way is getting faster review for your own PRs if you review other people's PRs
<catern>
that has an appealing symmetry
lukegb has quit [Quit: ~~lukegb out~~]
<catern>
(and exactly how to implement that "faster review for your PRs if you review other people's PRs" experience is not defined, there could be many ways)
<mkaito>
Don't care about believers. I care about doing my job and the source of trouble that is nixpkgs.
<MichaelRaskin>
We do not want more reviews on PRs, we want PRs getting merged or explicitly not merged faster
lukegb has joined #nixos-dev
<mkaito>
I've found that contributing my time in the form of reviews to have been a huge waste of time tbh
<catern>
MichaelRaskin: sure, true, but of course it saves time if the PR is already fully reviewed by the time someone with commit rights sees it
<tilpner>
catern: A shared PR review queue might be a start, while preserving the current incentives. Something that would allow you to mark PRs as "I plan to get to this during the next 3 days", and if you don't it's released back into the pool. Then you could also filter for PRs in your competence zone with the most need for reviews
<MichaelRaskin>
Given that the merger still needs to read the request for reasonability, we kind of want to reduce the need for manual review of any other aspect
<mkaito>
I've always thought that one of the biggest problems with nixpkgs is that most maintainers can't actually maintain the things they are maintainers of, always beholden to those with commit rights passing by and having a good day.
<catern>
MichaelRaskin: right! we'd want the request to already be fully fixed up in terms of code quality
<catern>
mkaito: re: "contributing my time in the form of reviews is a waste of time" yes, that's the thing my karma-system proposal tries to address
<typetetris>
Together with a shared PR review queue there could be a triage system. So Reviews done by beginners (like me) get checked by users with more experience, until the beginner had enough of his PRs been labelled "good" by some more experienced user. That way a system of trust in quality could slowly build up.
<mkaito>
internet points are not an argument I can bring to my manager when we review the fact that we allow our engineers to spend paid time reviewing PRs
<catern>
tilpner: typetetris: yeah, those sound like good ideas! although, I still feel like the proper incentives aren't there. if I'm someone submitting a drive-by PR to fix some bug in a package - what should my experience be?
<MichaelRaskin>
catern: one still has to read the entire diff before merging, so we need to make reviews useless… maybe outside the narrow band of people who should have been given merge rights by opinion of multiple committers
<catern>
mkaito: "I can spend those internet points to get faster merging of the PRs we care about" is, though
<mkaito>
here's the thing
<mkaito>
I don't care about getting my PRs merged faster because I run everything off a nixpkgs fork that I have full control over
<mkaito>
if nixpkgs proper wants to merge my stuff, it's up to them
FRidh has joined #nixos-dev
<mkaito>
no amount of internet points will convince me running our infrastructure off nixpkgs proper is a good idea, because I can't depend on other people to merge things
<mkaito>
so in the end, it doesn't matter :P
<tilpner>
mkaito: Shouldn't you care about keeping the divergence from upstream low, so that rebase is cheaper for you?
<mkaito>
we're going to solve that problem by removing the fork and moving to composable flakes instead. which is just another way to not contribute to nixpkgs.
<MichaelRaskin>
tilpner: that depends on things being merged in a month or two, not on things being merged a week faster
<catern>
mkaito: that's definitely one reasonable answer, but I've found it quite annoying to use a nixpkgs fork - mainly because I have to build everything from source...
<mkaito>
well, we have build clusters for that. benefits of doing this for a living and not a hobby I guess.
<tilpner>
MichaelRaskin: Sure, I was going more for a "merge in less than 2 months" vs "forgotten for 10 months", at which point the cost should be more noticeable
<MichaelRaskin>
Kind of yes kind of no
<mkaito>
that reminds me, I should see about upstreaming some of our stuff in a batch soon
<MichaelRaskin>
I have some personal stuff that is too messy to submit to Nixpkgs even if I have merge rights
<MichaelRaskin>
It just … lives in an overlay-like place with less maintenance than would be needed for a properly managed Nix package in Nixpkgs.
<mkaito>
funny you say that, I just spent the last 2 days cleaning up my personal server config
<catern>
mkaito: but you see how that is dependent on having a lot of infrastructure set up? i'm concerned about the smaller contributers, or people who aren't yet committed enough to Nix to set up build clusters
<mkaito>
well yeah, I suppose there aren't that many companies invested in nix yet
<mkaito>
but we have an entire team of "nix people" running servers and builders
cole-h has joined #nixos-dev
<MichaelRaskin>
To be fair, if you have _a_ build cluster, enabling Nix builds there is not that much of an investment
<MichaelRaskin>
OK, having a team of Nix people is definitely a large commitment
<catern>
tilpner: re: "merge in less than 2 months" vs "forgotten for 10 months" - yes, that's mostly what I'm concerned about too
<mkaito>
I work for serokell, you might have heard of us :P
tom39291 has quit [Ping timeout: 272 seconds]
<catern>
tilpner: although "always taking 2 months" would be concerning too - a faster average time with tails out to 2 months would be better
<mkaito>
after 2 months I wouldn't even remember what I was trying to solve in a PR
<mkaito>
getting a negative code review after 2 months would just lead to me not bothering again
tom39291 has joined #nixos-dev
<catern>
(in my experience almost all of my PRs go months before any review, which is frustrating when they're simple easy fixes)
<mkaito>
yeah but the solution to that is not internet points
<mkaito>
monorepos only work when there's a sufficient amount of people able and willing to maintain it. nixpkgs doesn't.
<mkaito>
mostly because it's just too big for the couple people that work on it
<catern>
I disagree with the anti-monorepo take, I think that's wrong
<mkaito>
maybe, maybe not. either way, I think flakes will save nixos in the long run.
<catern>
but I don't really want to devolve into a monorepo vs multirepo argument (we do that enough at my $DAYJOB aargh)
<typetetris>
mkaito: In a post-nixpkgs world with lots of composable flakes, one would need to solve a similar problem for NixOS: Which flakes to include? How to trust those people, they don't do bad stuff in their flakes? (Maybe I get this wrong, but its still a problem of distributing trust, isn't it?)
<catern>
mkaito: anyway, within the framework of a monorepo, I think internet points is a good way to solve it - or at least an acceptable way
<mkaito>
for those that care. certainly wouldn't convince me of anything.
<mkaito>
I don't need to be "motivated" to contribute. it's my job.
<mkaito>
the problem with it being a job is that I need to get things done, one way or another. and if nixpkgs being slow is in the way, then I just find a different way. this is not a jab at anything, it's just a reality of _this being a job_.
<catern>
mkaito: it doesn't need to convince you, it just needs to convince at least one person to review PRs with bounties faster. then you'll have the motivation to gain points so you can put bounties on PRs
<mkaito>
I really don't think it'll work nearly as well as it does in your mind
<mkaito>
but I'm one of those people that doesn't have social media. maybe I just don't understand people.
<catern>
¯\_(ツ)_/¯ I'm just trying to solve the problem, alternative solutions are acceptable
<mkaito>
the solution is fundamentally always the same. the problem with nixpkgs is that the ratio of work to people is too high. the solution is to get that ratio into a better state, one way or another.
<catern>
tilpner: so a shared PR review queue would be nice, but I don't see how that fixes the problem of "I, J. Random Hacker, submit a drive-by PR and it doesn't get reviewed for 6 months"
<mkaito>
this actually reminds me. I got an email on Friday about a PR of mine that was merged. I filed it 6 years ago.
<catern>
the only scalable way to fix that is to get more contributors the more PRs we get
<catern>
so, we want J. Random Hacker to do something to help - how do we get them to help?
<MichaelRaskin>
We want more people allowed to merge and fewer people satying that things are merged toop carelessly
<mkaito>
you see, the problem with giving people commit access is that they can commit to all of nixpkgs. which means that there's a significant barrier to giving people such access. more granular access would make this significantly easier. given that we live on github, and the access unit on github is the repo, the only way to do this is to have more repos. hence, more flakes.
<MichaelRaskin>
(This «we» does not include every contributor to Nix*)
<FRidh>
with volunteers only you're not going to get there, especially when it comes to part that requires significant depth. You will need funding to get people to actually work on it.
<mkaito>
also, I'm told that for every person added to the list of committers, there's a tenfold amount of people that have a problem with it.
<tilpner>
catern: Well, older PRs get weighted more, so that people who show up and say "I have time, give me a PR to review" start with the older PRs and either transition into a "waiting on author", closed or merged state, all of which remove it from the queue.
<catern>
mkaito: that's not the only possible solution though - you could, for example, create some bot which lets area-specific pseudo-maintainers merge PRs in their area
<mkaito>
well technically I get paid to work on nix and am allowed to contribute to nixpkgs on the clock. I'll consider that "funding" to some extent.
<MichaelRaskin>
mkaito: true, but as long as they are still the minority, the overall situation improves
<mkaito>
we also have one guy on the team that actually has commit access, I suppose that also counts as funding to some extent lol
<catern>
FRidh: I don't know, imagine that everyone submitting a PR also did two reviews - that would make things a lot easier on the people with commit rights, I think!
<FRidh>
catern: that works great with all the small updates of which we indeed have many all the time. Would definitely be great for that! But, the things that often don't get the attention that deserves is tree-wide or core changes. Those can require a lot of time.
<catern>
agreed that core stuff needs (or at least benefits from) paid, dedicated maintainers
<mkaito>
how's the bikeshedding these days :P
<catern>
(it kind of reminds me of Emacs; the C core is neglected because people are much more interested in working on Lisp)
<mkaito>
and now we are compiling elisp to C /shrug
<catern>
which I guess supports mkaito's argument in favor of breaking up the monorepo
<MichaelRaskin>
Well, here a lot of work on core is disincentivised by actual pushback, too
<catern>
but, there are successful monorepo FOSS projects, like Linux
<mkaito>
this is less like linux and more like BSD
<catern>
but there mostly everyone is paid to work on it :)
<MichaelRaskin>
We do not patch or do integration enough to qualify for BSD
<mkaito>
I'm all for keeping the core stuff in a single repo. I just don't see why we need every app, package and module ever written in there as well.
<catern>
anyway, I still think some kind of review-trading system, a review for a review, would improve things
<MichaelRaskin>
As long as someone pays for Hydra, so that a change impact can actually be evaluated
red[evilred] has joined #nixos-dev
<red[evilred]>
So I'm running a nix-review (of xorg.xserver so lot of deps) - unfortunately one of the deps is oracle jdk and I don't seem to be able to locate the correct version to insert into my store (at least yet)
<red[evilred]>
if stuff like that goes missing - is there a best-practice as to how to resolve that?
<catern>
(actually, I guess we can do review-trading without any kind of formal technical enforcement, it just needs to be a common practice) does anyone want to trade reviews with me? :)
<MichaelRaskin>
I can tell you 1.20.9 has a regression on some hardware…
<mkaito>
well I myself (and most of my team AFAIK) am going to work towards more flakes and less monorepo. We've even talked about forking nixpkgs and ripping 90% of it out and leaving only the core system.
<mkaito>
I believe in that enough to put my money where my mouth is
<mkaito>
we'll see how it pans out
<catern>
mkaito: it's probably valuable for your team to try that experiment, indeed
<MichaelRaskin>
What's your plan about importing upstream changes? Just intersect the patch with the remaining paths?
<FRidh>
I don't know, what do you gain at that point You'll end up with huge merge conflicts if you do want to take in patches from nixpkgs for relevant parts
<mkaito>
at that point it would be a hard fork, importing patches would be too hard
<mkaito>
we've *talked* about it, but I'm not sure we're seriously considering a fork. definitely going to work on putting more work into flakes though.
<MichaelRaskin>
If you hard fork, then you definitely will trim, of course.
<FRidh>
have fun then with updating gcc and binutils and the likes
<FRidh>
won't affect as many packages, but still a lot of manual work
<mkaito>
probably more than we can afford to spend on it
<gchristensen>
wkennington still carries on with triton afaik
<red[evilred]>
MichaelRaskin (IRC): how do I resolve something like that (with no guarantee of hardware) ?
<red[evilred]>
or is it not resolvable maybe unless you let it bake in unstable a while I guess looking for user complaints?
<catern>
(hmm, so now I want to build some kind of review-for-a-review system for Nixpkgs, but I don't want to build something tied to Github... how to approach this...)
<MichaelRaskin>
User complaint, there is…
<mkaito>
I doubt the nix ecosystem is leaving github any time soon
<red[evilred]>
oh crap - I'll go look
<MichaelRaskin>
I switched my system to a snapshot of upstream 1.20-branch (so pre-1.2.10) and wrote an issue about what I know by now
<red[evilred]>
I guess that means attempt to locate and backport the security fixes?
<MichaelRaskin>
I mean, you could kick me until I check that the specific set of reverts is enough on my hardware at least
<MichaelRaskin>
So it would be 1.20.9 + one later upstream patch or something
<red[evilred]>
I'm only going through the pain for 20.09
<red[evilred]>
I thought we oly needed to bump to .9
<red[evilred]>
lemme double-check a sec
<MichaelRaskin>
Yes, this gives you all the fixes and one regression
<red[evilred]>
aah - gotcha
<MichaelRaskin>
I mean, I have no stake here, I recorded what I was forced to learn, and my not precisely NixOS system now runs on ain-between version of Xorg, and I can test an alternative Xorg build if there is an expression
<MichaelRaskin>
I am not a stable-branch user so I just mention what I know but don't have vested interest. Can test a completely different Xorg build, of course.
<MichaelRaskin>
(In the worst case I can rebuild my system core from stable)
<FRidh>
which repo contains the config for the prometheus host?
<gchristensen>
nixos-org-configurations in nixos-org-configurations/delft/eris.nix
<gchristensen>
it looks like locations."/prometheus".proxyPass = "http://${config.services.prometheus.listenAddress}"; and prometheus's listenAddress used to have the port but no longer has the port in there
<lukegb>
yeah, it changed in 20.09 I think
<lukegb>
but I'm surprised it only broke now?
<lukegb>
but it makes sense, because then nginx would talk to itself on 0.0.0.0 (which is also a terrible idea), and then you have a forceSSL rule which redirects to https://0.0.0.0
<mkaito>
I was going to apoligize, but my PR didn't remove the port :P
<catern>
MichaelRaskin: thank you :D
<gchristensen>
a pr'd be appreciated
<mkaito>
oh I guess that _was_ my PR that broke it
<mkaito>
sorry :P
teto has joined #nixos-dev
<FRidh>
that's it, hard fork for you :P
<mkaito>
gosh darnit :P
<mkaito>
you should have gotten an assert failure btw
<lukegb>
I think it was relying on the default
<mkaito>
did that change?
<MichaelRaskin>
catern: not touching WIP and merge_conflict
<lukegb>
presumably it no longer includes the port :P
<mkaito>
or you add a trailing slash to the location so it gets removed on proxy pass
<mkaito>
if the location path has a trailing slash, it gets substituted for the URI path at the end of the proxy pass directive. so having a trailing slash in your location, and just a slash in your proxy pass just removes the matching part of the location.
<mkaito>
very intuitive, yes
<mkaito>
which is exactly what the grafana location above does
<mkaito>
basically /grafana/ -> /
<gchristensen>
semes fixed, thanks!
alp has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
alp has quit [Ping timeout: 272 seconds]
WilliButz has quit [Remote host closed the connection]
WilliButz has joined #nixos-dev
sorear has quit [Ping timeout: 260 seconds]
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<domenkozar[m]>
anything you've seen recently that is worth mentioning?
orivej has quit [Ping timeout: 260 seconds]
alp has joined #nixos-dev
evils has quit [*.net *.split]
bridge[evilred] has quit [*.net *.split]
pinpox has quit [*.net *.split]
ericnoan has quit [*.net *.split]
marek has quit [*.net *.split]
nbp has quit [*.net *.split]
nbp has joined #nixos-dev
ericnoan has joined #nixos-dev
pinpox has joined #nixos-dev
bridge[evilred] has joined #nixos-dev
marek has joined #nixos-dev
evils has joined #nixos-dev
iwq has quit [Ping timeout: 264 seconds]
iwq has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 260 seconds]
tilpner_ is now known as tilpner
<mkaito>
have you mentioned deploy-rs yet?
<mkaito>
maybe some people would care about that
AlwaysLivid has quit [Remote host closed the connection]
<mkaito>
I'm trying to get all our new infra code to be presentable enough to live in public repos, as examples to go along with it. I guess someone might find that interesting in the future.
<MichaelRaskin>
Oh cool
<mkaito>
I've got one infra repo that you can link along with deploy-rs but the "shared" repo is a bit messy, and it would look cooler if we had that presentable and two cluster configs tbh
<mkaito>
if you're struggling for content, feel free to link to deploy-rs on its own. otherwise, maybe next week, depending on how much work I have.