<red[evilred]>
(also gchristensen (IRC) - I sent you a message the other day on a related topic that I thought would ammuse you)
<infinisil>
TIL
<infinisil>
red[evilred]: beam refactor?
<red[evilred]>
I saw a few days ago that there was discussion about how to package / deliver packages that are deployed on the beam
<red[evilred]>
but I lost it
<red[evilred]>
because there's apparently some difficulty getting soime of the tooling to play nice
<red[evilred]>
I was looking to better understand the problem since I'm about to deploy a BEAM application using nix
<red[evilred]>
not as in "the BEAM is going to be refactored"
<red[evilred]>
although saying that... the erlang VM specification is actually pretty well documented so could probably be reimplemented fairly easily if anyone really wanted to.,
<red[evilred]>
domenkozar[m] (IRC): do you still use bacula?
rajivr has joined #nixos-dev
das_j has quit [Ping timeout: 265 seconds]
ris has quit [Ping timeout: 246 seconds]
das_j has joined #nixos-dev
supersandro2000 has quit [Ping timeout: 260 seconds]
Raito_Bezarius has quit [Ping timeout: 260 seconds]
supersandro2000 has joined #nixos-dev
Raito_Bezarius has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<jtojnar>
I have repeatedly heard that CVE fixes causing mass rebuild should go to master but according to rfcs#26 they should go to staging-next
<symphorien[m]>
is the "merge and squash" button of github acceptable to comply with the "one commit per package" rule when there is only one package affected in a PR ?
teto has joined #nixos-dev
thibm has joined #nixos-dev
janneke has quit [Remote host closed the connection]
janneke has joined #nixos-dev
cole-h has quit [Ping timeout: 265 seconds]
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<stigo>
Can someone help reviewing a comprehensive zookeeper bump in #104889 ?
<siraben>
Is there a more minimal stdenv than stdenvNoCC?
<LnL>
builtins.derivation? :)
pmy has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
edwtjo has quit [Ping timeout: 240 seconds]
edwtjo has joined #nixos-dev
edwtjo has quit [Changing host]
edwtjo has joined #nixos-dev
orivej has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
AlwaysLivid has joined #nixos-dev
<srhb>
Hmm, did the staging workflow change again? Just noticed the openssl cve fixes went to staging branches. Are they perhaps exceptions to the rule of security fixes going directly to master/release branches due to the large rebuild? cc ma27[m]
Baughn has joined #nixos-dev
<srhb>
Or maybe it was just considered not critical enough.
<ma27[m]>
oh damn it should be in `staging-next`, right?
<srhb>
Well, either that or master, I thought. But I'm a little confused due to the hugeness of openssl rebuilds :)
<adisbladis>
red[evilred]: Looks like we have the same unavailable version on master
<red[evilred]>
I wonder if that's a sign that most people have switched?
<adisbladis>
Please make a PR updating it and mention in the PR body that it needs backporting
<adisbladis>
red[evilred]: Probably, jdk 8 is pretty old by now
<adisbladis>
Which package requires it?
<red[evilred]>
How would one go about identifying packages that are dependent on it?
<red[evilred]>
my PR was a bump to xorg.server so I'm guessing I re-built everything that had x11 in its dependency tree
<jtojnar>
ma27: srhb I am confused as well, I kept hearing critical fixes (even mass rebuilds) should go to master so that is what I put into the diagram
<jtojnar>
but reading the rfcs#26 it says staging-next
<ma27[m]>
as mentioned above, this is probably not a good idea for 5000+ rebuilds %)
<ma27[m]>
re staging-next: read that as well, that's why I asked first :)
<srhb>
jtojnar: I think the conclusion is that this just isn't critical enough, therefore it follows the mass-rebuild rule. So the diagram looks good :)
<jtojnar>
maybe, but then it would mean the rfc is outdated