<DigitalKiwi>
they want $10 for shipping a pi zero w!
<samueldr>
canakit? it's a flat~ish shipping rate
<clever>
samueldr: looks like one is a "b rev 1\n0002"
<samueldr>
so yeah, only a raspi zero will cost you :(
<DigitalKiwi>
i can get it on amazon tomorrow for ~18
<samueldr>
and dang reseller and demand means they only sell one per order
<clever>
samueldr: and the other is a "b rev 2.1 (uk)\n000e"
<DigitalKiwi>
and the 2gb is 60 haven't checked the shipping
<DigitalKiwi>
for the one with heatsink and psu
<samueldr>
their power supplies (canakit) are good for the raspi
<samueldr>
since the raspi 4 are not compliant with USB specs (again)
<clever>
samueldr: last i heard, the rpi4 has 2 usb c ports, one is power (non-compliant) and one is usb otg capable (2.0 host or slave), using the old usb controller in the cpu
<samueldr>
clever: only one type-c port
<clever>
might be mis-remembering it slight
<clever>
ly
<samueldr>
clever: but you're right, it's hooked to the old usb
<clever>
ive also seen one blog, where the guy hot-aired the usb3 controller off
<clever>
then hot-wired the pcie lanes, to the usb3 lanes
<samueldr>
if you provide power through another means, that means you can still get USB via type-c, and use the pcie interface
<clever>
and then grabbed those cheep bitcoin miner pcie extensions (that abuse usb3 cables)
<clever>
and because he did the pinout right, he could plug that extension directly into the rpi4
<clever>
samueldr: for most things, it uses the host- dir, but when it gets to libgcc, it doesnt
<DigitalKiwi>
there's the link if anyone wants one. i'm going to hold off for now, i can either find one later for about the same price, pay a little more, or be forced to get a 4 :)
<t184256>
I saw nixpkgs:trunk:cachix:aarch64-linux build succeeding, that's why I said "trunk"
<t184256>
And it had the linked ghc as a dependency
<t184256>
So, it keeps hitting one or two absolutely arbitrary limits, and this is why we can't have nice things? Sounds awful.
<gchristensen>
iirc there is at least one ghc which does compile
<gchristensen>
but GHC's team needs to figure out why it grew by 500M all of a sudden
<t184256>
kinda a strange question. Let's suppose I want to buy my own aarch64 hardware to rebuild nixpkgs with a custom prefix instead of /nix/store. Aiming for a full rebuild once in a week, for example. How stupid is this idea and what hardware would you recommend?
<simpson>
That's a great question, and I have a very similar one, but for 32-bit ARM as well. I haven't been shopping in this space in a while.
<DigitalKiwi>
not that anyone cares but i ended up buying one of those >.> it's a really good price, almost everyone is out of stock, or if they do it's $40-45-50+ USD, and it's cheaper than they're selling pi 3 b for! i'd kick myself for not getting it, and i already have cases and power supplies for it, and it's good enough for what i currently do with it, and it's better than the one it's replacing. if i got a pi 4 i'd have to buy a case, a charger,
<DigitalKiwi>
i don't have any usb C accessories/cords/hubs/etc, and i have plenty of other computers with usb 3 and gigabit lan with more power behind them that are more suitable for whatever that'd be useful for... :) and besides, who needs a powerful pi when you can use the build server? :D
<DigitalKiwi>
oh wow long message, sorry
<simpson>
Parsing errors, sorry; are you advocating a Pi 4?
<DigitalKiwi>
i got a pi 3 b+ (i'm using my pi 3 b for a project so i will no longer have it)
t184256 has left #nixos-aarch64 ["Error from remote client"]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<lopsided98>
It is frustrating that none of the kernel documentation I read mentioned that device trees are not built with '-@', making overlays practically impossible with mainline by default.
<samueldr>
yes!
<samueldr>
I saw something about that in my research for the dtbo at runtime
<lopsided98>
You have to pass DTC_FLAGS='-@' to make, but I can't figure out how to get Nix to do that
<lopsided98>
The only way I can see is through hostPlatform.platform.kernelMakeFlags
<samueldr>
I think my attempt used a patch to the kernel makefile
<samueldr>
though I wasn't successful in doing what I was doing, I believe that once I had -@ the overlay stuff did work
<samueldr>
well, go one step further at least
<lopsided98>
I'm trying to get the RockPro64 wifi/bluetooth module to work on mainline, and I was trying to enable it with an overlay but it has turned out to much more difficult than I expected.
<lopsided98>
hardware.deviceTree is kind of buggy as well - if an overlay fails to apply, the build doesn't fail, your config just ends up with no device trees in it
<samueldr>
:o
<lopsided98>
Also it calls toString on a path, which means it gets the source location for the file (in my home directory, which is not available in the sandbox) rather than adding it to the store
<samueldr>
dang
<samueldr>
you're right
<samueldr>
I presume you'll be able to open a PR with fixes?
<samueldr>
that would be lovely
<samueldr>
looking at the code, I'm curious in what ways it fails to build, but does not fail the build
<clever>
lopsided98: if you want a path copied to the store, just treat it as a string, dont toString it
<lopsided98>
clever: That's how I fixed it, but I'm not sure if that breaks other use cases somehow
<clever>
in general, you shouldnt need to use toString
<lopsided98>
samueldr: It seems to be an upstream problem - fdtoverlay always returns 0 even on failure
<samueldr>
I didn't have any way to actively test the PR at the time :/
<samueldr>
oof, that's not goo
<samueldr>
d
<lopsided98>
clever: somewhat unrelated, but grafana actually has this same problem. The reason toString is used there is that the type of the variable is not known and it might be an integer, which can't be used directly with string interpolation
<clever>
lopsided98: in what cases would it make sense for it to be either a path or an int?
<clever>
lopsided98: oh, if you do toString "${./foo}"
<clever>
then the "${ will copy it to the store
<clever>
and the toString becomes a no-op
<lopsided98>
In grafana's case it is used to map a set of arbitrary options to strings
<clever>
ah
<clever>
"${./foo}" should work around the issue
<lopsided98>
I just remembered that the problem there was a little different - the option type was a string, so I had to do "${./foo}" like you suggested, but due to how my systems are set up, normally my config is located in the store (in a custom channel), while at other times (when debugging) it is at /etc/nixos. Using "${./foo}" on a path that is already in the store adds it to the store again - so when switching from the channel to a local config
<lopsided98>
, part of my system would end up being rebuilt even though nothing changed.
<{^_^}>
Invalid command syntax
<lopsided98>
I tried to fix that by changing the option type to a path, but that just created the problem we've been discussing