gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 245 seconds]
lassulus_ is now known as lassulus
sir_guy_carleton has joined #nixos-dev
init_6 has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar_ has quit [Quit: jtojnar_]
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
orivej has joined #nixos-dev
adisbladis has quit [Quit: WeeChat 2.1]
adisbladis has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
<ekleog> (from triage) I think this is ready for merge https://github.com/NixOS/nixpkgs/pull/44602 , and thus this for closing https://github.com/NixOS/nixpkgs/issues/44254
<{^_^}> #44602 (by mat8913, 6 weeks ago, open): Workaround for issue #44254 (Steam cannot connect to friends network)
<{^_^}> #44254 (by mat8913, 7 weeks ago, open): Steam cannot connect to friends network
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
vcunat has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 244 seconds]
init_6 has quit []
_rvl has quit [Remote host closed the connection]
_rvl has joined #nixos-dev
vcunat has quit [Quit: Leaving.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 244 seconds]
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
<srhb> Can someone restart https://hydra.nixos.org/build/81861609 ? It's a completely bizarre test failure, it looks as though `cat ChangeLog.md` received SIGTERM during the test suite.
xeji has joined #nixos-dev
<gchristensen> srhb: I gave you the ability to restart jobs
<ekleog> (btw, ping review for https://github.com/NixOS/nixpkgs/pull/44968 , shouldn't be really hard :))
<{^_^}> #44968 (by Ekleog, 5 weeks ago, open): wasm-gc: init at 0.1.6
<srhb> gchristensen: Thanks!
jtojnar has quit [Quit: jtojnar]
jtojnar_ has joined #nixos-dev
<aszlig> Mic92: i thought about using "printf '\x7FELF' | cmp -n 4 - somefile" instead
<aszlig> this should quickly terminate for non-ELF files
<Mic92> aszlig: I thought about not using shell. it is currently terrible slow when scanning large electron apps.
<aszlig> Mic92: same as for games (the original reason why i wrote the hook), especially when they have several gigabytes of assets
<aszlig> Mic92: yah, when looking at the magic file for js, this is quite expensive
<aszlig> Mic92: ah, no... it isn't it's only looking at the first line
<aszlig> but still, eg. if you have a large file: read(3, ..., 1048576) = 1048576
<aszlig> so it reads at least 1 mb off every file
<aszlig> so i'd just do that cmp as i wrote before and then check whether it contains a RTLD
<aszlig> or better: just check whether it has PT_INTERP
xeji has quit [Quit: WeeChat 2.1]
jtojnar_ has quit [Quit: jtojnar_]
jtojnar has joined #nixos-dev
<aszlig> Mic92: can you check whether this patch works for statically compiled elfs?
<aszlig> this should now also be much faster identifying ELF files
<clever> aszlig: beware of UPX, it claims to be a static ELF, but then uncompresses a dynamic ELF and fails on nixos
<aszlig> clever: yeah, but that's probably not something we need to take care of in autoPatchelfHook
<aszlig> otherwise we'd need to recursively look into archives as well
<aszlig> for UPX and others, this usually is something that runs in unpackPhase
<aszlig> (or even later, but i don't think at fixupPhase)
<clever> aszlig: what is the main goal of that hook? since the cc-wrapper sets rpath automatically
<aszlig> clever: the main goal is that it automatically does patchelf on all executables and finds the dependencies according to buildInputs
<aszlig> clever: so this is only needed for proprietary software
<clever> ah
<clever> and ive been telling people to lib.makeLibPath in a let block, and to just ignore buildInputs
<clever> aszlig: there is also the issue of dlopen stuff, where you cant shrink-rpath
<clever> and an automated rpath feels like it would bloat the closure a lot more
<Mic92> clever: It works pretty well actually and fix more stuff then a human would do.
<Mic92> especially for complex software new files can be easily missed out
<gchristensen> fyi: one of the packet machines has bad RAM
<srhb> gchristensen: epyc?
<gchristensen> t2-4
<srhb> Iiiinteresting.
<gchristensen> is epyc acting up?
<srhb> I was hoping so, to explain the bizarre failure I've seen earlier, but disregard for now since it's only the one.
<srhb> What does bad RAM entail? I've never thought of that. Potentially need to rebuild the whole tree forcing new hashes?
<gchristensen> no, it has ECC
<srhb> Ah, ok.
<gchristensen> so the system faulted and doesn't boot reliably. working on fixing it with Packet, though it probably means a new machine :)
<srhb> OK, that sounds much more bearable. :-)
<gchristensen> imo, ECC is basically almost always worth it if you're working on long-term stuff
<srhb> Yes, no kidding.
<gchristensen> (I can also be picky when I don't really actually _buy_ much hw)
<samueldr> my workstation has ECC ram; it caught two bit flips since I got it about a year ago
<clever> gchristensen: http://dinaburg.org/bitsquatting.html is what happens when you lack ECC
<gchristensen> yeah I've seen that X)
<clever> the crazy part, is that one of the machines that flipped a bit, cached the reply, and served the test page to 100's of users
<aszlig> clever: the auto patchelf is done after shrinking rpaths, so they won't be conflicting
<clever> aszlig: ah, but shrink itself can cause problems with dlopen
<aszlig> clever: well, sure, but that's why there is 'runtimeDependencies'
<aszlig> clever: usually software distributed in binary form do not even include these rpaths
<aszlig> clever: they just assume that everything will be in /usr/lib and that's it
orivej has joined #nixos-dev
<elvishjerricco> How should I get feedback on https://github.com/NixOS/nix/pull/2423?
<{^_^}> nix#2423 (by ElvishJerricco, 1 week ago, open): nix build: Print result paths to stdout with --no-link
<gchristensen> today is "graham breaks the builders day" so bear with me
<elvishjerricco> gchristensen: Sounds like fun :)
<gchristensen> not so fun ... :) was hoping for quick maintenance hehe
jtojnar_ has joined #nixos-dev
<Mic92> Can I get merge access for NixOS/systemd?
<samueldr> domenkozar may be the one handling accesses, not entirely sure though ^
<Mic92> we sometimes lack a bit of systemd maintainers with time on there hand
<Mic92> *their
<globin> +1 ^ niksnut, domenkozar ^
<gchristensen> it looks like the aarch64 builder could be down until tomorrow, sorry everyone
jtojnar has quit [Remote host closed the connection]
jtojnar_ is now known as jtojnar
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
goibhniu has quit [Ping timeout: 260 seconds]