<sphalerite>
infinisil++ for some excellent easter eggs
<{^_^}>
infinisil's karma got increased to 274, it's a crit!
<infinisil>
:P
<garbas>
is {^_^} gaining conscious? it knows how to make jokes!? :)
<garbas>
infinisil++
<{^_^}>
infinisil's karma got increased to 275
<srk>
:D
<flokli>
infinisil: serious feature request: can we get emoji support into {^_^} ?
<flokli>
is it utf-16 safe yet?
<infinisil>
flokli: Should work already!
<srk>
> unicorn
<{^_^}>
"🦄"
<flokli>
❤️ infinisil
<flokli>
^ your karma hasn't increased
<gchristensen>
✨ infinisil
<{^_^}>
infinisil's karma got increased to 276
<flokli>
mmhhh
<flokli>
I think I can sparkle to increase karma, hearting should work too.
<infinisil>
Ahh, we could add another regex for the emoji heart too :)
<srk>
I can't test my bot :(
<infinisil>
+1 to srk getting amqp access from gchristensen
<gchristensen>
srk: I can get you connected today :)
<srk>
\o/ \o/ thanks :)
* srk
has some more functionality in progress
v0|d has joined #nixos-dev
NinjaTrappeur has quit [Quit: WeeChat 2.7]
NinjaTrappeur has joined #nixos-dev
<spacekookie>
Mic92: the meeting is in 20, right? Just making sure I'm on the right timezone this week x)
<niksnut>
yes
<spacekookie>
woo
teto has joined #nixos-dev
<spacekookie>
I can't seem to see you anymore :(
<Mic92>
Me too
<niksnut>
people briefly appear and then disappear
<sphalerite>
worldofpeace: rfc meeting?
<qyliss>
concept: meta.eolDate
<qyliss>
We could have a check for disallowing eol software by default, _and_ before a release the RMs could delete anything that would go EOL during the support time of the release
<FRidh>
qyliss: Noting eol date is a good idea. But using it for evaluation is impure which I think we should avoid
justanotheruser has quit [Ping timeout: 244 seconds]
<cole-h>
MichaelRaskin: re your question on the liberation_ttf_v2 PR -- I think it's because cvc4 depends on jdk, which depends on liberation_ttf, as you noted.
<MichaelRaskin>
Ah, that's just me underestimating the rev-deps of JDK. Makes sense, thanks
<cole-h>
:)
justanotheruser has joined #nixos-dev
spacekookie_ is now known as spacekookie
kraem has quit [Quit: outta here]
<worldofpeace>
globin_: I think the fix is maybe moving it from preFixupPhases to using addEnvHooks
<worldofpeace>
* preFixupHooks
<globin>
worldofpeace: that was more of a question if i'd be wasting time on it if I start looking at it and jtojnar nearly being finished or if it would actually make sense
<jtojnar>
sorry, did not start on that yet
<jtojnar>
if someone wants to tackle that, feel free
kraem has joined #nixos-dev
<jtojnar>
worldofpeace: yeah, we will have to make it prefixup hook as before
<jtojnar>
the main issue is we will now have multiple preFixup hooks depending on each other
<jtojnar>
so we will need to force ordering again
<jtojnar>
globin^
dongcarl has quit [Read error: Connection reset by peer]
<cole-h>
srk: Even making a default.nix that imports hnix-overlay would be welcome
<srk>
ah right
<cole-h>
Just want to keep it all in one place
<cole-h>
Improvements can come later :^)
<srk>
cole-h: there's meta/ in hnix-overlay prepared for that
<srk>
cole-h: I'll add that and the overlay to NUR
<srk>
and tests.. but not today :D
nschoe has quit [Remote host closed the connection]
nschoe has joined #nixos-dev
alp has joined #nixos-dev
<jtojnar>
Ericson2314: but to know the application order, would not we need to know the whole dependency tree? e.g. if I something with a setup hook deep in the transitive dependencies of first buildInput is propagated, it would run before thing propagated by dependency of a second buildInput?
<Ericson2314>
Jan Tojnar: yeah it recurs through all dependencies and only once it gets back to the node does it enqueue it's setup hook
<Ericson2314>
this is esepcially better because we only process dependencies once
<Ericson2314>
maybe the dependency was already processed, but it's fine because it still comes first -- we still get valid topological sort
<Ericson2314>
right now we don't get a valid reverse topological sort because while the dependency is processed second if it is new, it is processed first if it is old
<jtojnar>
globin: I think I will just fix it, no point of delaying it
<prusnak>
can someone add "6.topic: java" label to nixpkgs? or what's the correct process for requesting new labels?
<srk>
I was thinking about "package update" label the other day but that would require a bit of automation
<tilpner>
Mic92: I'm not sure. I can of course set an arbitrary start date, but it depends on when we get this accepted. And creating the issue and sending a mail is the responsibility of the person enforcing this, who I also can't just choose arbitrarily.
<Mic92>
tilpner: I would make it relative to the accepting date.
<tilpner>
Mic92: The RFC already states that the process "is repeated at the beginning of each new year". I was hoping that to mean Jan 2020, but that didn't work out
<Mic92>
tilpner: You can rephrase it to do one process after accepting the RFC and than in January again.
<tilpner>
Mic92: If we want to have a special "catch-up" invocation, sure, we can do that
<Mic92>
tilpner: It's not the final word either. There is still an FCP
<tilpner>
I intentionally left the part of "who does this" underspecified, hoping that someone with the authority to enforce it would fill in the gaps. I can't really addres that point myself
<Mic92>
tilpner: did not we discuss this in the meeting?
<Mic92>
My memory is a bit lacking
<tilpner>
We touched on it, but AFAIR we didn't settle on a specific person
<tilpner>
It's probably going to end up being yet another task for eelco or graham
<Mic92>
tilpner: I think at some point we had a list, who was adminstrator. domenkozar[m] was in this list.
<tilpner>
Mic92: Pushed a +1/-1 to mention it takes effect after being accepted
<domenkozar[m]>
I'm not following :)
drakonis has quit [Read error: Connection reset by peer]
<Mic92>
domenkozar[m]: we are talking about who can remove people from the nixpkgs maintainer team. In this case inactive ones.
<tilpner>
domenkozar[m]: Do you have the permissions to remove people from nixpkgs-committers? And if so, are you wiling to commit to enforcing a yearly process of removing inactive committers from it?
<Mic92>
tilpner: I think we can even set up a calendar even or so.
<Mic92>
tilpner: The person that figures out inactive members and sent out the email does not even have to be an admin. As long as this person instructs one of the admins to remove the inactive accounts.
<Mic92>
tilpner: You could even do it.
<gchristensen>
tilpner: once the RFC is accepted we don't need any particular admin to commit to enforcing it
<tilpner>
Mic92: Maybe. This admin would still have to verify my list, and it adds some overhead.
<gchristensen>
verifying a list is easier than making it
<tilpner>
gchristensen: Mic92 asked to address the open question of "Who is doing the removal"
<gchristensen>
"any admin"? :)
<tilpner>
gchristensen: No, it's literally the same step
<gchristensen>
okay
<tilpner>
Just run the script in the RFC, and see if it agrees with the list I sent
<tilpner>
Admittedly, this would save a few minutes of writing the notification issue
<tilpner>
gchristensen: "any admin" was the default values, yes. But the concern was that nobody might feel responsible, and it wouldn't happen. Which can be fixed by nagging on IRC
<gchristensen>
there is no system in place for "yearly" events
<gchristensen>
one substitute could be making it part of the release process, making it 6monthly
<tilpner>
It's been so long, I don't care anymore about the specifics
<gchristensen>
the 6monthly cron job of "release nixos" is probably a good place to add it
<tilpner>
That implies changes to the RFC and the script
<gchristensen>
only do it on the .03 release?
drakonis has joined #nixos-dev
<gchristensen>
the idea being bake it in to a process which already exists, than count on a particular admin to remember and do it
alp has joined #nixos-dev
<worldofpeace>
I don't like the idea of making it a process of release nixos, it has nothing to do with nix & OS, it's about its structure.
<worldofpeace>
that just adds overhead to the release where it isn't needed?
<gchristensen>
my thinking is add a bullet item "ping an administrator to execute RFC55"
<gchristensen>
pretty low effort from the release team, but guaranteed to be seen twice a year
<worldofpeace>
I still don't think that makes sense. That is a task for the "NixOS org infrastructure team i.e github admins"
<gchristensen>
worldofpeace: so are lots of other thinsg in the release checklist, but there is no "hook" right now to put a yearl thing on to other than that
<worldofpeace>
who has write access shouldn't concern the release team.
<gchristensen>
anyway, if you don't like it, thatis okay, ignore it -- but I just dont see it happening otherwise
<gchristensen>
jtojnar: nice :) though maybe s/fringe//
<worldofpeace>
well, what is in the release checklist is something for the team to supervise or delegate. But atm, it should be someone's responsabilities to oversee who gets added to the org, who gets removed, and that would also be RFC55. We create a new team called GitHub Admins, and that's people who already invite people to the org, add a section to the nixos manual about how and when to do it, and then the GitHub admin team is
<worldofpeace>
pinged at the same date every year to do it.
<gchristensen>
and who pings them?
<worldofpeace>
* responsibilities
<worldofpeace>
or no one pings them, you just assign a single person in even rotation of the GitHub admin team to just do that for whatever year. and we really could use a nixos.org calendar
<gchristensen>
to just remember
<gchristensen>
yeah
<gchristensen>
I don't understand the distaste to putting it in the release steps to have an admin do this, it seems light-weight, existing, and fault-tolerant
<gchristensen>
but okay
<gchristensen>
I need to walk away for a while, catch y'all later :)
<worldofpeace>
you could create some sort of contraption that creates an automated issue on github and pings the team even. i.e a cronjob yearly
<MichaelRaskin>
A yearly cronjob to interact _with GitHub_ sounds like an experiment whether failure rate can beat 100%
<LnL>
that's a _really_ hard thing to do correctly and monitor
<cole-h>
See: all the recent ofborg-internal-error labels
<MichaelRaskin>
We _do_ have a yearly process that happens on the edge of the years, but I am not sure it is a good idea to hang such things there
<worldofpeace>
(*throws that in the trash. anyways, you can't trust github to even reliably create an issue.) I've already seen someone get their commit bit back after being removed from not having 2fa. it wasn't hard to get back. to just remember with some sort of calendar reminder, email, has to be fine? 2020 and we can't send email, then maybe we should stop internetting.
<MichaelRaskin>
We cannot make a low-notability yearly process. We never could, but we have actually noticed now
<qyliss>
We update the copyright notice every year :P
<MichaelRaskin>
± 3 months or so?
<qyliss>
Doesn't have to be exact, presumably
<worldofpeace>
MichaelRaskin: I don't think I understand what you mean exactly
<MichaelRaskin>
Well, I believe that RFC SC rotation is a yearly process that is visible and long and high-profile enough that it will actually happen yearly approximately at the planned time.
<MichaelRaskin>
On the other hand, updating copyright notice, or running obsolete-entry-collection on the committer list is like SSL certificate update in the bad old days.
<MichaelRaskin>
A small yearly thing that is very often not done on time.
<worldofpeace>
so you're saying it needs to be checked in smaller increments that someone hasn't contributed in 1 year?
<MichaelRaskin>
That has a better chance of working, yes
<LnL>
I think there's a boundary somewhere for things that happen not frequent enough where it's basically impossible to automate
<worldofpeace>
and your foundational claim is something that is "low-notability" not done in regularity has a high chance of just not being done at all or on time.
<LnL>
so doing it continuously would solve that, otherwise you need something to trigger it like the release steps which we're relatively confidant will be read at least twice a year
<LnL>
the steps itself could be automated ofcourse, just not the automatic triggering
janneke has quit [*.net *.split]
Taneb has quit [*.net *.split]
m1cr0man has quit [*.net *.split]
makefu has quit [*.net *.split]
eyJhb has quit [*.net *.split]
lovesegfault has quit [*.net *.split]
dottedmag has quit [*.net *.split]
delroth has quit [*.net *.split]
Taneb has joined #nixos-dev
dottedmag has joined #nixos-dev
eyJhb has joined #nixos-dev
janneke has joined #nixos-dev
dottedmag has joined #nixos-dev
dottedmag has quit [Changing host]
m1cr0man has joined #nixos-dev
janneke has joined #nixos-dev
janneke has quit [Changing host]
makefu has joined #nixos-dev
eyJhb has joined #nixos-dev
eyJhb has quit [Changing host]
delroth has joined #nixos-dev
lovesegfault has joined #nixos-dev
<worldofpeace>
I get that now
alp has quit [Ping timeout: 272 seconds]
<worldofpeace>
And that it needs to be in a place that could be seen by someone, it's just I disagree with that someone being the release team. Throwing more steps into a process just because someone will read them doesn't seem intentional to me
<worldofpeace>
But is adding a GitHub admins team out of scope... I don't know
<LnL>
yeah, I have no idea about that part of the release process
<MichaelRaskin>
We could try to invent a monthly _something_ that is also suited to hang a few yearly tasks onto
<MichaelRaskin>
Then it just needs to make sense as a monthly something
<worldofpeace>
monthly bikeshed
<worldofpeace>
jk
<worldofpeace>
hmm...
<MichaelRaskin>
Monthly bikeshed sounds good. That would mean we need to _stop_ bikeshedding at least once a month, right?
<LnL>
the officehours come to mind, but that's not exactly very structured at the moment
<worldofpeace>
✨ MichaelRaskin
<{^_^}>
MichaelRaskin's karma got increased to 0b100001
<worldofpeace>
LnL: we do what know with officehours?
<LnL>
of the topics could be to see who would fall off the list in each iteration