cyounkins has quit [Remote host closed the connection]
<gchristensen> ~120 aarch64 jobs remaining according to the queue runner
<samueldr> 21281 in the queue summaryu
<gchristensen> yeah I see that
<gchristensen> pretty weird
<gchristensen> not sure why
<samueldr> (and nothing in i686??)
<samueldr> is eval broken?
<gchristensen> yeah, I don't know, I was asking that yesterday
<gchristensen> been trying to fix the existing queue problems before ringing the alarm bells about future jobs :P
<samueldr> probably not
<samueldr> hmmmmmmmmmmmmmmmmmm
<samueldr> only darwin jobs queued
<samueldr> oooh, one aarch64-linux
<samueldr> could... could it just have been extremely quiet?
<gchristensen> ok I'm changing one of other nodes to build big-parallel with 2 jobs and 45 cores ea
<gchristensen> well maybe?
<gchristensen> staging doesn't evaluate anymore, and staging-next has jobs
<samueldr> staging doesn't evaluate anymore?
<gchristensen> not automatically
<samueldr> right
<gchristensen> t2a-3 is now building kvm,nixos-test,big-parallel jobs
<samueldr> llvm timed out for aarch64 not sure if it's big parallel
<gchristensen> don't think so
<samueldr> there's a satisfyingly low amount of failures on aarch64 for release 18.09
<gchristensen> nice
<gchristensen> great
<gchristensen> such good news
<gchristensen> ok, I'm making all three nodes high core count, low parallel jobs
<samueldr> a chunk is from dependencies failing
<samueldr> another part from time outs, possibly mostly dependencies timingo ut
<samueldr> (I see llvm 6 comint up often)
* samueldr sits back in an appropriate manner for typing
<gchristensen> hah
<gchristensen> ehh I need to let these be, and figure out my provisioning thing.
<gchristensen> https://github.com/packethost/packet-cli/issues/12 Nix users do obnoxious things like make ~ a tmpfs
<{^_^}> packethost/packet-cli#12 (by grahamc, 20 seconds ago, open): packet-cli should obey XDG_CONFIG_HOME
<samueldr> !! forgot that I had the linux-zfs thing building
<samueldr> it failed
<gchristensen> I may have caused some failures...
<gchristensen> by prematurely deleting build users
<samueldr> :o
<samueldr> not talking about hydra
<gchristensen> oh
<samueldr> samrose: https://gist.github.com/7b37ffa4ae5112b09c8598164534e917 <- not aarch64 specific
<samueldr> it's as I suspected, linuxPackages_testing.zfs doesn't currently build
<samueldr> (which can be expected since it uses kernel APIs, which those are not 100% stable like userland APIs)
orivej has quit [Ping timeout: 244 seconds]
Acou_Bass has quit [Ping timeout: 250 seconds]
Acou_Bass has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 272 seconds]
Acou_Bass has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<samrose> thnx samueldr
zupo_ has joined #nixos-aarch64
<zupo_> Hey all! After years of being on the receiving end of Nix evangelism by friends I finally bit the bullet today and am installing Nix on my RPi 3! Tried it years ago but RPi was not well supported back then. Today I found https://nixos.wiki/wiki/NixOS_on_ARM#Installation and yep, this looks way more doable. So big thanks to whoever contributed to the images and the documentation!
<gchristensen> yay zupo_!
<makefu> zupo_: a lot of different people contributed to the article, i think without the bootstrapping of Dezgeg a lot of people were discouraged from trying. samueldr has put huge efforts into structuring, adding and cleaning the wiki article. and of course there is the aarch64 binary cache now which is mainly thanks to gchristensen!
zupo has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 250 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<samrose> samueldr: hdmi, ethernet, and USB work with 4.20-rc5, turning off zfs boot, and the diver you suggested on the bananapi m64 (in my case I had to build an sd-aarch64 image to get it working)
<samueldr> samrose: "the d[r]iver you suggested" what do you mean?
<samrose> sorry for vagueness: the "SUN8I_DE2_CCU = yes" in common configuration, building sd-aarch64 image using testing, and removing the zfs from boot.supportedFilesystems
<samrose> samueldr: ^
<samrose> I still have a branch where I saved the work I did to get the u-boot working, so I will PR that, and back track through my clone + document the wiki on what it takes to make this much work
<samrose> ah, I also followed the step of deactivating the /boot partition after copying image to emmc too
<samueldr> ah, so yeah, for ethernet here I'm thinking either u-boot inits something differently than the kernel expects (unsure if even relevant) which would be fixed at the next u-boot release if my intuition is right
<samueldr> (for my board)
<samueldr> samrose: if you're still on your first boot and ethernet works, dump the dmesg output and reboot, in case after a reboot it won't work anymore like on mine
<samrose> samueldr: ok, I will
<samueldr> that's just because somehow on first boot with 4.20 it worked, but never worked after; PROBABLY just luck
<samueldr> (on something racy)
<samrose> I haven't actually even copied image to emmc yet
<samrose> but I assume it would work
<samrose> samueldr: I copied it here in case it what you say happens https://gist.github.com/samrose/0bdb09205a75e700700fe8970276e2b4
<samrose> going to try reboot
<samrose> ethernet seems to have survived reboot on this board, running from sd card
<samueldr> nice, which u-boot release are you using?
<samueldr> (I may look at their device tree and see if there's any obvious difference related to power and/or ethernet)
<samrose> samueldr: it's actually a bit of an old one, I hadn't rebuilt a new one
<samueldr> still a thing to consider :)
<samrose> samueldr: one moment, I will check and see how old this is
<samrose> I think I actually wiped out the installed ubuntu/nix image where i built this a while back
<samueldr> on serial (and graphics output) it should say the version number
<samrose> ah when it starts up
<samueldr> if you built it from upstream with defconfig, then it's trivial enough to get what should be the same
<samrose> it's from oct 30 2018
<samueldr> so probably before 2018.11
<samrose> I built it with nixpkgs
<samrose> will reboot now and see what it says
<samueldr> oh, so most likely 2018.09
<samrose> U-Boot 2018.09 (Sep 10 2018 - 21:46:42 +0000) Allwinner Technology
<samrose> samueldr: are you using a newer version?
<samueldr> I don't think I was
<samrose> I think we end up building the same one
<samrose> however, there may be some args that are bpim64 or pine64 specific in the u-boot and trusted firmware
<samueldr> probably, except yours would be with the bananapi defconfig and mine the sopine defconfig
<samrose> yes that's right
<samueldr> did you touch the ATF release used in nixpkgs?
<samrose> samueldr: "ATF release"?
<samueldr> don't really know, you said "however, there may be some args [...] specific in the [...] trusted firmware"
<samueldr> my experience is limited in what the ATF really does here
<samrose> sorry samueldr: yes, it is limited upon review and no I did not modify ATF
<samueldr> right, so all differences should be in DTB and defconfig :)
<samrose> samueldr: I think you are right that if defconfig and DTB are reviewed you may find the drivers. I can try to help if you think it would be of help to have me look at them too
<samrose> I will be back on later tonight my time
<samrose> (not that you need my help, but if I can help somehow, I am glad to try)
<samrose> this was the actual buildUboot that I used: https://github.com/samrose/nixpkgs/blob/bpim64/pkgs/misc/uboot/default.nix#L113
<samueldr> good, as I expected
<samrose> samueldr: is it this repo? http://git.denx.de/?p=u-boot.git;a=summary
<samueldr> that's the upstream u-boot repo, yeah
<samrose> (gotta run to pharmacy but will be back and dig around in this)
<samrose> samueldr: thanks a million once again.
Thra11 has joined #nixos-aarch64
Acou_Bass has quit [Quit: byeeeeeeeeeeeeeee]
Acou_Bass has joined #nixos-aarch64
Acou_Bass has quit [Quit: byeeeeeeeeeeeeeee]
Acou_Bass has joined #nixos-aarch64