alunduil has quit [Read error: Connection reset by peer]
jared-w has quit [Read error: Connection reset by peer]
jared-w has joined #nixos-dev
teozkr has joined #nixos-dev
alunduil has joined #nixos-dev
sorear has joined #nixos-dev
emily has joined #nixos-dev
carter has joined #nixos-dev
c00w has joined #nixos-dev
cbarrett has quit [Ping timeout: 252 seconds]
scott has quit [Ping timeout: 272 seconds]
angerman has quit [Ping timeout: 252 seconds]
c00w has quit [Ping timeout: 265 seconds]
elvishjerricco has quit [Ping timeout: 260 seconds]
alunduil has quit [Ping timeout: 272 seconds]
sorear has quit [Ping timeout: 272 seconds]
thoughtpolice has quit [Ping timeout: 252 seconds]
teehemkay has quit [Ping timeout: 260 seconds]
lightbulbjim has quit [Ping timeout: 260 seconds]
teozkr has quit [Ping timeout: 245 seconds]
sdier has quit [Ping timeout: 245 seconds]
georgyo has quit [Ping timeout: 250 seconds]
nh2 has quit [Ping timeout: 252 seconds]
emily has quit [Ping timeout: 260 seconds]
jared-w has quit [Ping timeout: 260 seconds]
tazjin has quit [Ping timeout: 260 seconds]
davidtwco has quit [Ping timeout: 260 seconds]
rajivr___ has quit [Ping timeout: 260 seconds]
carter has quit [Ping timeout: 272 seconds]
chrisaw has quit [Ping timeout: 272 seconds]
dmj` has quit [Ping timeout: 252 seconds]
feepo has quit [Ping timeout: 260 seconds]
<ryantm>
infinisil: You can feel free to close r-ryantm PRs but it will reopen them (maybe with an even newer version)
johanot has quit [Ping timeout: 246 seconds]
zimbatm has quit [Ping timeout: 246 seconds]
aria has quit [Ping timeout: 246 seconds]
kalbasit has quit [Ping timeout: 272 seconds]
_ris has quit [Ping timeout: 252 seconds]
aria has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7]
aria has quit [Ping timeout: 260 seconds]
srhb has quit [Ping timeout: 260 seconds]
davidtwco has joined #nixos-dev
davidtwco has quit [Ping timeout: 245 seconds]
lightbulbjim has joined #nixos-dev
johanot has joined #nixos-dev
lightbulbjim has quit [Ping timeout: 272 seconds]
johanot has quit [Ping timeout: 246 seconds]
drakonis has quit [Ping timeout: 272 seconds]
ixxie has quit [Ping timeout: 260 seconds]
lightbulbjim has joined #nixos-dev
lightbulbjim has quit [Ping timeout: 260 seconds]
drakonis has joined #nixos-dev
phreedom has quit [Ping timeout: 240 seconds]
phreedom has joined #nixos-dev
justan0theruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
drakonis has quit [Ping timeout: 246 seconds]
c00w has joined #nixos-dev
c00w has quit [Ping timeout: 245 seconds]
c00w has joined #nixos-dev
c00w has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
angerman has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.6]
angerman has quit [Ping timeout: 246 seconds]
angerman has joined #nixos-dev
teehemkay has joined #nixos-dev
chrisaw has joined #nixos-dev
vdemeester has joined #nixos-dev
sorear has joined #nixos-dev
teozkr has joined #nixos-dev
alunduil has joined #nixos-dev
srhb has joined #nixos-dev
sdier has joined #nixos-dev
c00w has joined #nixos-dev
zimbatm has joined #nixos-dev
georgyo has joined #nixos-dev
lightbulbjim has joined #nixos-dev
cbarrett has joined #nixos-dev
dmj` has joined #nixos-dev
emily has joined #nixos-dev
feepo has joined #nixos-dev
nh2 has joined #nixos-dev
carter has joined #nixos-dev
elvishjerricco has joined #nixos-dev
johanot has joined #nixos-dev
aristid has joined #nixos-dev
aria has joined #nixos-dev
<makefu>
r-ryantm already performs a lot of tests for potential reviewers to check. maybe the policy could be that PRs are merged if the package contains tests and all dependencies still build or if there no other packages having it as dependency in first place. I know there were (and still are) a lot of discussions about automatic or bot-assisted merging and i have high hopes for
<niksnut>
Taneb: you may be misled by the web interface, it shows all possible roles but they're probably not selected
<pie_[bnc]>
Profpatsch: thx
orivej has quit [Ping timeout: 268 seconds]
<Taneb>
niksnut: that might be the case, yes
<Taneb>
I do see buttons for, e.g., deleting projects, but I haven't tried clicking them
<Taneb>
OK, that's a relief, I tried restarting a job (as the most harmless thing I shouldn't be able to do) and it gave me an error so I mustn't have those permissions
kenjis1 has quit [Remote host closed the connection]
kenjis1 has joined #nixos-dev
<jtojnar>
Is there a way to reset password on Hydra?
__monty__ has quit [Quit: leaving]
genesis has quit [Remote host closed the connection]
<niksnut>
iirc we used to have a password reset feature
kenjis1 has quit [Remote host closed the connection]
justan0theruser is now known as justanotheruser
Synthetica has joined #nixos-dev
kenjis1 has joined #nixos-dev
psyanticy has joined #nixos-dev
drakonis has joined #nixos-dev
<infinisil>
Reviewing completely random PR's has been very nice so far
<gchristensen>
some gems in there
kenjis1 has quit [Remote host closed the connection]
<Synthetica>
Is that the new policy?
<gchristensen>
hm?
<Synthetica>
Reviewing in a random order
<infinisil>
Synthetica: Oh no I'm just doing this for myself
<infinisil>
It's much nicer imo because this way PRs don't get lost, all of them have an equivalent chance of being looked at, instead of preferring more active/more recent ones
<Taneb>
hub pr list | shuf | head -n1 | sed 's/#\([0-9]*\)/\1/' - | xargs hub pr show
<infinisil>
Yeah, or with the script I made which is about 6 times faster than hub :)
<infinisil>
`script > prs` then `firefox $(cat prs | shuf | head -1)` is what I do, only rerunning the firefox command for one session
<Taneb>
No doubt ;)
<Taneb>
This is the first time I've tried using Hub, it does seem fairly slow for this
<infinisil>
Yeah, took about 70 seconds for listing PRs for me
<infinisil>
Oh whoops, I just ran the script again, this time with it automatically opening the links in firefox
<infinisil>
Turns out the breaking didn't work though, now I have like every PR opened in firefox..
<Taneb>
Whoops
<Taneb>
There's only 1680 (assuming you only opened open PRs), not too bad
drakonis has quit [Read error: Connection reset by peer]
<infinisil>
After some panicking i was fortunately able to stop it by using a getty terminal
<infinisil>
And killing firefox and restarting it made it forget all those tabs :)
evils has quit [Ping timeout: 268 seconds]
drakonis has joined #nixos-dev
<infinisil>
Hm, should we be a bit more liberal with pushing to people's PR branches?
<infinisil>
Many PR's don't need many changes. I could just do them myself and merge them instead of having to comment and wait for the authors response
<qyliss>
I think that sounds good
<qyliss>
You could also at that point just do it yourself and push straight to master
<qyliss>
And then close the PR
<qyliss>
If you're going to merge straight away anyway there's no point pushing the their branch first.
<infinisil>
ofborg's checks would still be helpful
<qyliss>
Yeah that's true, although you can run those locally.
<infinisil>
The different platform builds are most valuable i think
<gchristensen>
(though hopefully the checks will one day it will become mandatory)
<gchristensen>
(adjust that sentence in your mind until it parses)
<qyliss>
Would that mean everything would have to go through a PR? I'm not sure I like the sound of that.
<gchristensen>
it would yes
<gchristensen>
and, I know, it would upset some people
<infinisil>
On that note I'll ping ma27[m], since he seems to have just pushed a new nixos module to master directly: https://git.io/JvTkz
<LnL>
there's no problem with that IMHO as long as is there's tooling to not make that extra overhead
<gchristensen>
yeah
<LnL>
in it's current form you have to wait for the checks to complete
<LnL>
and even then strictly speaking the check is probably outdated by the time you go back to merge
<infinisil>
Not sure what you're getting at. Any checks any better than none
<gchristensen>
+1
<gchristensen>
never will I ever go b ack to ye olde bad days when we didn't have the checks
<infinisil>
And I don't trust anybody, not even myself, to always run all relevant checks manually before pushing something
<worldofpeace>
"Many PR's don't need many changes. I could just do them myself and merge them instead of having to comment and wait for the authors response" infinisil I ask people when contributing to please allow maintainer pushes because it just makes everyone's like easier if I can fixup with ofborg checks on the PR. Else I have to do exactly what qyliss mentioned, which is close and push directly to master.
<worldofpeace>
infinisil++
<{^_^}>
infinisil's karma got increased to 190
<LnL>
sure but playing a human poller to merge somthing isn't very productive
<gchristensen>
agreed
<gchristensen>
it would be nice to be able to use GitHub's "Approve" feature with a `@ofborg merge` command, and auto-merge if evaluations pass
<worldofpeace>
Famous last words are three maintainer approvals and they don't even mention what they did to come to the conclusion of approval.
<LnL>
gchristensen: exactly and at that point the outdated eval isn't a problem anymore either
<gchristensen>
well it might still be out-dated, but much less likely :P
<worldofpeace>
we should really get back to working on that rfc 🤣
drakonis has quit [Quit: WeeChat 2.6]
<gchristensen>
one of the things that scares me about ofborg being able to merge is it is the risk of privilege escalation and determining if the approvals are really authorized to issue that command
<gchristensen>
and the ability to definitively prevent somebody from merging. right now that is easy, revoke their group membership
<LnL>
perhaps it's possible to avoid moving authentication
<gchristensen>
hmm like maybe users who use /merge must authenticate to ofborg, and ofborg becomes that user to execute the merge?
<LnL>
yep
<gchristensen>
that is a nice idea
<LnL>
assuming github has something to not provide full access to your account that could be a great alternative
<gchristensen>
yeah
<gchristensen>
it would be important for my own comfort to only be able to be granted access the nixpkgs repository, and then only a very small subset of permissions
<LnL>
don't see anything parameterized
<LnL>
you have deploy keys, but that's based on a repository not users
<gchristensen>
how about the new fancier permission model of GitHub Apps?
<LnL>
not sure, was looking at oauth scopes
kenjis1 has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
<infinisil>
Oh I think I can optimize my random PR script: First get the number of total PR's, then make an array from 1 to <total>, shuffle it, query the state of the first 100 in a single query to find the first open PR among them
drakonis has joined #nixos-dev
lovesegfault has joined #nixos-dev
lovesegfault has quit [Ping timeout: 258 seconds]
kenjis1 has quit [Remote host closed the connection]
_ris has joined #nixos-dev
<gchristensen>
I wonder how small we could get shellcheck to be
<infinisil>
After doing some calculations with above idea for random PR's, it should on average only take 2.11 requests :D
<worldofpeace>
gchristensen: ain't shellcheck already a static haskell executable?
<gchristensen>
whoa it is, worldofpeace, I thought it had a massively huge closure
<worldofpeace>
it would be cool if it was a check we could run
<gchristensen>
I'm thinking a build-time validation
<globin>
gchristensen: then we need ghc etc in stdenv :/
<gchristensen>
not a check on everything
<gchristensen>
but shellcheck for like, activation scrips
<gchristensen>
they're complicated, long, and one of the few places errors are dangerous
<globin>
+1
drakonis has quit [Ping timeout: 260 seconds]
cjpbirkbeck has joined #nixos-dev
kenjis1 has joined #nixos-dev
<gchristensen>
it does mean ghc needs to build for the channels to move forward, but nixpkgs-unstable already does with the cachix client
psyanticy has quit [Quit: Connection closed for inactivity]
ris has joined #nixos-dev
<globin>
for a channel bump it should build anyway
<gchristensen>
yeah
<samueldr>
aarch64 may suffer
<gchristensen>
pretty much puts shellcheck on every person's machine, which may rustle feathers
<gchristensen>
ohh right samueldr
<samueldr>
not sure if ghc was more successful lately though
_ris has quit [Ping timeout: 240 seconds]
<gchristensen>
${if !stdenv.isx86 then "${pkgs.shellcheck...# only x86 gets nice safety things things" else ""}
<samueldr>
not fond of the precedent this sets
<gchristensen>
me either
<samueldr>
even though it _is_ tiered one level lower
<gchristensen>
it was a joke
<gchristensen>
I would want every build to benefit
<samueldr>
I'm curious as to what doesn't port cleanly to a systemd-based stage-1 in what we have
<gchristensen>
yeaoh
<samueldr>
I know code and behaviour can't match 1:1, but the end result will mostly be the same for 99% cases I believe
<gchristensen>
yeah
<gchristensen>
I *like* our activation script for early boot because of how simple they are, and it feels cool to be able to see so plainly how a Linux system starts
<gchristensen>
but I'm not married to it and that isn't a reason to keep it exactly
<samueldr>
is the stage-1 mess an activation script?
<gchristensen>
erm right sorry
<gchristensen>
my brain is completely mush. the last 7 days have been really intense for me.
<samueldr>
:)
<samueldr>
one of the main issue is how it doesn't deal with dependencies in an appropriate manner, only through ordering, and waiting
<gchristensen>
yea
<gchristensen>
I'm happy as long as I can keep booting from an empty / :)
<samueldr>
in my experiment with mobile nixos, where there's less ordering and waiting, it made stage-1 quicker to boot (that wasn't a goal)
<gchristensen>
yup
<samueldr>
but experiment with non-systemd, non-shell stage-1 init
<gchristensen>
people who say systemd is slow ... is ... well, when you have a precise DAG you can sort of start up maximally fast
<samueldr>
even without an actual DAG working!
<gchristensen>
:P
<samueldr>
I kinda sort the stuff, but rely more on looping on all things and checking if the dependencies are fulfilled
<samueldr>
(because I don't know how to implement that right now and didn't care)
<samueldr>
punted to a future improvement, as more importantly it needed to prove it can boot
<infinisil>
Question: #70234 adds a package that hasn't seen a new commit in 3 years, but it's probably still functional and the author of the PR uses it themselves
<qyliss>
But IIRC my view on this issue was somewhat extreme
<infinisil>
I guess it's alright as long as that person is maintaining the package within nixpkgs
<gchristensen>
love that master has been red for 3 years
lovesegfault has joined #nixos-dev
<infinisil>
Related: What path should packages use for zfs?
<infinisil>
Just ${pkgs.zfs}/bin/zfs won't always work because on NixOS it's /run/booted-system/sw/bin/zfs that you should use
<gchristensen>
their kernel's, heh.
<infinisil>
But the latter doesn't work on non-NixOS
<infinisil>
I guess the only other option is the one in $PATH
<qyliss>
PATH sounds good
<qyliss>
I think it's unlikely you wouldn't have one
<gchristensen>
it is very likely they shoudln't run a nixpkgs zfs package
<infinisil>
Oh, but also: The NixOS binary on PATH is not the one from /run/booted-system
<gchristensen>
a bit dangerous
<clever>
that reminds me, debian patched pam, to support include statements in pam config files (because they lack something like nix with string interpolation)
<clever>
as a result, any binary from nix, that reads pam config files, fails hard
<gchristensen>
:|
<clever>
the nix copy of sudo, fails, even when ran from root
kenjis1 has quit [Remote host closed the connection]
puck has quit [Quit: nya]
puck has joined #nixos-dev
<infinisil>
Idea: RFC's get really long discussions quickly, which lessens participation. So how about we close and reopen long RFCs as a new PR?
<infinisil>
This also indicates that it went through a couple revisions since it first started
<qyliss>
This would make it extremely difficult for people who do want to follow the conversation
<qyliss>
EXTREMELY difficult
<qyliss>
And on the flipside, rather than unsubscribing once from an RFC I'm not interested in, I'd have to unsubscribe from it once a month or something?
<infinisil>
Is it worse than GitHub's awful comment collapsing?
<infinisil>
This shouldn't happen more than once or so
<qyliss>
I think that's a sign that GitHub is a terrible RFC platform.
<infinisil>
We can't change that unfortunately
<qyliss>
Why not?
<globin>
that's why I advocated and still do for shepherd leaders to semi-regularly summarise the discussion!
<qyliss>
What would happen to ongoing discussions?
<qyliss>
I would like to point out that none of these are problems with a mailing list.
<globin>
one PR with regular summaries of open discussion points and decisions reached is better in my opinion
<qyliss>
GitHub is a fundamentally terrible platform for long-form discussion.
<qyliss>
It just doesn't work well, whatever you do.
<infinisil>
globin: You mean a separate PR?
<globin>
no, comments every ~2 weeks if there has been discussion just providing the above
<infinisil>
Hm yeah I don't think that helps with the github awfulness
<samueldr>
maybe it's time we report the bug at github, about the way comments are unusable
<globin>
why, that removes the necessity of reading the collapsed comments?
<worldofpeace>
qyliss: I agree with you. I've had a real pain trying to figure out what I've been doing on github in the past months because I can't track down what I was doing/talking about.
<globin>
worldofpeace: the beta notification page improves that
<qyliss>
globin: infinisil is talking about when GitHub says "Show 100 more comments", not when inline comments are collapsed due to an outdated diff
<infinisil>
globin: So you have a new comment every 2 weeks summarizing the discussion of the last 2 weeks, then another 2 weeks of discussion happens, and now the summary comment is buried up there too, so I need to uncolapse comments to find it
justanotheruser has quit [Ping timeout: 260 seconds]
<worldofpeace>
globin: what is with everything being a beta feature on github nowadays 🤣
<globin>
infinisil: no the summary of all previous talking points
<globin>
infinisil: so that just reading that is enough to join the discussion
<infinisil>
Oh, yeah I don't think anybody could summarize 200 comments into a single one, every two weeks, without it becoming really big or inaccurate
<infinisil>
I mean if anybody can do that then great, but I don't feel like I could do it
justanotheruser has joined #nixos-dev
<qyliss>
Another thing GitHub lacks is proper threaded discussion, so you end up reading three conversations all spliced together in one long thread.
<infinisil>
qyliss: I wish infinite nesting becomes the standard
<infinisil>
I guess mailing lists have that
<qyliss>
Indeed they do
<infinisil>
And reddit does as well
<worldofpeace>
Really, a platform that hides your discussion more and more as you have it is truely counterintuitive. infinisil I wouldn't volunteer to do that too.
<qyliss>
I truly think RFCs should be on a mailing list. Maybe GitHub has some advantages when it comes to code, but the focus on an RFC isn't about code, it's about the discussion, and GitHub is truly terrible about that.
<infinisil>
globin: Ah yeah, that's pretty good, but as you can see it got rather long and presumably took a while to write, I don't think that's realistic on a regular basis
<infinisil>
qyliss: I wouldn't mind a mailing list with a nice frontend
<qyliss>
If people set the subject of their mail to what their point is, you even get a summary of discussion points in the thread overview.
<qyliss>
infinisil: what do you think of hyperkitty? have you seen it?
<qyliss>
I think it's great.
<infinisil>
I think you might have shown it to me before
<infinisil>
Ah you're using it for spectrum, it's in my browser history
<worldofpeace>
I wonder how ironic it would be for an RFC on GitHub to not use GitHub for RFCs would be
<qyliss>
haha
<worldofpeace>
qyliss: do you have link for an example for that? (you using hyperkitty)
<qyliss>
infinisil: it has them in my PR, doesn't it?
<globin>
the mailman module in its current state shouldn't have been merged imho
<qyliss>
I agree
<infinisil>
qyliss: mailmanCfg is still just a string
<qyliss>
But it also suffered from lack of review
<globin>
but I was too slow and it had made it into the release
<qyliss>
infinisil: oh right, but there's webSettings now
<qyliss>
that's what I was thinking of
<globin>
qyliss: yeah but mailman3 is really hard to review+package
<qyliss>
That's true
<globin>
qyliss: see my hacky approach
<qyliss>
Although I'm pretty happy with the job I've done
<globin>
haven't had enough time to look at it thoroughly but looked fine at first glance
<infinisil>
qyliss: Ah I see, yeah that part is a bit better, though a fully specified type is still lacking and assigning defaults in the config section
<infinisil>
qyliss: (instead of doing // cfg.webSettings)
<qyliss>
infinisil: please comment on the PR so I don't forget?
<infinisil>
Can do
<qyliss>
globin: but yeah, I was surprised by the state of the prior mailman module
<infinisil>
qyliss: Oh also it introduces extraConfig, which is bad for backwards compatibility with an eventual settings option
<globin>
infinisil: it is hard to do without because you essentially do just write python code
<infinisil>
Oh it's python..
<qyliss>
No it's not
<qyliss>
The file infinisil is talking about is an ini file
<globin>
oh sry
<qyliss>
The Python one I solved by having a stub Python file that imports JSON
<qyliss>
And then generating JSON from the settings option
<qyliss>
infinisil: wait the standard option is called "settings"?
<qyliss>
Everywhere I've seen in Nixpkgs it's called "config"
<infinisil>
Yeah it was decided settings is better because it doesn't conflict with `config` for modules, and there's enough `config` settings already which mean other things