blazked has quit [Quit: Connection closed for inactivity]
zupo has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
h0m1 has quit [Quit: WeeChat 2.8]
h0m1 has joined #nixos-aarch64
tilpner has joined #nixos-aarch64
v0|d has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
vika_nezrimaya has quit [Remote host closed the connection]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bdju has quit [Read error: Connection reset by peer]
bdju has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ryantrinkle has quit [Read error: Connection reset by peer]
ryantrinkle has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
FRidh has quit [Ping timeout: 246 seconds]
FRidh has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<lovesegfault>
thefloweringash: That needs quite a bit of work, and I'm afraid it's reached the limit of my abilities :(
<lovesegfault>
I know what needs to be done: we need to always have ac_cv_func_lchmod=no to the configureFlags of packages that are built with autotools
<lovesegfault>
but I have no idea how to achieve that
<thefloweringash>
from my reading it seemed like we might be able to change the definition of /proc in the sandbox to make lchmod work
<lovesegfault>
We don't understand yet _why_ the /proc in the sandbox is insufficient for glibc's lchmod implementation
<lovesegfault>
at first we thought it was because it calls chmodat to a path in /proc, and that the sandbox's seccomp would prohibit that as /proc is not in $out
<lovesegfault>
but I built a custom Nix with all of seccomp disabled and the issue persisted
<lovesegfault>
so I don't really know
dongcarl has quit [Read error: Connection reset by peer]
nschoe has joined #nixos-aarch64
nschoe has quit [Remote host closed the connection]
nschoe has joined #nixos-aarch64
<flokli>
thefloweringash: nix does mount /proc on its own, and the redhat issue mentions something about things being broken in chroots
<flokli>
So I think it might have something to do with our /proc mount, and not the chroot itself.
orivej has quit [Ping timeout: 246 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jakobrs>
oh ty
zupo has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
<samueldr>
I may have been getting poorer performance when I both updated to unstable and the latest kernel revision, I haven't checked whether reverting the kernel upgrade helps or if it's something in nixos-unstable
<srk>
aarch?
jakobrs has quit [Quit: WeeChat 2.8]
<samueldr>
pinebook-pro
blazked has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<srk>
I'll be testing 4.19 soonish on armv7 instead of 5.6/7 but what's the good benchmark?
<srk>
kernel build I guess.. :D
FRidh has quit [Quit: Konversation terminated!]
<samueldr>
oh, for the pbp it was likely an issue with graphical stuff
<samueldr>
something in the stack isn't agreeing
<samueldr>
I *think* the devs are assuming you run mesa tip of master or something along the way
<sphalerite>
samueldr: oh, panfrost issues?
<samueldr>
no idea!
<sphalerite>
did you look at the journal?
<samueldr>
I haven't investigated,
<sphalerite>
ah ok
<samueldr>
screen draws are noticeably visible
<sphalerite>
because I was trying out panfrost on my gru-bob the other day and it had some, uh, funky issues
<sphalerite>
graphical artifacts and what I assume was kernel memory corruption
<sphalerite>
since it eventually dumped a load of rubbish across the serial line