ehmry has quit [Quit: No Ping reply in 180 seconds.]
Adluc has joined #nixos-aarch64
ehmry has joined #nixos-aarch64
srk has joined #nixos-aarch64
bdju has quit [Read error: Connection reset by peer]
justanotheruser has quit [Ping timeout: 272 seconds]
bdju has joined #nixos-aarch64
bdju has quit [Read error: Connection reset by peer]
bdju has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
<gchristensen>
hilarious.
<gchristensen>
tesla cars store syslog data on eMMC.
<gchristensen>
rolling rpi style
<samueldr>
do they _still_ do that?
<samueldr>
because it was a problem IIRC a couple years ago already
<thefloweringash>
the stock fan on the lx2k is pretty loud. admittedly I have a dev version with a broken fan controller. I tried replacing it with a noctua fan which didn't seem to be sufficient. now I also have a 120mm case fan hovering over the cpu fan, and it seems to work.
<thefloweringash>
the temperature monitors on the kernel I'm using don't work. i need to try upgrading to a newer kernel
<thefloweringash>
i also did install an independent fan controller. a little board from aliexpress that has a temperature probe, and a one-button interface to setting a fan curve. shouldn't be a problem for the proper version :-)
<delroth>
ugh, community box is down so there's no cache at all for nixpkgs master right now, and I can't even rebuild everything from scratch because stage0 stdenv segfaults on my aarch64 host :P
<delroth>
(probably because stage0 was never updated with the patchelf page size fix I implemented a few months ago)
<gchristensen>
want to help bring the community builder back up?
<delroth>
I don't even have access to the community builder
<delroth>
but if I can help in any way I'm happy to give it a shot
superherointj has joined #nixos-aarch64
<thefloweringash>
the community box and the cache shouldn't be related. why is there no cache for master?
<superherointj>
I have installed NixOS ARM in my PinePhone, but I am stuck in the login screen and the virtual keyboard does not appear. I wonder what I should be doing now. lol
<samueldr>
the cache and community boxes are not related, indeed
<samueldr>
superherointj: you successfull installed an empty system with the most minimal configuration
<samueldr>
superherointj: that does mean no users, no UI
<samueldr>
at that point here be dragons, mostly
<gchristensen>
they might both be down for the same reason though
<superherointj>
how do you issue commands? How do you edit configuration.nix and rebuild?
<delroth>
ah, maybe I'm mistaken about the root cause -- but right now there seems to be no cache and ofborg seems to be hanging on PRs
<samueldr>
gchristensen: oh, fresh builds off of hydra could be down indeed, are they?
<gchristensen>
well the aarch64 hydra builders get restarted regularly, and the OCSP issue could be keeping them down too
<samueldr>
hmm, different hardware, different ipxe or no?
<samueldr>
superherointj: I have the "demo" rootfs I personally use to test systems, but it's not really a "final" "user-friendly" image, and has some bad defaults
<samueldr>
superherointj: really, "installation" of a fresh image is still an open question for the future
<samueldr>
superherointj: I'm sure it can suck to hear this, but also understand that this also means anything is possible :)
<samueldr>
superherointj: as far as input, on my device the usb port is broken for communcations, I wonder if host mode is supposed to be working, if so you could literally plug a keyboard
<superherointj>
I have the convergence dock here. Just tried it. But no luck.
<superherointj>
Maybe it needs something?
<samueldr>
I really don't know, haven't looked yet into that, and uh, my unit being defective really puts a damper on that side
<gchristensen>
samueldr: same ipxe firmware, different hw
<samueldr>
gchristensen: yeah, I was on the fence about either it'd be the same ipxe firmware or not :)
<red[evilred]>
So I've now put that machine in a cart on two separate machines
<red[evilred]>
so it's just a question of if I'll follow through
<gchristensen>
aye, I *think* it is all the same -- I think a firmware-grade ipxe first-step loads a fresh ipxe from packet's servers
<samueldr>
superherointj: if not, with cross-compilation you cannot do as much, but you could add a `local.nix` file with some configs like user/initial passwords, ssh, maybe wifi
<red[evilred]>
thefloweringash (IRC): You have the OS booted at least righht? I can likely fight the rest as long as that works.
<samueldr>
superherointj: though this all comes back to the big issue, it's not user-friendly yet, no "PE" (phone environment) yet, and such
<thefloweringash>
dev batch was ~$200 cheaper, so I don't feel too bad about it
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
<superherointj>
Thanks for the hints samueldr. I'll give it a try!
<samueldr>
don't hesitate to ask, though I'm not always around to answer
<samueldr>
but once booted, it's a normal NixOS system, with the caveat that you don't control the booted kernel and bootloader install (yet)
<samueldr>
but you can select a generation
<samueldr>
again, open-ended questions I need to get a good answer for
<samueldr>
the limitations from android-based devices don't really apply for the pinephone, but I've modeled it in a way that imitates it better
<samueldr>
simply for the fact that this way all devices share the same abstraction for requiring kexec for generation-specific kernels
<samueldr>
and using a "golden" kernel as a bootloader
<superherointj>
PinePhone is nice because it is not Android. :-)
<samueldr>
there's enough android phones we can add to this list that it's important to make a good abstraction around it all :) https://mobile.nixos.org/devices/index.html
<superherointj>
Understable. But we can have both ways (eventually), right? That is what matters. :)
<samueldr>
but yeah, finally having "mainline-first" phones is great
<superherointj>
It is amazing tbh. Long due.
<superherointj>
Is android-burn-tool used for PinePhone too?
<superherointj>
In RockPro64 if I just "nix-build examples/demo/ --argstr device pine64-pinephone -A android-burn-tool" it will build stage-2? The part I am finding weird the 'android' part. And the 'dd' I will have to adapt it.
<samueldr>
nope, it's not even used anymore I think
<samueldr>
that was for a specific phone where `fastboot flash xx userdata` failed
<samueldr>
now I just recomment going through `adb` either from a TWRP or from a mobile-nixos stage-1 with adb enabled
<samueldr>
(on that particular phone)
<superherointj>
I was looking at wrong folder. Found Hello now.
<samueldr>
nah, you want demo
<samueldr>
hello will be more useful than the totally empty config, but useless in the end
<samueldr>
>> builder for '/nix/store/ky4ajaaisq9vynmb1ixq5iw3my4pf767-gst-plugins-good-1.18.0.drv' failed with exit code 1
<superherointj>
Has header "bcm_host.h" : NO
<superherointj>
sys/rpicamsrc/meson.build:30:4: ERROR: Problem encountered: Could not find bcm_host.h. Please pass the location of this header via -Drpi-header-dir=/path
<samueldr>
is this the examples/demo without modifications or something else?
<samueldr>
if it's something else, I guess the question is: does it build outright on Nixpkgs/NixOS? I would wager it does not
<samueldr>
>> sys/rpicamsrc/meson.build:30:4: ERROR: Problem encountered: Could not find bcm_host.h. Please pass the location of this header via -Drpi-header-dir=/path
<samueldr>
superherointj: that's my investigation without building anything
<superherointj>
samueldr, you are really good. I need to learn to do this too.. Hopefully sooner than later. :)
<samueldr>
meanwhile either you can try reverting the PR/specific commit, or use a Nixpkgs commit that built the demo rootfs successfully
<superherointj>
I am still learning the basics tbh.
<superherointj>
As it is late here, I will delay building nixos (until tomorrow likely).
<samueldr>
yeah, more than a year on this particular project (mobile nixos), and before that managing a release, and then before that getting my hands dirty in Nixpkgs helped :)
<superherointj>
It might be fixed by then (who knows).
<samueldr>
I wouldn't expect it really
<samueldr>
I would start a build with a known-good Nixpkgs revision
<samueldr>
you can know which commit ID was used for Nixpkgs
<superherointj>
Right. Makes sense. I will have to do it tomorrow anyway.
<samueldr>
no worries :)
<superherointj>
How do I set which version to use?
<samueldr>
do you know how to use NIX_PATH to point nixpkgs to a git repo, and then checkout the right commit id?
<superherointj>
I mean, how do I pin to a specific version?
<samueldr>
that's one way
<superherointj>
Yes. Using nix-channel.
<samueldr>
that's not it really
<samueldr>
since you're on your way out, better ask again how one would use NIX_PATH to point to a git checkout :)
<superherointj>
Right, I will give it a try.
<superherointj>
Have a good night too. :)
superherointj has quit [Quit: Leaving]
orivej has quit [Ping timeout: 260 seconds]
LnL has joined #nixos-aarch64
LnL has joined #nixos-aarch64
LnL has quit [Changing host]
prusnak has quit [Ping timeout: 272 seconds]
prusnak has joined #nixos-aarch64
prusnak has quit [Ping timeout: 272 seconds]
prusnak has joined #nixos-aarch64
prusnak has quit [Ping timeout: 272 seconds]
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
prusnak has joined #nixos-aarch64
NekomimiScience has quit [Ping timeout: 272 seconds]
NekomimiScience has joined #nixos-aarch64
orivej has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
alp has joined #nixos-aarch64
dongcarl has quit [Quit: Ping timeout (120 seconds)]
dongcarl has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has quit [Ping timeout: 264 seconds]
alp has joined #nixos-aarch64
kcalvinalvin has quit [Ping timeout: 256 seconds]
hyperfekt has quit [Ping timeout: 265 seconds]
kcalvinalvin has joined #nixos-aarch64
hyperfekt has joined #nixos-aarch64
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
<ardumont>
fwiw, got a successful full-disk image out of the mobile-nixos b0fe081426046ac88a5820155415299539227923 (head commit on current mobile-nixos#199) and nixpkgs 24c9b05ac53e422f1af81a156f1fd58499eb27fb repositories
<ardumont>
and for setting the NIX_PATH, i currently use a nix-build.sh script which sets the repositories accordingly and then set the NIX_PATH prior to trigger the standard nix-build referenced in the documentation
<Ke>
does it doe something useful at runtime?
<ardumont>
nope, not yet
<ardumont>
it boots and installs my configuration as i do my other nix boxes
<cirno-999>
is there a default on screen keyboard in the pp image?
<Ke>
ardumont: sure, everything apart from a working configuration is trivial
zupo has joined #nixos-aarch64
<sphalerite>
__red__: now I'm getting an LX2K. This is all your fault!
orivej has quit [Ping timeout: 246 seconds]
mvnetbiz_9 has quit [Quit: Ping timeout (120 seconds)]
mvnetbiz_9 has joined #nixos-aarch64
ky0ko has quit [Remote host closed the connection]
ky0ko has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<Ke>
honeycomb?
<Ke>
so when people are here iteratively debugging aarch64 on low powered nixos devices, how do you rebuild kernels
<Ke>
would be super nice to be able to just use mostly prebuilt kernel as source
alp has quit [Ping timeout: 260 seconds]
<sphalerite>
Ke: yep
<Ke>
I guess I should get one too
<sphalerite>
Ke: I haven't done any of that iterative debugging, but I'd probably either cross-build from a more powerful machine or use nix-shell for the iteration.
<Ke>
but you can't inject a kernel derivation to a working system, right?
<sphalerite>
uuuuh
<sphalerite>
I don't understand the question
<Ke>
like if you have natively built nixos, you can't install just a kernel on top of it
<Ke>
except by hacking
alp has joined #nixos-aarch64
<Ke>
and if you do hacking, you can just compile kernel like on other distros and then hack the initrd and bootloader
LinuxHackerman has joined #nixos-aarch64
<Ke>
speak of the devil
<LinuxHackerman>
Hehe
<LinuxHackerman>
I'm sphalerite
<LinuxHackerman>
So there are a couple of ways to achieve this
<LinuxHackerman>
It's easiest if you don't need modules
<LinuxHackerman>
Then you can just kexec the new kernel, keeping the parameters from the current boot
<LinuxHackerman>
It will try and probably fail to load modules if you're using a normal kernel in your nixos config, but that's OK
<LinuxHackerman>
But yeah I think that's the best way to iterate without full rebuilds
<Ke>
I think you can just unpack and repack existing initrd to replace the modules
<Ke>
this is "easy" to do though I am not sure how do you make the other modules available
<Ke>
probably some env or something
alp has quit [Ping timeout: 272 seconds]
<Ke>
/nix/var/nix/profiles/system/kernel-modules
<LinuxHackerman>
Yeah, thing is in that scenario you need to replace them both in the initramfs and in the running system
<LinuxHackerman>
In fact you probably don't need to repack the initramfs, you can also just concatenate in another containing the new modules
<LinuxHackerman>
Hm, actually, with that approach it can probably also load all the modules it needs before reaching stage 2
<Ke>
if you are scripting it, unpack and repack takes almost no cpu cycles anyway
<LinuxHackerman>
Iirc there's a sysctl or similar that defines the path to modprobe, and nixos points that to a wrapper that searches /run/booted-system/kernel-modules
<LinuxHackerman>
True
<Ke>
there is also an environment variable, we have a hack that uses it
<Ke>
but really, I think I am fine with just sticking with linux-5.4 until the hw breaks, the lifecycle for 5.4 is almost infinite
<LinuxHackerman>
Ha, fair enough, if all your hardware is supported
<Ke>
good enough
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Ke>
also bootlin guys have macchiatobins, but not sure if the are using them for anything
<angerman>
`uname -a` -> `Darwin DTK.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:18 PDT 2020; root:xnu-7195.50.7~2/RELEASE_ARM64_T8020 arm64`
<angerman>
we just need the `install` script fixed.
<angerman>
sphalerite: ahh, ok that's basically the patch I wanted to propose ;-)
<sphalerite>
oh right
superherointj has joined #nixos-aarch64
<angerman>
sphalerite: so take this as a confirmation that this actually *does* work :D
ryantrinkle has quit [Remote host closed the connection]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Remote host closed the connection]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Remote host closed the connection]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Remote host closed the connection]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Remote host closed the connection]
ryantrinkle has joined #nixos-aarch64
<srk>
it can emulate x86? wow.
<srk>
Rosetta, I see
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
brightone has joined #nixos-aarch64
<brightone>
Hello, has anyone tried updating from 20.03 to 20.09 on a RAM-constrained system? I'm trying to do that with Banana Pi M64 (2GB RAM), and the evaluation (not build process) makes it go OOM. Any ideas on how to make that work?
<superherointj>
activate swap?
cole-h has joined #nixos-aarch64
<sphalerite>
brightone: use swap as superherointj says, or do the evaluation on a different machine
<brightone>
Same thing happens with a 4GB swapfile. I'm gathering logs, but I have no idea what exactly is responsible for OOM. I'm pretty sure no package builds happen on device.
<brightone>
sphalerite, how would I do the latter, and what do I need to copy over?
<brightone>
Instead of running `nixos-rebuild switch` on the Pi, should I use something like `nix-copy-closure` to transfer the `nixos-system` output?
<srk>
it's possible to use nixos-rebuild --build-host and --target-host options to do that for you
<sphalerite>
brightone: make sure to set nixpkgs.system = "aarch64-linux"; if the other evaluation host isn't aarch64-linux
orivej has joined #nixos-aarch64
red[evilred] has joined #nixos-aarch64
<red[evilred]>
We don't have anyone with one of the aarchh64 macs yet right?
<red[evilred]>
a friend just got test hardware, hence the question
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<patagonicus>
The manjaro edition of the pinephone just changes the logo on the back and the preinstalled OS, right?
<red[evilred]>
sphalerite (IRC): Well, it would be rude of me to make someone else buy one and not buy one myself right?
zupo has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
john654 has joined #nixos-aarch64
<john654>
hi everyone! had anyone recent success flashing and running nixos on a rockpro64?
<sphalerite>
john654: yes
<sphalerite>
red[evilred]: angerman I think?
rajivr has quit [Quit: Connection closed for inactivity]
mhgny has joined #nixos-aarch64
john654 has left #nixos-aarch64 [#nixos-aarch64]
<superherointj>
john654, I have 3 RockPro64 running NixOS, quite happy about it.
<sphalerite>
red[evilred]: at least it looked like that from the messages angerman wrote above :)
<mhgny>
superhero, I had to switch from john to this account. Sounds great! I'd like to be happy as well. Right now the setup is one issue after another
<sphalerite>
red[evilred]: yes, now you have to buy one too! :p
<sphalerite>
red[evilred]: I'm really excited about it now and can't wait for it arrive. I just hope it won't take as long as the helios64 :D
<mhgny>
I got one, but I'm struggling with the setup. Flashing the SD card went very well but UART isn't working as expected
<sphalerite>
mhgny: helios64 or rockpro64?
<mhgny>
rockpro64
<sphalerite>
and how is uart failing?
<mhgny>
to boot is working, nix seems to be starting but I don't get a prompt to login
<superherointj>
Have you tried HDMI? It worked for me.
<mhgny>
dead. got no output
<superherointj>
Are you using an old version or current?
<superherointj>
It matters because there was a bug in dmidecode that would crash the board at start-up.
<mhgny>
superherointj, that's the guide i've been using
<superherointj>
Oh. Interesting. I never expected it would show up on searches. I'm sorry for not keeping it updated. I'll fix whatever you got wrong.
<mhgny>
I just noticed it's your guide :D thanks for this great resource
<superherointj>
You can just a pick a newer version.
<superherointj>
It it will work. Same procedure.
<superherointj>
Still it should show up on HDMI and that is what is making me wonder if you are being affected by the dmidecode crash bug or not. If you are, just by updating will solve it.
<mhgny>
I'm currently downloading the latest build. You'll get an update as soon as possible
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
<mhgny>
Hmm, this installation didn't work at all.
<mhgny>
Very unstable output over the serial console. No HDMI and the boot process seems to get stuck somewhere
<superherointj>
My monitor is 4k.
<superherointj>
I'm saying this because maybe it matters? Idk
<superherointj>
The HDMI cable had to be 2.0.
<mhgny>
I'm reflashing the SD with the latest nixos build and the uboot version mentioned in your article...another HDMI cable is the next step
<superherointj>
You can use a newer uboot.
<superherointj>
You can flash newer uboot over the same sdcard, it will work.
<mhgny>
The latest working build wasn't working. The older one seems to be working again
<mhgny>
Still no success...HDMI output still missing
<superherointj>
Are you using HDMI 2.0 if your device supports 4k that is required.
<superherointj>
At least it is how I made it work here.
<mhgny>
Its a FullHD monitor. I tried several cables
<superherointj>
Right.
<superherointj>
mhgny, I can test a newer version on my RockPro64 and update guide, so you can be sure that version is working, but that is going to take me some time, if you don't mind waiting.
<superherointj>
Have you tested 20.03 version or 20.09?
<mhgny>
I appreciate your effort
<mhgny>
It's 20.03.3263.db4....
<superherointj>
I think you should give 20.09 a try.
<superherointj>
That is what I am likely using because my boards have been upgraded to unstable.
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<superherointj>
mhgny, sometimes to turn on the RockPro64 is tricky. (We think it is turned on but it is not) Close to the USB ports, there is a white LED, is it on?
<superherointj>
It must be on.
<superherointj>
I also found out that when powering off the RockPro64, I had to take power supply off and wait a while before powering it on again. Or it wouldn't power up when I plug power back. I think it retains some power for a while and when that happens it doesn't power on automatically properly.
zupo has quit [Ping timeout: 272 seconds]
<mhgny>
superherointj, the white led is turning on. Powering the device on/off always worked like a charm.
zupo has joined #nixos-aarch64
<mhgny>
Using 20.09 right now. Still no HDMI and no proper boot...the device gets stuck after a certain time
justanotheruser has quit [Ping timeout: 272 seconds]
<superherointj>
Did you get a more current uboot too?
<superherointj>
mhgny, can you use a different SDCard?
<superherointj>
(Just in case the SDCard is corrupted - it has happened to me before.)
<mhgny>
I used the latest uboot without success. Switching back to the uboot from your article with the latest 20.09 I can boot. Still no HDMI but the SSH port seems to be open
<mhgny>
Used multiplke cards and emmc memories
<superherointj>
By any chance do you have any 4k display device?
<superherointj>
If you have, and have a HDMI 2.0, I suggest you give it a try. Because mine is using 4k. I think I did try to use FullHD but did not work - but I barely recall it.
<samueldr>
well, there will be nothing to download if there's a failure
<superherointj>
Right.
<superherointj>
Good.
<superherointj>
I am out of ideas. :(
<mhgny>
Only a 2k monitor. Nothing else... :(
<mhgny>
Thats the one I downloaded. I'm quite familiar with jenkins...so looking for the right artifact wasn't an issue at all
<mhgny>
Current progess: I can SSH into to box...but no HDMI working yet
<mhgny>
Thats actuall quite satisfying...never got this far in the booting process
<superherointj>
mhgny, just out of curiosity, how did you find that article?
<superherointj>
That address was not published. I thought it was kinda hidden. :)
<mhgny>
Desparate googling of the following keywords: nixos, rockpro64
<mhgny>
The query "nixos rockpro64" lead to your page...last entry on the first page
orivej has joined #nixos-aarch64
cptchaos83 has joined #nixos-aarch64
<angerman>
red[evilred], sphalerite: at least thefloweringash and I *do* have arm64 (aarch64-darwin) hardware.
cptchaos83 has quit [Client Quit]
<red[evilred]>
cooil!
cptchaos83 has joined #nixos-aarch64
alp has joined #nixos-aarch64
<red[evilred]>
sphalerite (IRC): pulliing the trigger - it's all our fault ;-)
<colemickens>
siraben: have you attempted to get nixos proper on the remarkable(2)? It seems like the focus was just getting nixpkgs available?
<colemickens>
also thank you, I am excited to receive it, but far more excited knowing about your work.
<samueldr>
from what I understood, it was about getting the tooling to build stuff so it runs on whatever configuration runs by default
<samueldr>
and not about producing an independent OS
<colemickens>
sure, I was just fishing for gossip if anyone had tried, but tbh I have 4 ARM devices on my desk that could use attention before a fifth arrives.
<samueldr>
hah
<samueldr>
last I looked for the remarkable (1) it seemed like a relatively standard u-boot setup
<colemickens>
I'd (jokingly) blame you but I'm pretty sure you explicitly warned me off of three of them! ha.
<samueldr>
I wonder which three
<samueldr>
I guess one's a blueline
<colemickens>
pinebook/pinephone :)
<colemickens>
although, the pinebook just works for me, and performs about as I'd expect
<colemickens>
I get a decent bit of use out of it.
<samueldr>
right
<samueldr>
probably more than I do mine, since I just don't use a laptop at all these days
<colemickens>
and then a spare rpi4 that I'm stubbornly insisting on netbooting, but I haven't put much effort into it, I don't think ti should be hard, but ipxe wasn't building for aarch64 or something like that?
<samueldr>
colemickens: you could as I do
<samueldr>
keep them in a box off your dek
<samueldr>
desk*
<colemickens>
They migrate back and forth based on how delusional I am about having time to work on them.
superherointj has quit [Quit: Leaving]
<hexa->
hm, i'm on the latest channel for nixos-20.09 and my rpi4 is building stuff since earlier this morning (~20 hours)
<hexa->
currently glibc-locales, earlier binutils, golang-1.14
<hexa->
this is a bit annoying
<andi->
aarch64 is not required for channel bumps IIRC
<andi->
and there is not aarch64 channel IIRC
<hexa->
this is the aarch64 channel though!
<hexa->
anyway, very sad :<
<andi->
nix channel...
<andi->
not IRC channel
<hexa->
yeah, I'm kidding :)
<samueldr>
the builders had a huge hiccup due to boot problems
<samueldr>
basically the OCSP server from ipxe did an oopsie
<hexa->
oh, that was related
<samueldr>
so aarch64 could have accrued many tasks
ninjin has quit [Remote host closed the connection]