<DigitalKiwi> help
<DigitalKiwi> i found raspberry pi 3b+ (used) for $33.20 USD on ebay which is a heck of a deal
<DigitalKiwi> should i get that or hold off for a 4
<DigitalKiwi> oh and there are 4 of them if anyone wants one...
<samueldr> DigitalKiwi: shoot the link, curious, though expecting shipping to me makes it prohibitively expensive :)
<DigitalKiwi> just don't buy them all before i get one :(
<samueldr> I don't know if your *should* hold off for the 4, depends on what you intend to do with it
<samueldr> if I buy one, it would be only one to validate mobile-nixos work on it
<samueldr> >> Does not ship to Canada
<samueldr> that seals the deal :)
<clever> DigitalKiwi: id say the usb3 and gigabit on the 4 makes it far better
<samueldr> though, if the intention is to test nixos releases on one, a 4 cannot substitute for a 3B+ :)
<samueldr> (same for 3B+ vs. 3B)
<DigitalKiwi> samueldr: i could buy you one and ship it to you?
<samueldr> nah, thanks though :)
<DigitalKiwi> oh and it's replacing a 3b that i bought like right before the 3b+ came out and i've been mad about it for years
<samueldr> shipping a $thing to me i would figure would cost ~20-30USD, based on shipping an SSD back to crucial the cheapest way possible
<DigitalKiwi> how much can you get a 4 for and does nixos run on it yet
<samueldr> there's a raspi4 specific image
<samueldr> there's a WIP open PR with tasks to do to get the generic image going
<samueldr> but in theory all pieces are ready
<DigitalKiwi> the only thing i've shipped to canada was a 9x11 photo mailer with my stickers and art and it wasn't too bad
<samueldr> maybe one way is cheaper than the other
<DigitalKiwi> probably too thick to send in one of those though :(
<samueldr> yeah, and it would need some protection
<samueldr> better put the money in buying "locally" (basically all the way the other side of the country)
<clever> samueldr: ive got an array of pi's, across several versions, 4 of them in total
<DigitalKiwi> heh ask gchristensen how good i am at protecting stuff
<clever> at least one is armv6 only
<samueldr> heh, some would think I have a problem
<clever> and i have the camera module too, for testing that
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<samueldr> but the first part of having a problem is admitting to having one
cptchaos83 has joined #nixos-aarch64
<samueldr> I don't have a problem, only a small sample of diverse SBCs
<clever> i also have a banana pi r1
<samueldr> three armv6 ones, 0, 0w, 1
<clever> its an allwinner a20, with a switch IC and wifi module
<samueldr> annoyingly I haven't figured out a safe way to get a 64 bit raspberry pi 2
<clever> samueldr: ?
<samueldr> same board as the raspberry pi 2, but the CPU of a raspberry pi 3
<clever> ah, those ones
<samueldr> yeah
<clever> rpi 3, b model 1.2
<clever> rpi 2, model b, v1.1, bcm2836
<DigitalKiwi> hrm raspberry pi 4 2GB is like 49 on amazon which is amusing because the 3b+ are 50+
<clever> rpi 2011, with the ram ontop of the cpu, and composite video, definitely a 1
<samueldr> clever: likely 256MB then?
<clever> rpi 2011.12, composite video, mora ram on the cpu
orivej has quit [Ping timeout: 240 seconds]
<samueldr> ah, the time 512MB raspberry pi were a novel thing :)
<samueldr> DigitalKiwi: check https://www.canakit.com/
<DigitalKiwi> but 33.20 is a lot less than 49 :( and i don't have a power supply for a 4
<samueldr> they are a known good reseller, services both northernmost countries of north america
<clever> samueldr: they both ahve samsung ram, but the chip#'s are different
<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> and now he has an external pcie slot!
<samueldr> now imagine having multiple PCIe slots
<samueldr> (the link to the project you were talking about is in the article)
<DigitalKiwi> that one that's 60 before shipping (which is probably 10?) is 63 on amazon (and it's the canakit one) and would get here sunday
<clever> samueldr: yep, there it is
<DigitalKiwi> mhr
v0|d has joined #nixos-aarch64
<clever> samueldr: and yeah, as i suspected, the problem is getting an arm build of gpu drivers
<samueldr> not entirely
<samueldr> it's the same issue as many arm systems
<samueldr> they are not configured to leave enough space in the PCIe BAR
<samueldr> something I'm not qualified enough to understand yet
<samueldr> but something about address space being 32MiB
<samueldr> (for the RK3399 boards)
<samueldr> and the rpi4 has the same issue basically
<clever> also, i'm attempting to get the vc4 toolchain built, under nix
<samueldr> I dare you
<clever> make[2]: Entering directory '/tmp/nix-build-gcc-vc4-stage1.drv-0/source/vc4-elf/libgcc'
<clever> Makefile:169: ../.././gcc/libgcc.mvars: No such file or directory
<clever> currently dealing with this bug
<clever> [nix-shell:/tmp/nix-build-gcc-vc4-stage1.drv-0/source]$ find -name libgcc.mvars
<clever> ./host-x86_64-pc-linux-gnu/gcc/libgcc.mvars
<clever> its looking in the wrong directory
<clever> [nix-shell:/tmp/nix-build-gcc-vc4-stage1.drv-0/source]$ cp -vi host-x86_64-pc-linux-gnu/gcc/libgcc.mvars gcc/
<clever> and that may help?
<clever> ../../.././libgcc/libgcc2.c:26:21: fatal error: tconfig.h: No such file or directory
<clever> ./host-x86_64-pc-linux-gnu/gcc/tconfig.h
<clever> something feels off, like its working relative to the wrong dir
<samueldr> could tha makefile expect to be ran from a makefile like one level upper?
<clever> [nix-shell:/tmp/nix-build-gcc-vc4-stage1.drv-0/source]$ make
<clever> already using the root Makefile
<samueldr> something like a "main" makefile that is used to do multiple tasks?
<clever> that one runs several configure scripts, and makefiles
<DigitalKiwi> huh 60 for the 4gb on ebay
<DigitalKiwi> hmm and others for less
<clever> samueldr: it feels like something should have made (and used) host-x86_64-pc-linux-gnu/libgcc/
<clever> make[2]: Entering directory '/tmp/nix-build-gcc-vc4-stage1.drv-0/source/host-x86_64-pc-linux-gnu/gcc'
<samueldr> would it be piggybacking off a prebuilt toolchain?
<clever> samueldr: its a cross-compiler, from x86 to vc4, and the only thing ive given it is a vc4 binutils
<clever> and vc4 lacks an mmu, and i dont know of anybody that has ran linux on it
<clever> so think of vc4 more like a micro-controller
<clever> make[2]: Entering directory '/tmp/nix-build-gcc-vc4-stage1.drv-0/source/vc4-elf/libgcc'
<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 :)
<clever> 7 $ /build/source/libgcc/configure --srcdir=../.././libgcc --cache-file=./config.cache --enable-multilib --with-cross-host=x86_64-pc-linux-gnu --disable-static --prefix=/nix/store/ciqi0qjw50fj8mdqmwlziwl6h4a krmmx-gcc-vc4-stage1 --disable-nls --disable-ssp --without-headers --with-newlib --disable-decimal-float --disable-threads --disable-libatomic --disable-libitm --disable-libsanitizer --disable-libquadmath -- disable-lto --enable-sj
<clever> samueldr: i think something put the state into vc4-elf/libgcc, when it should have been host-x86_64-pc-linux-gnu/libgcc ?
<samueldr> I'm not so hip on building cross-compilation toolchains :) sorry
<clever> --with-target-subdir=vc4-elf --build=x86_64-pc-linux-gnu --host=vc4-elf --target=vc4 -elf
<clever> that doesnt look right....
<clever> thats my reference
<samueldr> might be annoying to do, I know it is to me, but maybe try building it first on non-nixos to sanity check it works?
<samueldr> I know, "non nixos", what's that?
<clever> lol
<clever> oh, i notice its also doing an out-of-tree build
<clever> *adjusts nix expr*
<DigitalKiwi> samueldr: likely arch linux based on a lot of users
<samueldr> hm?
<samueldr> there are no operating systems other than nixos
<samueldr> prove me wrong
<insep[m]> pmos?
<samueldr> oh, forgot about android, which I'm trying to make go away
<DigitalKiwi> "non nixos" there are a lot of former arch linux users in #nixos
<clever> i was once a gentoo user
<samueldr> insep[m]: I'm joking here :) and wasn't talking about mobile operating systems
<DigitalKiwi> clever: i'm so sorry
<samueldr> clever: yeah, and you stopped being one since there's no such thing as gentoo :D
<clever> DigitalKiwi: nix gives you all of the power of gentoo, without all of the pain!
<clever> either of you heard of twitch installs arch?
<clever> what if somebody setup a twitch installs nixos? lol
<samueldr> curl https://to/configuration.nix > /etc/nixos/configuration.nix && nixos-install
<samueldr> or something similar
<clever> i would secretly leave justdoit installed
<clever> so when everybody gets stuck, i can "justdoit" and its done, lol
<clever> the challenging part, is that every single viewer in the twitch stream, is going to be fighting over the keyboard
<clever> changing to an out-of-tree build seems to have done it
<insep[m]> <clever "DigitalKiwi: nix gives you all o"> ok then, how do i compile all the packages with -march=native?
<insep[m]> excluding firefox and libreoffice
<clever> insep[m]: you can just chuck an overlay in, that mutates stdenv.mkDerivation
<clever> but then you loose the power that a binary cache provides, and sharing binaries between machines
<insep[m]> thanks
<clever> samueldr: gcc fixed, the relative paths in the new vc4 code are broken
<clever> samueldr: it only builds if you ../gcc-vc4/configure, and breaks if you ./configure
<clever> 138 AS = vc4-elf-as
<clever> hmmm, the makefile knows which as to use
<clever> yet it still uses plain `as` (the x86 one)
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
ris has quit [Ping timeout: 258 seconds]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
LnL has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
t184256 has quit [Quit: Gateway shutdown]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
t184256 has joined #nixos-aarch64
<t184256> I have a question, nixos-aarch64
<t184256> ghc builds time out all the time on Hydra, why not raise the timeout?
<gchristensen> there are two problems with ghc on aarch64
<gchristensen> (1) it takes a long time (2) it is actually too big
<t184256> Too big for what?
<gchristensen> ^
<t184256> why not raise the size limit as well?
<t184256> also, weird, I do remember it being in the cache a mere month ago or so
zupo has quit [Ping timeout: 265 seconds]
<t184256> gchristensen: but it builds fine on trunk: https://hydra.nixos.org/build/102779522#tabs-buildsteps
<gchristensen> "trunk"?
<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"]
t184256 has joined #nixos-aarch64
<DigitalKiwi> there are 3 more on ebay if anyone wants one it was 35.52 after tax free shipping https://www.ebay.com/itm/Element14-Raspberry-Pi-3-B-Motherboard/133205084138
<DigitalKiwi> i considered buying 2 but it took me long enough to commit to the one :(
<DigitalKiwi> did the entirety of my original message go through or was it just that it was gibberish
<DigitalKiwi> it should have ended with ' :D '
<simpson> Yes. Also I understand now, thanks.
<DigitalKiwi> (there was a previous conversation ~12 hours earlier that you probably missed)
<simpson> Ah, okay, I see.
orivej has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-aarch64
<t184256> How long would a nixpkgs rebuild take on RPi4? Day? Week? Month? More?
<simpson> Probably months, *but* I think that most folks just care about bootstrap and their own leaves, which hopefully would only be a day or two.
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
<samueldr> it would also be highly dependent on the backing storage I suppose
<samueldr> I/O is what kills perfs for most uses in my experience
fooker has quit [Remote host closed the connection]
<t184256> I has SSD over NFS in mind
orivej has quit [Ping timeout: 268 seconds]
ris has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-aarch64
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