<colemickens>
I haven't tried mainline yet. Too afraid of losing an entire day to it.
<colemickens>
Supposedly mainline uboot works now too. I'd love to see a NixOS config with mainline uboot+kernel, even if some things are missing for a few more releases.
<colemickens>
actually right now I'd settle for someone properly documenting what upstream versions are needed for rpi4 h264/hevc playback -_-
<samueldr>
on the pi 4, mainline uboot (there is no OEM uboot) works, but at the time it required you to bring your own dtb for it to work
<samueldr>
not sure if they now have an in-tree u-boot
<samueldr>
they were stuck waiting on the kernel to do theirs
<samueldr>
(which I still think it's an error that the kernel has to manage what amounts to hardware description tables, those should be shipped with the device, and static~ish, and other means to work with the existing firmware should be used by the kernel...
<samueldr>
... just like they do on non-device-tree systems)
<hexa->
they probably saw that it wasn't happening any time soon
<hexa->
basically most devices supported by openwrt are built on devicetree files
<samueldr>
hm?
<samueldr>
devicetree is not something that is unique to the kernel
<samueldr>
in the end devicetrees would be used
<samueldr>
but my issue is how the kernel has decided to be the sole gatekeeper of device tree files, and that they require the right device tree files from the right kernel version for the kernel to work right
<samueldr>
you shouldn't need to update your firmware (bios) to update the kernel version
<samueldr>
but with device trees, it's pretty much that
<samueldr>
the kernel has not included a way for itself to load device trees or device tree overlays during boot (AFAIK)
<samueldr>
so they decided they own the device trees, but all firmwares now have to deal with loading it for the kernel
<samueldr>
which causes the annoying puzzle with nixos of keeping the device trees synced up with the kernels and initrds
<samueldr>
not an issue with u-boot
<samueldr>
but now try it with grub
<hexa->
Ok, gotcha
<hexa->
Thx for the primer
<samueldr>
I guess one way to rephrase it is now that device trees are the issue... they're not, they're simply another way to describe hardware
<samueldr>
and they're not even specific to ARM, or required on ARM
<samueldr>
you can have an ACPI-based ARM system!
<samueldr>
while you can also have an x86 system that at some point had a device tree in use
<samueldr>
(not sure if there are that actually boot from it)
<samueldr>
(but some x86_64 targets in coreboot IIRC use device trees in the build process)
<samueldr>
the issue is that the kernel is tightly coupled with their opinions on what the device trees should be, but they mandate the bootloaders in providing it
<samueldr>
it's not an issue if you are focused on one product, booting one kernel with one device tree, and updating that one single kernel and device tree at once
<samueldr>
but it becomes one if you have generations like NixOS, *and* want to have support for all platforms in the mainline defconfig
<ashkitten>
samueldr: you load device trees by concatenating them onto the kernel image, yes?
<ashkitten>
i don't see the problem with keeping it in sync with the kernel
h0m1 has quit [Ping timeout: 272 seconds]
h0m1 has joined #nixos-aarch64
<samueldr>
ashkitten: that's a qualcomm-ism, initially, and an android-ism maybe afterwards
<samueldr>
I wasn't thinking about mobile nixos
<samueldr>
I was thinking about mainline linux and how it's expected to boot
<samueldr>
I *believe* that this concatenated FDT (dtb) is actually handled by the bootloader (aboot or abl), so even there it ends up being a task that the kernel pushes onto the bootloader
<samueldr>
(btw, as always, I'm happy to be proven wrong when I am)
Zer0_ has quit [Quit: Leaving]
<samueldr>
on the nixos sd image, we have all FDTs sitting on storage, as is the kernels and initrd, for each generations where it changes (as a secondary nix store)
<samueldr>
hmm, not a secondary nix store, when it's on the same partition
<samueldr>
anyway, the bootloader, u-boot, then will load the right FDT by convention from that directory
<samueldr>
as it expanded the extlinux config file format to add an FDTDIR directive so all boot options can point to a different folder
<samueldr>
that's nice that u-boot has that, but if you want to use a UEFI firmware, or even u-boot's basic UEFI support, you're SOL
<samueldr>
each UEFI bootloader would need to know about the kernel-convention, somehow map the currently running system (from its innate FDT) to a file, and then load it
<clever>
currently, i'm choosing to select a DTB file, based on the arm cpuid
<samueldr>
meanwhile, the kernel already knows about those conventions, it's not far-fetched to think they *could* be appended to the image, or in the initrd, or some other mechanism like UPGRADE_ACPI, and the kernel able to choose the right one *from the knowledge it already has* about the system
<samueldr>
clever: see! you're proving my point!
<samueldr>
you need to worry about that!
<samueldr>
you only want to make a boot loader, but there, you now need to *somehow* load the right file!
<clever>
in my case, i'm acting as the firmware that runs before any binary gets loaded
<samueldr>
in that case you should have (what barebox calls) the internal FDT, which yes, you could load as a file just like you do
<clever>
but i want to support booting on different pi models
<clever>
and linux/u-boot shouldnt need special code to tell which pi model they are on
<samueldr>
but it *should*, in my opinion, be enough for the kernel that you load an FDT, and the kernel should load its linux-flavoured device tree overlay on top of that
<clever>
the firmware before them should just provide that answer in the dtb
<samueldr>
yeah
<samueldr>
but, and tell me if you disagree, you shouldn't have to sync up your device tree with whatever updated version each kernel revision wants to use
<samueldr>
right?
<clever>
right
<clever>
the dtb should only change when the hw changes
<samueldr>
thanks, as you're more deep into that than I am, it helps to see I'm not thinking completely wrong ideas
<clever>
ive even gone out of my way to explain the i2c muxing to linux via dtb
<samueldr>
yes!
<clever>
so linux can use any available i2c port
<samueldr>
but the kernel uses the FDTs as ways to add configuration options at runtime!
<clever>
rather then requiring the user to edit the dtb
<samueldr>
that's a whole other level of wrong!
<samueldr>
well, I say runtime, I mean real-early-runtime
<clever>
this tells linux to create 3 virtual i2c controllers, and to re-mux the pins of a single real i2c controller based on use
<samueldr>
in fact, personally, I am saying that kernel-managed device trees are actively harmful at UEFI adoption on SBCs
<clever>
so i can access the i2c on pins 0/1, the camera connector, or the SMPS/GPIO-expander
<clever>
without having to specially configure and pick one at boot time
<samueldr>
let me rephrase in a more clunky manner
<samueldr>
in fact, personally, I am saying that almost-mandatory-kernel-authored-but-bootloader-selected device trees are actively harmful at UEFI adoption on SBCs
<samueldr>
I say "almost mandatory" because I'm gonna hit a pedant saying "but see, the kernel boots just fine, it just lacks all the features you actually want when you use the OEM FDT"
<clever>
i'm thinking that the DTB should just describe hw, and that there should only be a few variable parts within it
<clever>
1: kernel cmdline obviously
<clever>
2: ram stuff and initrd location
<clever>
3: some status = "disabled";'s sprinkled around based on a cfg file?
<clever>
the rest should be static, based on the model/hw
<clever>
something like an rpi hat would obviously have its own overlay, to extend that base DTB
<samueldr>
even kernel cmdline, no, not as part of the internal dtb for the firmware
<clever>
the rpi also has a slightly special case, the mac addr of the ethernet
<samueldr>
the firmware shouldn't need to bother with hardware specifics!
<clever>
yeah, the bootloader should fill the kernel cmdline in, as it boots
<samueldr>
yeah, that's different a bit here
<samueldr>
it's co-opted for some divergent uses that it makes it hard to talk about
<samueldr>
and I *do* believe that the kernel should ship their own authored device trees!
<samueldr>
but they should handle the loading themselves
<clever>
one issue, is that the "proper" DTB files for the rpi, also describe how to talk to the firmware on the VPU
<clever>
and if i boot linux with those, it will crash, due to not implementing that
<clever>
they also omit hw that the firmware is meant to control
<clever>
we need to seperate the hw description and the firmware description
<clever>
raspbian also uses a dtparam and dtoverlay command for it
<ashkitten>
ky0ko knows more than me but i remember her saying that concatenating the dtb to the end of the kernel image is the proper way to do it in general, not just with qualcomm?
<ky0ko>
yes, but the raspi is special and does just about everything badly, because broadcom
<clever>
ky0ko: but i have the option of doing things differently on my rpi-open-firmware project
<ky0ko>
oh! well then, the preferable way of doing things would be to have your firmware load u-boot, with a sensible configuration that will try to load load fitimages or uimages with appended dtb from attached boot media
<ky0ko>
rather than booting linux directly
<samueldr>
though appending to the kernel still doesn't solve the problem of dealing with a universal image :(
<ky0ko>
that is what fitimages exist for, and why we use those almost exclusively in the embedded linux industry nowadays
<samueldr>
I'm off my usual computer and can't quickly look it up
<ky0ko>
fitimages effectively let you store a generic distribution kernel and all the dtb and optional overlay files for various devices in a single binary
<ky0ko>
the bootloader (almost always u-boot) that is built in to the boot firmware has an identifier for its hardware that it passes the kernel to select the correct dtb to load from the image
<clever>
ky0ko: current uboot also fails, because it tries to ask the firmware how much ram the device has
<clever>
ky0ko: but the firmware cant answer
<samueldr>
I'll have to read more on FIT images (which I already saw the name multiple times) and see if they can be a good solution
<samueldr>
those FIT images can be appended to the kernel, is that right?
<ky0ko>
fit images include the kernel
<samueldr>
ah
<samueldr>
my main concern is if the bootloader has to know too much about the format
<samueldr>
I'm thinking about e.g. using grub with UEFI
<samueldr>
whether tianocore or u-boot's basic UEFI
<samueldr>
so, without having done more research, it sounds like for FIT images the bootloader has to know about its format, right?
<ky0ko>
correct
orivej has quit [Ping timeout: 256 seconds]
<ky0ko>
iirc (i dont know the details) uefi has proven rather problematic on arm in the field, so it's generally not used, excluded from u-boot in most devices
<samueldr>
hm, that doesn't solve the "the kernel should manage its own FDTs" problem :(
<samueldr>
in non-embedded, so more serverey, it's almost exclusively UEFI
<samueldr>
but to my inexperienced self, it seems the troubles with UEFI is mainly because it wasn't in use at first, and vendors are slow on the uptake
<samueldr>
so a complete ecosystem is already quite solidly in place and
<samueldr>
oops, s/ and$//
<ky0ko>
probably mostly attributable to arm putting out the sbbi spec well before arm servers started becoming popular, and it being decent for that purpose
<ky0ko>
they also have the ebbi spec for embedded devices, but i can tell you that the opinion of ebbi in the field by most devs is "lol no"
<ky0ko>
i'm personally indifferent to it
<samueldr>
and I'm not saying other solutions are bad! I don't know enough about them, but it sure looks like _the kernel_ makes too many assumptions, and forcing the bootloader to deal with kernel-authored FDTs is, in my opinion, a bad assumption here
<ky0ko>
part of the issue here is that fdt was originally supposed to be authored by firmware vendors
<samueldr>
maybe the kernel is a bit less insistent about that, but communities sure think that tweaking what amounts to hardware description should be normal :/
<samueldr>
yep
<ky0ko>
but firmware vendors consistently put out firmwares that were broken and had unusable fdts
<samueldr>
I assume so, too, and they probably did it like vendors do
<samueldr>
hah
<samueldr>
but that's not an FDT-specific problem!
<samueldr>
(maybe worse though?)
<clever>
at least in the case of the rpi, the "firmware" is on the SD card, along with the DTB files
<clever>
so its a lot more variable then true firmware
<samueldr>
what I'm thinking is, why isn't it handled the same way as it is for ACPI?
<clever>
and with the right compiler, you can also make your own firmware
<samueldr>
or a better shared way?
<clever>
samueldr: i think the rpi4 tianocore is doing some acpi translation stuff, to support windows
<samueldr>
yep
<ky0ko>
samueldr, acpi... isn't handled well in my opinion
<clever>
acpi also has a whole bytecode thing within it
* ky0ko
looks over to a laptop that will not boot without acpi support removed from linux/netbsd kernels
<samueldr>
having the kernel force distros and bootloaders to deal with the firmware's brokenness, instead of dealing with it internally is my peeve
<samueldr>
because I sure know ACPI isn't "better" or "worse" than device trees
<samueldr>
both can be terrible, both could be good
zupo has quit [Ping timeout: 246 seconds]
<samueldr>
but the double discourse from the kernel is a drag to deal with :(
<ky0ko>
the original implementation of device trees, back in the open firmware days, was much better about that in various operating systems in my opinion and experience. broken device trees were a thing that existed and were handled in the kernel
<ky0ko>
i'm not sure what changed since then
<ky0ko>
i wish more than just devicetrees had been carried forward from the openfirmware days, i miss openfirmware
<samueldr>
I couldn't say, still relatively new and inexperienced, and definitely do not know the history
<ky0ko>
(of course i say that i miss it, but i have three different computers that run openfirmware within arms reach)
<samueldr>
heh, any of them at ARMs reach ARM?
<samueldr>
though I shold read on more about OF, I know it is/was a thing, but not much more than that
zupo has joined #nixos-aarch64
<ky0ko>
none of the OF machines i have are arm - i'm not sure if arm OF machines ever existed
<ky0ko>
there are certainly arm machines at arm's reach though
<ky0ko>
after all, i'm sitting at the same desk i work at, and i'm an embedded linux dev :)
<clever>
ky0ko: you might want to play with my rpi stuff then?
<clever>
ky0ko: if you simply `nix-build -A bootdir`, youll get a directory with a bootcode.bin file, drop it onto an SD card, and boot a pi with a 115200 baud uart hooked up, and you should get some output
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
<sphalerite>
huh, I'd expect (maybe naively) that a function like memcmp would use NEON instructions on aarch64. Yet this doesn't seem to be the case in glibc as built in nixpkgs (no use of LDP or the Q registers). Does anyone know enough to explain why it might not actually be a good idea to vectorise it, or to confirm that it probably should be vectorised?
zupo has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 246 seconds]
<sphalerite>
ky0ko: are they SPARC? :D
<sphalerite>
clever: that's just "an" open firmware for the rpi, not OpenFirmware, right?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever>
sphalerite: yeah, i dont think it has any relation to "OpenFirmware"
* srk
packaging dt-schema atm
<clever>
sphalerite: ive noticed gcc cheating, and sometimes when i run memset, it translates into a fully unrolled loop that just saves a constant to 4 offsets
<clever>
so what i thought would be a function call, turned into just 4 opcodes to save a constant to an addr
zupo has joined #nixos-aarch64
<sphalerite>
clever: hm ok, but surely memcmp should have that sort of thing built in anyway? If it makes sense performance-wise that is, which maybe it doesn't?
<clever>
sphalerite: id have to check with objdump to see what things are actually doing
<sphalerite>
clever: that's what I did :)
<sphalerite>
objdump -d /nix/store/c30q4ij77cxkgf35iig3q0zv6hv8x0ky-glibc-2.27/lib/libc.so.6 and looked at the memcmp symbol
<sphalerite>
it seems to have some optimisations for doing 32-bit/64-bit chunks separately, but no NEON AFAIU
<clever>
but thats just the fallback memcmp, for when gcc isnt cheating and trying to inline things
<clever>
youll want to compile something that uses memcmp, then objdump that
<sphalerite>
but is there a reason why the fallback memcmp shouldn't use NEON?
<clever>
not sure on that part
<sphalerite>
I mean, maybe the amount of stuff that needs to be stacked/unstacked on a call? But I imagine that could be reasoned about too
zupo has quit [Ping timeout: 260 seconds]
<sphalerite>
I don't know how sophisticated compilers are, but in the case of memcmp you have the handy size parameter which tells you how long you're going to be comparing at most…
zupo has joined #nixos-aarch64
<sphalerite>
well, first try there failed, it compiled to just "ret" because I made the function return void :)
<sphalerite>
ok, that definitely branches to memcmp. With a wonderful tail call optimisation, but no SIMD fanciness
<clever>
next thing to check out would be tools like godbolt
<sphalerite>
even if I compare with a short constant string
<sphalerite>
clever: I can't seem to come up with a memcmp call that doesn't get compiled to a memcmp call, maybe memset is a special case?
<sphalerite>
It seems memset with c=0 is a special case
<sphalerite>
that is compiling to plain NEON instructions
Darkmatter66 has quit [Ping timeout: 260 seconds]
<clever>
for me, it just compiled into 4 mov's, relative to the stack pointer (i was doing a bzero of a struct on the stack)
<sphalerite>
yeah that makes sense
<sphalerite>
but why is there no NEON for memcmp :(
<sphalerite>
I guess maybe the compiler isn't smart enough?
<sphalerite>
lol, in glibc's memcmp implementation /* BE VERY CAREFUL IF YOU CHANGE THIS CODE! */
<clever>
lol
<sphalerite>
it's… funky code
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<bennofs[m]>
Does anyone understand what happened here: https://hydra.nixos.org/build/117095669/nixlog/2 When I try to reproduce the build, I just get a successful cached build on the aarch64 community box
<bennofs[m]>
Could it be that hydra garbage collected the ELF interpreter while the build was running?
<bennofs[m]>
[i was looking at aarch64 tested job, and this is one of the causes for current failures]
<clever>
bennofs[m]: i think thats a bug in the garbage collector, thats deleting things that are in use
<bennofs[m]>
it was just a guess from me, it could also be that the file really did not exist
<bennofs[m]>
clever: do you know if the error would look different if the file really didn't exist? Also, is there a way to find out if hydra performed a GC at that time?
<clever>
bennofs[m]: if it didnt exist, its likely it would have failed again, enless its a concurrency issue in the build
<bennofs[m]>
is there a known issue in nix gc that it doesn't accurately track dependencies of in-progress builds?
<clever>
dont know if an issue is open, but ive seen it happen a few times
<bennofs[m]>
we need to do some things to increase the SNR of hydra failures for aarch64's tested job I think. Right now, it feels like almost all issues are either due to timeouts or hydra bugs
<gchristensen>
timeouts: really big jobs would do better to be labeled as big-parallel
<bennofs[m]>
do we have big-parallel for aarch64?
<gchristensen>
yeah
<bennofs[m]>
ok, I guess llvm9 then needs big parallel :)
<clever>
is it just a matter of fewer nix jobs per box, and allowing more cpu cores per nix job?
<gchristensen>
big-parallel jobs get 32 cores, and 2 jobs per machine
<gchristensen>
regular builds get 2 cores and 16 jobs per machine
<bennofs[m]>
It fails with: /nix/store/qa79fvrbxrgxx9pl1yqjmv82183z6n4s-bash-4.4-p23/bin/bash: ./obj/aux/echogs: No such file or directory
<bennofs[m]>
seems to be a missing dependency in the makefile :(
<bennofs[m]>
in case anyone reads this in the future, and has no idea how to start debugging it: I looked at where the "not found" executable is built (grep for `-o ./obj/aux/echogs` on a succeful build), then searched for that in the raw log and found out that it did not appear there
zupo has quit [Ping timeout: 244 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
noonien has joined #nixos-aarch64
<noonien>
hello!
<noonien>
i'm thinking about installing mobile-nixos on a CT100PA. i've not got one yet, planning on buying. is the installation difficult?
<samueldr>
noonien: the installation isn't really difficult
<samueldr>
unlocking it may be less trivial though
<noonien>
i see
<noonien>
i'm not really set on the CT100PA
<samueldr>
but one of the good aspects of that particular tablet is that it runs the mainline kernel, so it should get better, and more importantly, stay updated
<noonien>
are there other tablets you would recommend?
<samueldr>
none really, because right now, except for playing about, I can't recommend anything
<noonien>
i see, i'm guessing there aren't really any android tablets with mainlined kernels
<samueldr>
especially android-based tablets, there are not really many
<samueldr>
non at all with mainlined kernels
<samueldr>
there's so few android tablets
<samueldr>
hmmm
<samueldr>
not exactly true
<samueldr>
there is a bunch available online-only with mediatek chipsets from chinese OEMs
<samueldr>
but those are most likely completely non-recommendable
<samueldr>
as they most likely don't have the sources available
<noonien>
i'm want to buy a tablet for myself, and get nixos running on it. do all chromebook tablets have mainlined kernels?
<samueldr>
the chromeos team *has* to mainline all their work as a goal, or at least it was at some point if it isn't anymore
<samueldr>
though that doesn't exactly mean that all chromeos hardware is trivial to use, as sometimes there are quirks (even on x86_64) that you have ton contend with
<samueldr>
but that makes them at least better candidates of being perfect machines
<noonien>
i'll probably be looking for chromebook tablets then, see how easy it is to get customm software running on them, and then perhaps porting mobile-nixos
<samueldr>
now, as far as chromeos tablets, there are two main "families" AFAIK, the gru-scarlet family, based on the same hardware platform, Rockhip OP1 (RK3399)
<samueldr>
and the other is the x86_64 based one which I'm not familiar with
<noonien>
i'm guessing i can take a lot of inspiration from CT100PAs port
<noonien>
hmm, i see
<samueldr>
if it's another gru-scarlet, in theory it already works using that port
<samueldr>
AFAIK those are the other 2 models based off gru-scarlet
<samueldr>
now, as far as running custom software on chromeos devices? I think it'll depend on your skill level greatly, but it's on trivial end of the scale, and well documented
<noonien>
hmm, so basically they have the same specs as the CT100P
<samueldr>
yes
<samueldr>
chromeos hardware are often built off of a "platform", that platform is a basic set of hardware components that vendors can add their stylings and maybe some things to it
<noonien>
i'm not really that interested in using the phone software, as long as audio, the touch screen, and networking works, i'm good
<samueldr>
to be fair, that tablet can run "normal" nixos well too
<noonien>
i'm mostly trying to move away from google, funny that a chromebook seems like the best choice so far :D
<samueldr>
since mobile nixos is mainly a superset to abstract some details away
<samueldr>
yes, it's a bit counter-intuitive, but the chromeos team at google probably has the best hardware to respect the end-user :/
<samueldr>
they are hard to *truly* brick
<samueldr>
even if you flash a customized bios!
<noonien>
they have a bios? not just a bootloader?
<samueldr>
hm, when it comes to firmware, sometimes names can get murky
<samueldr>
everything ends up having some kind of "bios" like thing
<samueldr>
here I used bios
<samueldr>
but it's the firmware
<samueldr>
which is based on coreboot for chromeos devices
<samueldr>
(arm and x86 both)
<noonien>
ah, i see
<samueldr>
its firmware is stored on a dedicated storage, so it's not part of the main storage like popular with some ARM SBC
<noonien>
a BIOS usually does some hardware initialization, on arm devices atleast, usually there's ajust a bootloader and the kernel does the initializing
<noonien>
if that's what you mean
<samueldr>
it's... not that clear cut
<samueldr>
usually the "bootloader" here initializes some hardware, I prefer calling it the firmware
<samueldr>
u-boot is not strictly a bootloader
<samueldr>
it plays double duty
<noonien>
i see, i guess it makes sense, since the bootloader already uses quite a bit of hardware
<samueldr>
yep
<samueldr>
and on non-arm, too, it's not that clear cut
<samueldr>
since the kernel ends up initializing some hardware too!
<samueldr>
what might be better to say is that the firmware initializes as much as it needs to to allow the operating system to continue
<noonien>
yeah, and probably the display as well for status updates
<samueldr>
(and not *strictly* what it needs, sometimes more so the boot is more friendly)
<samueldr>
yeah
<samueldr>
like, initializing display and such devices IMO is part of "as much as it needs", which would be different that "as few as required"
<ky0ko>
<sphalerite "ky0ko: are they SPARC? :D"> no, the openfirmware machines i have are all powerpc macs
<ky0ko>
sphalerite
h0m1 has quit [Quit: WeeChat 2.8]
h0m1 has joined #nixos-aarch64
bqv[m] has left #nixos-aarch64 ["User left"]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
ekleog has quit [Quit: WeeChat 2.7.1]
ekleog has joined #nixos-aarch64
Thra11 has quit [Quit: WeeChat 2.8]
rsa_ has quit [Ping timeout: 256 seconds]
zarel has quit [Ping timeout: 240 seconds]
zarel has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
noonien has quit [Quit: Connection closed for inactivity]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 244 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]