justan0theruser has quit [Ping timeout: 250 seconds]
figgyc has quit [Quit: No Ping reply in 180 seconds.]
figgyc has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
orivej has joined #nixos-aarch64
fooker has quit [Ping timeout: 246 seconds]
fooker has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
pinkieval has quit [Excess Flood]
pinkieval has joined #nixos-aarch64
noonien6 has joined #nixos-aarch64
noonien has quit [Ping timeout: 252 seconds]
noonien6 is now known as noonien
davidtwco has quit [Ping timeout: 246 seconds]
davidtwco has joined #nixos-aarch64
steveeJ has joined #nixos-aarch64
cole-h has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 252 seconds]
alpernebbi has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<sphalerite>
samueldr: so it boots to the screen successfully with that PR applied, but my laptop isn't detecting it on USB
srk has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 3.1]
h0m1 has joined #nixos-aarch64
ib07 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
h0m1 has quit [Quit: WeeChat 3.1]
h0m1 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bpye>
So I’ve ended up with an ARMv7 board (really a Zynq FPGA board) - what’s the current status for ARMv7, either in unstable or 20.09. I don’t have any fast ARMv7 machines currently setup, I do have an old TK1 which was at one point kind of fast, but I suspect qemu-user on my modern desktop is faster?
<LinuxHackerman>
you may be underestimating how slow qemu-user is
<LinuxHackerman>
ARMv7 is still difficult any way you turn it.
zupo has joined #nixos-aarch64
<hexa->
and we don't have a proper cache for armv7
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
aleph- has quit [Quit: WeeChat info:version]
aleph- has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<sphalerite>
I'm so confused by nixos-mobile's example system, it being xfce but having KDE icons x)
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Remote host closed the connection]
ryantrinkle has quit [Ping timeout: 252 seconds]
<aleph->
heh
<bpye>
I wonder if I could get an ARMv7 build built on AWS - the Graviton parts should do 32 bit execution
rajivr has quit [Quit: Connection closed for inactivity]
<gchristensen>
no you can't
<gchristensen>
to properly do it you need to get the system running in 32 bit mode, not just 32bit execution
<gchristensen>
since programs can detect cpu features
<bpye>
Ah damn - that’s annoying. So we really are stuck with just older hardware or user emulation for ARMv7 native builds?
<gchristensen>
some aarch64 cpus can go in to a 32 bit mode
<gchristensen>
graviton cannot
<bpye>
Right, for example the A72 on the Pi4 can I guess. I suppose I also have a USB 3 SSD I could use there for storage so that may not be entirely terrible…
<samueldr>
sphalerite/LinuxHackerman have you tested the JumpDrive image?
<samueldr>
I know my initial device from Pine64 has completely broken USB, more broken than the expected brokenness
<samueldr>
maybe yours does too?
<samueldr>
sphalerite: because I was pushing for breeze icons to be used in Nixpkgs things, like the grub boot menu for the iso, and the nixos wiki, before we had the site redesigned
<bpye>
gchristensen do you know what apps are doing to detect the platform that breaks ARMv7 on ARMv8 builds? If for example it’s just uname I wonder if you could hack around that and get a fake uname passed through…
<gchristensen>
iirc compiling and running programs
<gchristensen>
seeing if the CPU can do it
<samueldr>
there's already a hack that does some of it, called "personality" in the kernel, but the personality stuff for ARM is much much less strong than on x86
<gchristensen>
as always, when it comes to ARM, samueldr knows way better than I do
<samueldr>
and yes, gchristensen was also right on the button
<samueldr>
when things detect through testing
<samueldr>
that will fail
<samueldr>
already fails on e.g. x86_64 too
<samueldr>
for things like SSS[...]E X.Y things
<gchristensen>
are those problems somewhat less common in x86 b/c there is less pick-and-choose when making the chip?
<samueldr>
nah, probably because we all end up using new enough hardware
<samueldr>
see the issues with that wendy, was it?, build machine
<simpson>
Somewhat. There's no el/BE choice on x86, vectorization has been mandatory for decades, and ISA extensions are gated rather than versioning the entire ISA.
<qyliss>
I've run into people who can't use the NixOS binary cache on x86 because their CPUs are too old
<samueldr>
exactly
<samueldr>
qyliss: thanks for having actual metrics
<gchristensen>
ah
<qyliss>
metrics?
<samueldr>
well
<samueldr>
you know of people
<samueldr>
I simply theorized people!
<qyliss>
oh
<qyliss>
yes
<qyliss>
I helped one on IRC once
<gchristensen>
sounds hard to deal with
<samueldr>
I tried dozens of time to get people to think about it
<samueldr>
that's our worst ambient impurity I think
<samueldr>
because it's totally hidden until it's not
<qyliss>
in theory it should be fine
<qyliss>
but it breaks when packages try to detect CPU features at build time
<hexa->
qyliss: so they lack cpu features we use as baseline?
<qyliss>
this person in particular had problems with ffmpeg
<qyliss>
hexa-: no, they just lack CPU features the build machine had and packages auto-detected even though we don't enable them
<hexa->
ah ok
<qyliss>
which is much worse because it's impure
<hexa->
yep
hexa[m] has left #nixos-aarch64 ["User left"]
<qyliss>
o_O
<qyliss>
oh the matrix version
<hexa->
hm?
<qyliss>
I thought you'd left just after talking to me
<hexa->
hah, no :D
<hexa->
you just highlighted me here and over there
<qyliss>
and was worried I'd offended you somehow lol
<hexa->
that was once too much
<hexa->
matrix irc bridging is the worst
<samueldr>
qyliss: that's the probleme exactly, build time detection of features
<samueldr>
we should run R13Y on the oldest core duo 64 bit machines
<qyliss>
yeah
<qyliss>
strong agree
<samueldr>
or maybe equivalently old AMD machine _too_
<qyliss>
also agree
<gchristensen>
mail me som e:0
<samueldr>
weren't they talking about retiring a server "because it had too old hardware"?
<hexa->
wendy doesn't do sse4.2
<hexa->
iirc
<samueldr>
yeah, I wondered what _else_ could be missing
<samueldr>
ideally we'd want the maximum amout of missing features
<gchristensen>
I like the idea of applying pressure from multiple angles
<samueldr>
probably want to trawl on ebay
<gchristensen>
I'm not going to buy anything but if someone wants to mail me stuff
<samueldr>
but first check on e.g. wikipedia for the oldest xeon features
<samueldr>
let's not make those builds needlessly be too slow
<gchristensen>
+1
<bpye>
On x86 can’t we start VMs with arbitrary CPUID? If something attempts to run without any detection it still may not work, but they *should* check first…
<samueldr>
*maybe* with ryzen it finally reached the level of being to parity with the older slower core duo
<samueldr>
(maybe especially not in raw compute, but other things around like I/O?)
<bpye>
I guess that’s my point, KVM would let you manipulate the reported CPUID but if something just tried to run AVX512… then you can’t fix that
<qyliss>
btw, for ARMv7, my ARM expert friends (one who used to work there, and one who's a pkgsrc committer) tell me the way to go is an emag ampere, which is a powerful aarch64 computer that can do 32-bit userspace
<gchristensen>
yup
<samueldr>
well
<samueldr>
it's armv8, not armv7!
<qyliss>
oh :(
<samueldr>
but it's fine enough
<samueldr>
if we forget about detection of features like ssse4.2
<samueldr>
we already proved it works
<gchristensen>
I thought it could go in to 32 bit mode
<samueldr>
and a VM under armv8 32 bit works well enough we think
<samueldr>
yes
<samueldr>
armv8 is not 64 bit only
<gchristensen>
right
<simpson>
To ask a stupid question, how strict is the native-compile requirement? Or is that exactly what's being discussed?
<gchristensen>
okay
<samueldr>
they even sell actual silicon that's only 32 bit and armv8
<qyliss>
I wonder if less build-time feature detection would happen if we always used cross compilers
<samueldr>
simpson: I think maybe it's what we're talking abot