<AmandaC> Oh. Finally figured out why I can't test my nix-on-droid config: `... The current workaround is to hardcode the path to the wanted proot nix store path in modules/environment/login/default.nix. ...`
<AmandaC> hydra doesn't like that kind of sandbox breaking, it seems
orivej has quit [Ping timeout: 264 seconds]
<samueldr> at the very least, with boards from good integrators that splurge for an SPI flash chip to store the firmware, this can all be abstracted away
<samueldr> but still, yuck
AmandaC has quit [Quit: Toodles]
AmandaC has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
h0m1 has quit [Ping timeout: 260 seconds]
rajivr has joined #nixos-aarch64
h0m1 has joined #nixos-aarch64
<angerman> samueldr: radxa with their rockpi did not put a spi on their board, but documented all this really well (also rockchip), so you could build this trivially. The odroid-n2 has an spi chip, still just these steps should be the bare minimum to document imho; it doesn't hurt them, and has only upsides as far as I can see. Well here we are.
<samueldr> oh, the step to build the software to put on the SPI should be documented and reproducible enough
<samueldr> definitely
<samueldr> I was thinking more about usage afterwards, where if you have it on SPI, you can generally begin thinking in terms of universal images
<angerman> I'm only learned about nixos-hardware today. 😱
<angerman> that does seem to share a bit of the same painpoints haskell.nix has though. You want something external to nixpkgs, while still being able to provide a somewhat reasonable nixpkgs combination with caching.
<samueldr> yep, a hard situation both ways :)
<samueldr> probably as many good points as bad points
andi- has joined #nixos-aarch64
<angerman> samueldr: so what we do with haskell.nix is we pin a few nixpkgs revisions and build against those in CI. The nixpkgs revisions are periodiacally updated.
<angerman> As long as you can live the nixpkgs pins (e.g. the 20.03 rev we have) you get mostly cached artifacts.
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 240 seconds]
irminsul_ has quit [Remote host closed the connection]
irminsul_ has joined #nixos-aarch64
LnL has quit [Ping timeout: 260 seconds]
LnL has joined #nixos-aarch64
LnL has joined #nixos-aarch64
LnL has quit [Changing host]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
<samueldr> blah, no video at all, whatever I do
<samueldr> this is getting out of my current skill set, sadly
<Ke> what patches do you still need outside of the video enablement
<Ke> which does not work anyway
<samueldr> need: none at all
<samueldr> want: some
<samueldr> the first three are already posted on the mailing list
<samueldr> so they are there just because they're going to be there soon
<samueldr> so let's get them tested :)
<Ke> does the USB keyboard btw work with the serial output?
<samueldr> yes
<samueldr> u-boot has a "unified" output
<samueldr> when a platform outputs to both serial and video, it is the same console
<samueldr> the four patches from dhivael are self-explanatory, two main features I want are (1) LED early on in SPL (2) "conventional" PBP-centric boot order
<samueldr> and then there's my patch that's totally useless for the "beep boop" effect, which just shows that it should now be at the default boot command
<samueldr> and finally those from thertp are those from that user that states the display is working
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
<samueldr> but if you simply build the default pinebook pro u-boot, it boots fine too, albeit without feedback for the user, and with the u-boot-rockchip-conventional boot order
<Ke> can you furiously press a key to boot an alternate kernel with the usb kb patch?
<Ke> without seeing output at all
<samueldr> it's now possible to implement that yes
<samueldr> a specific generation: quite hard though
<samueldr> the issue being that furiously mashing will get you a shell first
<samueldr> so you'd have to furiously mash
<samueldr> wait what seems appropriately long enough
<samueldr> type "boot"
<samueldr> then mash 2222222222222222222222222
<samueldr> which... might not be right
<samueldr> it might be 2
<samueldr> oops, 2[enter]
<samueldr> though if all inputs are buffered
<samueldr> you might be fine with "boot" [enter] "2" [enter]
<Ke> maybe it would not be hard to ignore most keys when checking whether to enter the shell
<samueldr> there's already a feature for this iirc
<samueldr> so that's another option
<Ke> ideally there would be no mashing, just holding some key combination
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<samueldr> oh! I have something to look into tomorrow https://lists.denx.de/pipermail/u-boot/2020-April/408104.html
<samueldr> same issue I have
<samueldr> oh, and with both devices I traced it to
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
Gaelan has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
orivej_ has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
patagonicus has joined #nixos-aarch64
<patagonicus> Hi there. Not quite aarch64, but the main channel recommended asking here anyway. :) I'm trying to run NixOS on an Odroid HC2, which is armv7l, but I can only find old references (i.e. the wiki links to images from 2018, which at least boot on a RPi3). Does anyone have pointers for how to get an armv7 machine up? Either for the HC2 or generic armv7.
<srk> patagonicus: I think you can just use generic armv7l image
<srk> and install HC2 u-boot manually
<srk> installing u-boot manually *might* not be required depending on the board, not sure
alp has quit [Ping timeout: 246 seconds]
<patagonicus> srk: Is there an image somewhere that's a bit newer? I tried the 2018/18.03 image on a RPi3, but the included version of Nix wouldn't want to work with anything newer than 18.09 nixpkgs and even there I was running into problems trying to upgrade the system.
zupo has joined #nixos-aarch64
<srk> patagonicus: Hydra builds generic images, the ones on the wiki were built by Dezgeg and are no longer updated
<srk> oh but not for armv7 yet I guess
<srk> you can cross-compile one though
<srk> (which might require using master or even staging branches)
<patagonicus> Yeah, no Hydra builds for armv7 :(
<srk> yup, there are some problems with armv7 on aarch64 vm that's supposed to build these
<patagonicus> I think it requires unstable, there was a recent-ish issue on Github about the bootstrap packages being broken and I think that hasn't been backported to 20.03.
<srk> yes, there's an open issue for the backport IIRC
<patagonicus> Hmm. The wiki describes how to build the image with qemu & binfmt, which is quite slow. I haven't looked into crosscompiling yet.
<srk> yes, that's slow and not required anymore as cross can produce working images just fine now
<srk> I've successfuly built a few recently using staging but you might not need that depending on the packages used
<srk> you might want to minimize a closure a bit with e.g. https://github.com/hexamon-tech/nixos-lorawan-gateway/blob/master/profiles/arm.nix#L10
<srk> if you don't need GUI right away
<patagonicus> I'm happy if I can just get something to boot with a working nix. :)
<patagonicus> So, I use the cross_armv7.nix and modify that a bit (minimizing packages, removing the gw bits) - how do I use it to build the SD image? I'm still getting used to Nix outside of changing the system config and rebuilding.
<srk> something like this NIX_PATH="$NIX_PATH:lorawan-gateway=$(pwd)" nix-build --cores 0 '<nixpkgs/nixos>' \ -I nixos-config=configs/cross_armv7.nix -A config.system.build.sdImage -o gw --keep-going
<srk> minus the gateway specifics :)
<patagonicus> Alright, thank you very much! I'll kick that off this evening.
<srk> yw!
<patagonicus> Or, actually, I guess it's better to spend a few minutes on it now, it's probably going to take a while.
alp has joined #nixos-aarch64
<patagonicus> Ok, I managed to remove the gw stuff and at least Nix is happy with the config and started building. :)
<srk> cool :)
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 240 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<patagonicus> https://pastebin.com/xrU5sBi1 looks like systemd doesn't want to build. This is with nixpkgs from 20.03 - should I try unstable instead? I'd prefer a 20.03 system, but I'll take unstable.
<patagonicus> Ah, no, actually it's unstable - I was building on the one machine I have that is not running NixOS, but Ubuntu with Nix.
<patagonicus> Let's see if updating the channel helps, for this machine it's not automated and I'm not sure when I last did that.
<srk> sec
<srk> you need to change that manually in pkgs/os-specific/linux/systemd/default.nix
<srk> unstable is fine
<patagonicus> srk: Oh, hmm. So, clone nixpkgs, manually change that and then set NIX_PATH="nixpkgs=/path/to/nixpkgs:lorawan-gateway=/path/to/lorawan"?
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
<srk> patagonicus: yup! except you don't need to refer to lorawan-gateway, that's only to allow to 'import <lorawan-gateway>'
<srk> patagonicus: you might want to switch to the same commit as the channel was using previously not to rebuild already done stuff again
orivej has quit [Quit: No Ping reply in 180 seconds.]
<patagonicus> Yeah, I thought that I could probably get away without the lorawan-gateway.
<patagonicus> I'll just let it rebuild, didn't take that long (and I should be working instead of doing hobby projects anyway ^^).
orivej has joined #nixos-aarch64
<srk> :))
<srk> or make hobby projects your work.. then you "just" need another hobby :D
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
adisbladi is now known as adisbladis
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp_ has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
bigvalen has joined #nixos-aarch64
bigvalen[m] has joined #nixos-aarch64
<gmr> yay! :)
orivej has quit [Read error: Connection reset by peer]
orivej_ has joined #nixos-aarch64
<gmr> bridges all the way down - did it work with the #nixos-aarch64 alias or did you have to add the freenode prefix?
<bigvalen[m]> No, it worked without freenode. All good.
<bigvalen[m]> So, I was saying in another channel, that I was trying to build a customer sdcard image for raspberryPi2. I was playing with `nix-build -j10 -A hello --argstr system armv7l-linux` first. But I'd an odd problem - sometimes, processes were hanging in an odd mmap/munmap loop. Sometimes rm, sometimes touch, sometimes gcc. For hours. It seems like a variant of -
<bigvalen[m]> has anyone seen anything like that ?
zupo has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
<srk> bigvalen[m]: that's with binfmt?
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
<bigvalen[m]> If you try build arm binaries on nixos x86, it seems to use qemu to do it.
<bigvalen[m]> So yeah, I setup binfmt, let it rip...and voila :(
<bigvalen[m]> I'm running this from nixpkgs / HEAD, as nixos-20.03 seems to define a glibc that's too old for gcc. Or vice versa.
<patagonicus> bigvalen[m]: Heh, I also ran into that. srk gave me some pointers, I'm currently trying to cross-compile an image instead of using qemu, but for RPi3.
<bigvalen[m]> I was also having problems with derivations not being in the store afterwards, but I'll sort that out another day.
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
bennofs has joined #nixos-aarch64
bennofs_ has quit [Ping timeout: 246 seconds]
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
<patagonicus> bigvalen[m]: So, is there a reason you want to use binfmt instead of cross compiling?
<bigvalen[m]> No, I'd be happy with anything that works.
<bigvalen[m]> I thought that was just how nixos-arm stuff was done.
<samueldr> it's generally done through native compilation
<samueldr> so on aarch64 hardware
<bigvalen[m]> Bonus points if it pulls pre-built stuff from a public build server.
<samueldr> and it will
<bigvalen[m]> Aaah. OK, in that case, I don't have any arm hardware running nixos.
<samueldr> patagonicus: I'm curious as to why you need or want cross-compilation (but am not saying it's wrong)
<samueldr> bigvalen[m]: yeah, the big egg or chicken problem :)
<samueldr> and with armv7l there's not really native builds yet
<bigvalen[m]> Also, RaspberryPi2 is a bit slow for compiling on. I'd hope my 8 nixos box could do the work.
<samueldr> (sorry, missed the fact it was armv7l)
<samueldr> so cross-compilation is the way you would bootstrap yourself up
<patagonicus> samueldr: Because the only existing image for armv7 I can find is from 2018 and upgrading that to 20.03 is really hard. Building a fresh image from x64 should be faster and easier.
<samueldr> yeah
<bigvalen[m]> Unfortunately, 20.03 doesn't even build for armv7l - it's got a mismatch between gcc/glibc. You have to build for master if you want something recent.
<samueldr> this repo allows you to cross-build a minimal sd image
<samueldr> that gives you a way to bootstrap yourself
<samueldr> though it won't build with the tip of unstable (unless fixed since yesterday)
<bigvalen[m]> Cool. That's basically what I was trying to do. Then random binaries started hanging during build.
<samueldr> try 22a3bf9fb9edad917fb6cd1066d58b5e426ee975 on Nixpkgs
<bigvalen[m]> I'm a little new to Nix still. What does that mean ?
<patagonicus> Ah, hmm, that also looks nice. I'll finish building what I currently have running, but that repo looks a bit cleaner for what I'm doing.
<Ke> bigvalen: probably means nixpkgs repo git commit
<bigvalen[m]> aaah
<samueldr> bigvalen[m]: nixpkgs checkout
<samueldr> yeah
<bigvalen[m]> Is there an easy way to tell that 'cross-system/build.sh' to use a specific nixpkgs repo ? Oh. NIX_PATH=~/repos/nix-pkgs I suppose
<samueldr> yep
<samueldr> well
<samueldr> NIX_PATH=nixpkgs=path/to/actual/checkout/nixpkgs
<samueldr> NIX_PATH=path/to/actual/checkout/ # would work if checkout/nixpkgs was the checkout
<bigvalen[m]> I'd like to assume i'll be doing this a bit. And want the intermediate deriviations to hang around - /nix/store/lyd1jr9rifb9vx6ivpyxi0z5jvz4chbi-glibc-2.30 - in one specific case. Is there any way of doing that, other than putting --add-root onto the nix-build command line ?
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<srk> nix.extraOptions keep-derivations = true and keep-outputs = true not sure which is which
<srk> man configuration.nix for an example mentioning these two
<bigvalen[m]> would do the job.
<samueldr> bigvalen[m]: https://logs.nix.samueldr.com/nixos-aarch64/2020-06-22 <- matrix sometimes doesn't translate well into IRC
<srk> heh, matrix forwards all the edits as separate messages it looks like
<samueldr> there's also that :)
<srk> combined with long message.. ehm :D
<bigvalen[m]> Sigh. Maybe I should just stick to IRC :)
<samueldr> I don't know about keeping intermediate derivations around
<srk> don't gc .. :(
<srk> well most should be cached anyway
<samueldr> hmm, I'm not sure that the revision ID I gave will cross compile for armv7l, I know it will for aarch64 though, which means it's way more likely to build successfully for armv7l
<samueldr> srk: yes and no
<srk> if not you can cache yourself as well
<samueldr> srk: it wouldn't have been if mobile-nixos didn't
<srk> samueldr++ :)
<{^_^}> samueldr's karma got increased to 237
<bigvalen[m]> Ah, I have gc after 10d, so maybe that'll be OK :)
<bigvalen[m]> Thanks for the help guys, that's kicking off now. I'll see what happens in an hour :)
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<colemickens> I've got a Pi and spare time, if there's anything I can do to help the pi4 pr get merged, I'd be happy to.
<colemickens> relatedly, is profspatsch here?
<samueldr> colemickens: what's to be merged?
<samueldr> profpatsch is in #nixos-dev AFAIK
<bigvalen[m]> Heh, thanks to using the git hash above, it's rebuilding a lot fewer derivations :)
<colemickens> I guess they're all merged, nice. nevermind!
<samueldr> bigvalen[m]: and more likely to succeed
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
<gmr> <srk "heh, matrix forwards all the edi"> hmm a feature disparity - would there be a better way to reveal what is happening to irc users?
<gmr> i'll just chip in and say that matrix features lower my cognative and emotional load considerably. even irc rooms as less stressful when viewed through a matrix bridge (especially if there are matrix users there and they are participating in the extra layers of meaning which it provides)
<gmr> i'll bang on a little more, even though it's offtopic: it's possible (as of very recently) to run the construct (the first real secondary implimentation of a matrix homeserver) on a raspberry pi, and there are moderation tools which means that dozens of people are doing so. when irc was in its infancy, there was no such grassroots movement. it was just big monolithic servers with mods = gods complex. there was nothing for
<gmr> irc like what leaf was to nntp
<patagonicus> Huh. Now it's trying to build efibootmgr and failing obviously. Maybe I'll try the other repo for cross compiling.
Thra11 has quit [Ping timeout: 240 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
<patagonicus> samueldr: First thing I noticed: without also bringing PATH="$PATH" into the env it fails to find nix-build. Probably because this is a non-NixOS system. Or maybe I use fish instead of bash.
orivej has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
<samueldr> yeah
<samueldr> I've had another project where `env -i` breaks PATH enough for this to matter
<samueldr> and it's also the same reason, because it's non-NixOS
<patagonicus> I'm guessing I wouldn't even need env -i, but I can see that it makes sense for reducing the number of variables.
<samueldr> it's to shield the build against impurities
<samueldr> like, even more
<samueldr> from e.g. NIXPKGS_ALLOW_UNFREE
<patagonicus> Maybe using "$(which nix-build)" could also work, without the need to figure out what PATH should be.
<samueldr> yes it will
<samueldr> that's the fix
<samueldr> (or type -p rather)
<patagonicus> Ah, yes, that sounds better than "which". :)
<srk> gmr: yup, I don't how to make this better, bridge should maybe rate limit edits and only send the last one?
<srk> gmr: it would be nice if people could run their own bridges as well :)
<srk> (easily via NixOS module)
<srk> mm
FRidh has quit [Ping timeout: 260 seconds]
DigitalKiwi has left #nixos-aarch64 [#nixos-aarch64]
FRidh has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp_ has quit [Ping timeout: 260 seconds]
Thra11 has quit [Ping timeout: 260 seconds]
FRidh has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
<patagonicus> "error: moving build output '/nix/store/0r0aj95jb5ymjvljr7q1cgvcpqplrjar-documentation-highlighter' from the sandbox to the Nix store: Permission denied" That's an error I haven't seen before.
Thra11 has joined #nixos-aarch64
alp_ has joined #nixos-aarch64
<bigvalen[m]> right image built. Writing to an SD card now :)
<patagonicus> I've kicked off the same build on a NixOS machine, we'll see tomorrow morning if that makes a difference.
<samueldr> bigvalen[m]: note that on your first rebuild on device, you're likely to have to rebuild the whole world!
<bigvalen[m]> That's ... probably fine. I might not want to do this. :)
<samueldr> if possible, you might want to prefer producing a system image for your device with the features you need in an "appliance" manner
<bigvalen[m]> Yeah, that's exactly what I'm working on :)
<bigvalen[m]> So, this is my attempt at the 'appliance' version - https://github.com/bigvalen/cross-system - but the next bit of 'weird glue' I have is that I was able to make a simple netboot image. A bzImage and an initrd. I'd love to be able to stash those somewhere on the RPi image, where pixiecore can find them. How could one...make that go ?
<bigvalen[m]> I think I'd import netboot.nix in the 'configuration.nix'. But...how I can make a build go, and make that accessible from configuration.nix (so I can tell pixiecore where to find the files), I'm a little less clear on.
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<bigvalen[m]> Actually, samueldr that image building recipe resulted in one that tries to PXE boot :)
alp_ has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr> u-boot does
<samueldr> it's part of its default boot flow
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
<bigvalen[m]> Ah. In my case it stopped there. Seems I'd a bad SD card. At least the image started up. Right, I can work out how to add a kernel/initrd to serve out over PXE tomorrow.
<bigvalen[m]> (on a working sdcard)
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
alp_ has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 210 seconds.]
orivej has joined #nixos-aarch64
AmandaC has quit [Quit: Toodles]
AmandaC has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
AmandaC has quit [Quit: Toodles]
AmandaC has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 258 seconds]
alp_ has quit [Ping timeout: 272 seconds]