worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ https://discourse.nixos.org/t/nixos-20-09-release/9668 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 20.09 RMs: worldofpeace, jonringer | https://logs.nix.samueldr.com/nixos-dev
<red[evilred]> I just asked alis for a list of #nixos-* channels and kinda hoped to find a #nixos-beam channel
<red[evilred]> so nixos owns the namespace right? So it's not a case of "if you make it, they will come"
<red[evilred]> ?
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
<infinisil> red[evilred]: I don't think you can own namespaces on freenode, so creating it should be just fine
<qyliss> infinisil: you can, and the NixOS project owns the #nixos- and #nix- namespaces
<gchristensen> the nixos foundation has a group registration for #nixos #nix and #nixos-* and #nix-*, but feel free to make a channel
<gchristensen> the group registration lets the foundation take control of these channels if needed
<red[evilred]> Well, I need to find the people who are working on the BEAM refactor first
<red[evilred]> I checked for an irc channel first since it looked like a sizable undertaking
<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
<{^_^}> https://github.com/NixOS/rfcs/pull/26 (by vcunat, 2 years ago, merged): staging workflow
<jtojnar> anyone knows which is more up to date?
<gchristensen> I've only talked about CVEs going right to master if they're highly critical
<gchristensen> like a heartbleed fix shouldn't wait for staging-next to be heathly
<{^_^}> #106302 (by jtojnar, 1 day ago, open): gdk-pixbuf: 2.42.0 → 2.42.2
<jtojnar> I guess it is somewhat critical
<jtojnar> it allows code execution in file manager thumbnailer
<jtojnar> but the thumbnailer is sandboxed so it would need to be combined with another vulnerability in bubblewrap
<jtojnar> hmm, https://security.archlinux.org/CVE-2020-29385 writes about it as DoS but the original issue calls it a crasher
teto has quit [Ping timeout: 260 seconds]
<hexa-> we merge staging into staging-next every 6h
<hexa-> or maybe I misunderstood that
<hexa-> let me recheck
<hexa-> | Automate the merging of master -> staging-next -> staging.
<hexa-> #105153
<{^_^}> https://github.com/NixOS/nixpkgs/pull/105153 (by FRidh, 1 week ago, merged): GH Action: merge staging(-next) periodically
<hexa-> so there's less of a difference ig
<samueldr> hexa-: other way around
<samueldr> it's so staging gets fixes from -next and master
orivej has joined #nixos-dev
mkaito has quit [Quit: WeeChat 2.9]
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
maljub01 has quit [Quit: maljub01]
maljub01 has joined #nixos-dev
aristid has quit [Ping timeout: 260 seconds]
jared-w has quit [Read error: Connection reset by peer]
aristid has joined #nixos-dev
sorear has quit [Ping timeout: 264 seconds]
jared-w has joined #nixos-dev
sorear has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
kalbasit has quit [Ping timeout: 240 seconds]
supersandro2000 has quit [Quit: The Lounge - https://thelounge.chat]
supersandro2000 has joined #nixos-dev
<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 ?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/104889 (by ztzg, 1 week ago, open): zookeeper: 3.4.12 -> 3.6.2 & assorted changes
pmy has quit [Quit: WeeChat 3.0]
Baughn has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
__monty__ has joined #nixos-dev
orivej has joined #nixos-dev
<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 :)
<srhb> If it's critical, master, if not, staging looks correct. :confused:
<ma27[m]> cc FRidh: Jan Tojnar (don't know vcunat's IRC handle) how shall we proceed here?
<srhb> ma27[m]: Maybe mass rebuild rule wins, and you did the correct thing. Sorry for the noise in that case :)
<hexa-> srhb: I didn't feel it was *that* critical tbh
<hexa-> but there is no problem pushing it to master ig
<srhb> hexa-: Yeah, I kinda feel the same, but the description was a little opaque to me, so suddenly doubts. :P I think you're probably right though.
<srhb> re. "not that critical" I mean.
<hexa-> fwiw: I'm mweinelt, the author the the pr in question
<srhb> hexa-: Oh, thanks for clarifying! :)
kalbasit has joined #nixos-dev
<hexa-> also pushing a rebuild-5001+ package onto master is kinda like throwing a wrench into the machine :D
<hexa-> you'd probably accept that for heartbleed et al., but not for this :)
<srhb> Yeah, I realize that. :/ I think you're correct, and good to hear it's deliberate. I'll stop worrying on this :)
<hexa-> debian stable has it fixed already https://security-tracker.debian.org/tracker/CVE-2020-1971
<hexa-> so it was embargoed and predisclosed to distros
<hexa-> thanks for worrying though, wrapping my mind around the staging branches is tough :)
<FRidh> ma27[m]: link?
<srhb> FRidh: It was this, but I think hexa- put my mind at rest re staging being the correct target indeed: https://github.com/NixOS/nixpkgs/pull/106362
<{^_^}> #106362 (by mweinelt, 23 hours ago, merged): openssl: 1.1.1h -> 1.1.1i
<FRidh> if its not critical then yes, staging
<srhb> Great. :) Thanks all.
<{^_^}> #106452 (by mweinelt, 1 hour ago, open): curl: 7.73.0 -> 7.74.0
<hexa-> yeah, reviews very welcome .)
<hexa-> they're also not too critical
<FRidh> ok good
<hexa-> two advisories are ftp related, one for ocsp validation, where they don't look to close whether the response actual matches the ocsp response
<hexa-> whether the certificate*
red[evilred] has joined #nixos-dev
<red[evilred]> so - I have a non-random question
<red[evilred]> when building something in 20.09 I discovered that it needed a jdk
<red[evilred]> but the version of teh jdk that you need to download and put in the store doesn't seem to be available anymore
<red[evilred]> (or at least I couldn't find it)
<red[evilred]> shouldn't that mandate an upgrade in stable?
<hexa-> could you make your example more concrete?
<adisbladis> red[evilred]: Yeah, sounds like it
<red[evilred]> sure
<red[evilred]> it was in the pr I just did
<red[evilred]> lemme re-run it
<adisbladis> hexa-: Reading between the lines a bit, but I take it the (nonfree) version of the oracle jdk is not available anymore
<hexa-> adisbladis: yeah, you apparently have more context then I do :)
<hexa-> s/then/than/
<red[evilred]> Unfortunately, we cannot download file jdk-8u261-linux-x64.tar.gz automatically.
<red[evilred]> Please go to http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html to download it yourself, and add it to the Nix store
<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
<{^_^}> https://github.com/NixOS/rfcs/pull/26 (by vcunat, 2 years ago, merged): staging workflow
<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
<hexa-> ma27[m]: fwiw: we're batching pulls for staging-20.09 in https://github.com/NixOS/nixpkgs/projects/26#card-50919823
<red[evilred]> oh! Diagram!? Pl;ease share
<hexa-> #105986
<{^_^}> https://github.com/NixOS/nixpkgs/pull/105986 (by jtojnar, 4 days ago, merged): doc: Add staging workflow diagram
<srhb> jtojnar: You're right, the RFC is outdated (in more than one way -- staging-next doesn't even have hydra jobs anymore, right?)
<jtojnar> staging-next does
<jtojnar> staging does not
<srhb> Sorry, yes :P
<{^_^}> #106321 (by FRidh, 1 day ago, open): Staging next
<jtojnar> so this thing to master? https://github.com/NixOS/nixpkgs/pull/106302
<{^_^}> #106302 (by jtojnar, 1 day ago, open): gdk-pixbuf: 2.42.0 → 2.42.2
<hexa-> jtojnar: do you have an advisory?
<hexa-> > GDK-PixBuf could be made to hang if it opened a specially crafted file.
<{^_^}> error: syntax error, unexpected IF, expecting ')', at (string):443:34
<hexa-> is what ubuntu says
<hexa-> that's related to "Fix loading GIF without a GCE rendering color 0 [Robert Ancell, #162]"
<{^_^}> https://github.com/NixOS/nixpkgs/pull/162 (by ecarreras, 8 years ago, merged): VLC: update to v2.0.4
<hexa-> eh "Fix invalid LZW codes in the GIF loader [Robert Ancell, #164, CVE-2020-29385]"
<{^_^}> https://github.com/NixOS/nixpkgs/pull/164 (by jcumming, 8 years ago, merged): - ncmpcpp 0.5.10
<infinisil> (btw you can make the bot link to specific repos with <owner>/<repo>#<issue>)
<hexa-> I copied the raw chanloge entry, sorry :)
<hexa-> there was no intent to link to anything
<infinisil> Yea, just wanted to point out :)
<infinisil> Ohh, yeah it wouldn't work on gitlab anyways
<hexa-> I think staging would probably be fine
<hexa-> like it's not directly remote executable etc
<hexa-> or staging-next, whatever has the hydra job
<FRidh> staging still needs to get a small job
<FRidh> if sqlite needs to be reverted, we can throw that security update in right away. Would prefer not to though
<jtojnar> FRidh: it is not clear if the test case reveals a bug that would cause issues for users
<jtojnar> it is currently discussed at #tracker:gnome.org
<hexa-> FRidh: #105268 could go in right now, but it's still in draft state. ig to prevent accidental merge?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/105268 (by FRidh, 1 week ago, open): libxml2: upstream patch for Python 3.9.
<FRidh> ok, then I suggest we just let hydra keep building for now
<red[evilred]> adisbladis (IRC): I'll make that PR for you - np.
<FRidh> hexa-: yes definitely, marked it as draft to avoid accidentally merging it. If there's a batch of changes, get it in
<jtojnar> they managed to track it down to https://www.sqlite.org/src/info/b79f19edfd33c2a7
<red[evilred]> oh - I really like that diff --side-by-side presentation
<gchristensen> you might like fossil!
cole-h has joined #nixos-dev
<red[evilred]> at first glance - that does look nice
<red[evilred]> I think the one thing that really bothers me about github is that you can't really PR from different git repos off-site
peelz has joined #nixos-dev
pmy has quit [Ping timeout: 256 seconds]
justanotheruser has joined #nixos-dev
kalbasit has quit [Ping timeout: 240 seconds]
pmy has joined #nixos-dev
thibm has quit [Quit: WeeChat 2.6]
kalbasit has joined #nixos-dev
Jackneill has joined #nixos-dev
greizgh has quit [Quit: greizgh]
greizgh has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
ris has joined #nixos-dev
FRidh has quit [Ping timeout: 265 seconds]
Scriptkiddi has quit [Quit: killed]
ajs124 has quit [Quit: killed]
das_j has quit [Quit: killed]
das_j has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
ajs124 has joined #nixos-dev
etu has quit [Quit: WeeChat 2.9]
talyz has quit [Quit: WeeChat 2.6]
etu has joined #nixos-dev
talyz has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 272 seconds]
AlwaysLivid has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
lukegb has quit [Quit: ~~lukegb out~~]
lukegb has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 272 seconds]
__monty__ has quit [Quit: leaving]