<flokli>
hmm, apart from libgpg-error, what's left? seems zstd trying to invoke the wrong cmake (as seen in the discussion about btrfs-progs too)
<samueldr>
if you're deactivating all filesystems support as in my cross-builds, good question
<samueldr>
I'm finishing up a thing and can try it out
<samueldr>
(results may take some time to trickle in)
<flokli>
I mean, it's literally only zstd left
<flokli>
which is a bit confusing, cmake is in nativeBuildInputs
<flokli>
and nowhere in buildInputs
ryantrinkle has joined #nixos-aarch64
<flokli>
(I reverted the libgpg-error bump for now)
<flokli>
fixed
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<flokli>
I was mistaken - the first zstd built
<flokli>
I fear https://github.com/NixOS/nixpkgs/pull/78910 broke cross support, and some of the overrides in 414da94fedd80cac992df835dfbd4a1efd388395 don't properly work with cross
<{^_^}>
#78910 (by yorickvP, 20 weeks ago, merged): libarchive: link to zstd (split zstd output)
<flokli>
and the cmake there is cmake for aarch64, not a native one
<flokli>
no, not reverted
<flokli>
it has been a bit of a mess in that PR
<Ericson2314>
oh ok
<Ericson2314>
well, I should finish off gpg-error
<Ericson2314>
before dipping my brain in other ones
<flokli>
heh, yeah :-)
h0m1 has quit [Ping timeout: 246 seconds]
<delroth>
re: cross-nixos, is there an easy way to build a VM for a given nixos system that is cross-built? something like an equivalent to nix-build -A vm that actually uses the right qemu package etc.
h0m1 has joined #nixos-aarch64
<flokli>
uff. It's done
<flokli>
so, the NetDBus PR from master, and reverts of 683004d092e6c4b5dc68d40684e8ecf65c87c1fc (libgpg-error) and 414da94fedd80cac992df835dfbd4a1efd388395 (libarchive zstd) get me a successful build
<flokli>
with polkit and udisks disabled. otherwise pretty standard
<flokli>
hell yeah
<flokli>
pushed to flokli/nixos-cross
<samueldr>
delroth: good question, I think the missing bits are setting up the vm scripts up
<flokli>
and off to bed! :-D
<samueldr>
(it would be emulated, no hw virt obv.)
<gchristensen>
g'night flokli!
<samueldr>
good work again flokli, thanks
<flokli>
merci beaucoup!
<samueldr>
drôle de fléchissement, mais ok
<flokli>
I'll see if I can wire my brain around btrfs and the zstd stuff tomorrow if noone else did till then :-D
<Ericson2314>
flokli: gpg-error works
<flokli>
Ericson2314++
<{^_^}>
Ericson2314's karma got increased to 7, that's Numberwang!
<flokli>
<3 <3 <3
<flokli>
o come on. gchristensen, more karma please
<Ericson2314>
flokli: so what is the current sympotom of the zstd problem?
orivej has quit [Ping timeout: 264 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: 265 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 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 quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
claudiii_ has quit [Read error: Connection reset by peer]
angerman has quit [Ping timeout: 240 seconds]
TheNumb has joined #nixos-aarch64
pkral has joined #nixos-aarch64
angerman has joined #nixos-aarch64
NekomimiScience has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
claudiii_ has joined #nixos-aarch64
Guest42512 is now known as JJJollyjim
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
irminsul has joined #nixos-aarch64
<irminsul>
samueldr: the mobile nixos kernel doesn't have userspace crypto access enabled so I need to rebuild to run cryptsetup benchmark :(
<irminsul>
def fixable though
<samueldr>
*for that device (and possibly other)
<samueldr>
I really need to figure out which configs we need enabled
<samueldr>
and a linting step that checks them
<irminsul>
idk how that kind of option gets enabled in nixos -- it "just worked" when I had luks partitions so I'm tracing those expressions to find the flag
<samueldr>
yeah, mobile nixos doesn't use the automatic options handling of nixos
<samueldr>
which may or may not be a problem, still not sure
orivej_ has joined #nixos-aarch64
<samueldr>
for quirky devices and source trees, so mostly android-based devices, it really makes sense to have the full configuration laid out
<samueldr>
for mainline kernels, less so
<samueldr>
or mainline-based, at least
orivej has quit [Ping timeout: 240 seconds]
<samueldr>
though I guess the actual end goal is that however the configuration is done, it should always end up linted and validated
orivej_ has quit [Read error: Connection reset by peer]
<samueldr>
so if you need algif_skcipher, CONFIG_CRYPTO_USER_API_SKCIPHER is the option to enable
<samueldr>
and indeed # CONFIG_CRYPTO_USER_API_SKCIPHER is not set
<samueldr>
you can either use `bin/menuconfig` or edit the file manually, though editing the file manually *sometimes* doesn't work if there are multiple interlinked dependenceis
<samueldr>
dependencies*
<samueldr>
and then it's preferrable to run bin/kernel-normalize-config after manually editing, it will resolve those dependencies
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
quinn has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<irminsul>
ooh, nice! that goes in the list with godbolt and felixcloutier
<samueldr>
hm?
<samueldr>
ah, cateee as a reference site?
<samueldr>
cateee is really nice to also know about the *history* of those options
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
cole-h has quit [Ping timeout: 240 seconds]
orivej_ has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
cole-h has joined #nixos-aarch64
irminsul has quit [Remote host closed the connection]
irminsul has joined #nixos-aarch64
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
<irminsul>
samueldr: is the lack of kexec the only thing preventing mobile-nixos from reflashing its boot partition while running?
<irminsul>
possibly a weaker thing than "reflash" is appropriate
orivej has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
<samueldr>
irminsul: definitely not, it's not even relevant to reflashing it :)
<samueldr>
irminsul: the reason it's not done is because I need to stop and think about a good way to abstract the different system types
<samueldr>
ideally the user experience should be the same for all four
<samueldr>
though I don't know yet if it should happen automatically (spooky!) or only through a specific action
orivej has quit [Ping timeout: 246 seconds]
<samueldr>
with that said, kexec support will allow you to boot any other kernel from that "stage-0" step
<samueldr>
and without "reflashing"
<samueldr>
hmm... qemu-startscript will not need an abstraction for upgrades, but the planned UEFI system type will :)
orivej has joined #nixos-aarch64
<irminsul>
yeah I'm sorta thinking of the how to translate the difference between `nixos-rebuild boot` (ideally: a new config gets put in the right place and the bootloader phase will kexec that) and `nixos-rebuild boot --install-bootloader` (more akin to "reflashing")
<samueldr>
at the very least I think your intuition about it being "install-bootloader" and "rebuild boot" is good
<samueldr>
"rebuild boot" is what kexec will be good for
<samueldr>
anyway, I'm off to sleep, but as always, feel free to ask questions, and open issues / PRs if needed :)
<irminsul>
:)
orivej has quit [Ping timeout: 240 seconds]
irminsul has quit [Remote host closed the connection]
irminsul has joined #nixos-aarch64
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
cole-h has quit [Client Quit]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 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 [Quit: No Ping reply in 180 seconds.]
orivej_ has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
irminsul_ has joined #nixos-aarch64
irminsul has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 264 seconds]
quinn has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
quinn has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
<flokli>
Ericson2314: sorry, already went to bed
<flokli>
zstd needs cmake to build, cmake needs libarchive, and libarchive can be built with zstd support
<flokli>
it successfully bootstraps a non-zstd libarchive, builds a armv7l cmake, and then tries to invoke that armv7l cmake on my x86 box to build zstd :-D
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 [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
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 [Quit: No Ping reply in 180 seconds.]
cornu has joined #nixos-aarch64
orivej has joined #nixos-aarch64
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 [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
alp has quit [Quit: Leaving]
orivej has quit [Read error: Connection reset by peer]
orivej_ has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 258 seconds]
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
FRidh has quit [Quit: Konversation terminated!]
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 [Read error: Connection reset by peer]
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: 256 seconds]
orivej_ has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
<Ericson2314>
flokli: is that on master now?
<Ericson2314>
we just need to get a buildPackages.cmake with buildPackages overrides
<flokli>
my cache probably contains it as well now, so not a very good metric :-D
<flokli>
in that case, let me check if it builds
<flokli>
:-D
<flokli>
confirmed, no rebuild on non-cross
<flokli>
and it builds for me with cross, too
<flokli>
okay, so now the only thing that's left that'd make me suuper happy would be btrfs-progs :-P
<flokli>
btrfs-progs tries to build some python stuff (libbtrfsutil_python), and uses the native python include path
<flokli>
and "pyport.h complains #error "LONG_BIT definition appears wrong for platform" then
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
<ryantrinkle>
what's the chance of zfs on mobile, cross ;)
<ryantrinkle>
back up my phone every night via zfs replication - yes please
<clever>
:D
<ryantrinkle>
i've been trying to learn how to back up my android devices properly
<ryantrinkle>
it's a nightmare
<ryantrinkle>
without root it seems to be acutally impossible
<ryantrinkle>
and even with root, it's complex
<ryantrinkle>
which is exactly what i want my backup system to *not* be
cole-h has joined #nixos-aarch64
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 joined #nixos-aarch64
orivej_ has quit [Ping timeout: 260 seconds]
<samueldr>
I would assume that zfs on mobile is as possible as zfs on arm
<samueldr>
but that's without considering the ressources usage (power draw)
<Thra11>
I'm not up to speed on zfs, but I believe btrfs on mobile is not unknown. Think some Jolla/Sailfish devices use btrfs.
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
<irminsul_>
samueldr:
<irminsul_>
oh oops thought I was deleting that & hit enter, sorry
<samueldr>
lol no worries
orivej_ has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<irminsul_>
samueldr: I'm trying to understand 2 things: (a) when I built an image from 4c479ad63d7ec157d433585bdb3247387da0f264 (no custom config), there was a "Pre-Init" splash, but when I built from 5d5d9394b0d17405398d21605a9dfea732ad3eb7 with examples/demo/configuration.nix there was not
<irminsul_>
(b) what do I need to enable to get kernel bootup messages instead of the mobile nixos splash (is the fbterm option + splash.enable = false enough?)
<samueldr>
was the kernel in-between updated?
<samueldr>
I've also seen that issue but haven't investigated yet
<samueldr>
but when I saw that, it was with the PR that upgrades the kernel
<samueldr>
splash.enable = false; fbterm is for those devices which don't have a VT, the pinephone does
<irminsul_>
gonna try it out once I feel I have the hardware basics worked out
<samueldr>
nice!
<gmr>
<ryantrinkle "i've been trying to learn how to"> this seems OT but i'm really interested in your comments - i'm planning on getting a pinephone as soon as finances allow and i want to "back up" my data in portable formats (portable being the key word - android seems to have broken that part of the backup workflows at some point between android 4 and 7). could i ask you to add any thoughts/notes to my pad on the topic?
<gmr>
irminsul_: why would one consider a librem 5 over a pinephone?
<irminsul_>
gmr: it's just a nixos packaging of the librem ui
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
<irminsul_>
I'm a huge pinephone fan so far even though mine is still in the "barely functions as a computer, much less a phone" phase
<irminsul_>
The pine64 lineup generally is looking really nice -- I'm also heavily considering picking up a pinebook pro.
alp has joined #nixos-aarch64
<samueldr>
the pinebook pro is definitely miles ahead in functionality if you compare :)
<samueldr>
suspend is not working with mainline, which is the main daily usage issue you'd face
<samueldr>
and otherwise during boot graphics init is not done until the kernel is booting, which is annoying for nixos generations
<irminsul_>
huh, no grubbish thing?
<samueldr>
the pinebook pro uses u-boot to boot too :)
<samueldr>
and there is no driver made yet for graphics for the pinebook pro either
<samueldr>
(and I don't know that anyone is working on that)
<samueldr>
same issue as with the pinephone, different solutions, but "same solution"
<samueldr>
"write a damn driver for its display"
<irminsul_>
I mean given that it has a display _eventually_, you really just need to port the driver earlier right?
<samueldr>
just :)
orivej has quit [Quit: No Ping reply in 180 seconds.]
<irminsul_>
yeah of course
<samueldr>
probably the most loaded word here :D
<samueldr>
different "kernels", you have the linux kernel driver, and a u-boot driver
<samueldr>
different subsystems probably need to be ported over too
<irminsul_>
but it's a porting job rather than "figure out how this display works and write a new driveer for it"
<samueldr>
like, if the display is MIPI, how close are the MIPI drivers for u-boot and linux?
<samueldr>
yeah
orivej has joined #nixos-aarch64
<samueldr>
with probably some foundational world building
<samueldr>
if you look, it's pretty much built the same way as the pinephone is
<irminsul_>
It kinda seems like a 2-birds-1-stone thing, ie, "how do we get nixos to behave comparably with a u-boot'd linux instead of grub"
<samueldr>
what do you mean?
<samueldr>
using mobile nixos is a good workaround for that problem?
<irminsul_>
in both the pbp and the pinephone there's a u-boot linux startup system, but because it isn't grub a bunch of things behave differently (no per-config kernel, config-picker UI support isn't there, etc)
<irminsul_>
maybe I'm just squinting hard & making them blur together
<irminsul_>
but it feels like there's a general-ish problem around u-boot + nixos that, if solved, would make both platforms work better
<samueldr>
u-boot already has a generation selection menu built-in
<samueldr>
(well, features that we use for that)
<samueldr>
and yes, if u-boot was fixed those would be good fixes for both
<samueldr>
the pinephone doesn't need the "mobile nixos" treatment
<samueldr>
(though u-boot wouldn't be usable without a keyboard)
<samueldr>
making the device descriptions for the pinebook pro is more of an exercise in showing how flexible Mobile NixOS is :)
<samueldr>
(and an exercise in dogfooding)
<samueldr>
*if* u-boot had display init for the pinephone, it would be conceivable to set it up using UEFI grub
<samueldr>
I have the pinebook (a64, non-pro) setup to go through standard aarch64 uefi grub
<samueldr>
the pinebook (a64) is the same SoC as the pinephone (but different display path)
<samueldr>
so it's not a theory, it would work
<samueldr>
but because of other platforms supported by mobile nixos, it makes sense to not worry about this and use the same solution as other platforms
<samueldr>
and stating again: using a stock nixos installation with a graphically-booting u-boot in theory should be as usable as a mobile nixos built system in the end
<samueldr>
because mobile nixos aims to do absolutely nothing for the running system :)
Ke has joined #nixos-aarch64
<irminsul_>
a noble goal :)
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 265 seconds]
alp has quit [Ping timeout: 272 seconds]
<danielrf[m]>
samueldr: Should it possible to set up uboot -> uefi -> systemd-boot on the pinebook pro?
<danielrf[m]>
I understand display init is not working on the pinebook pro w/ uboot
<samueldr>
already on u-boot master, CommitDate: Sun Apr 26 23:04:49 2020 +0200
orivej has quit [Quit: No Ping reply in 180 seconds.]
<Ke>
samueldr: yes, this it the url I was referring to
* samueldr
clears the afternoon of other plans
<samueldr>
in theory with all those patches, if they do what's advertised, the pinebook pro early boot is "done"
orivej has joined #nixos-aarch64
<Ke>
samueldr: does it actually blend though?
<samueldr>
y'all be the first to know
<Ke>
I assume you are not a lazy slob like I?
<samueldr>
I kinda have some interest in making NixOS the first "boots like on your PC" distro for the pinebook pro :)
<Ke>
that's slightly unexpected
<samueldr>
hm?
<Ke>
well just prejudice, do you have bleeding edge kernel in aarch64 installer?
<samueldr>
I guess you would use a custom iso with a known good kernel though
<Ke>
debian testing has maybe 4 weeks old kernels
<samueldr>
it's all things I've already one, my pine a64-lts has u-boot on SPI, I last installed using the standard UEFI install
<Ke>
was it that you needed 5.8 to work with the battery
<samueldr>
I'll first work off from a known good kernel though :)
<Ke>
I guess you only need it to recharge, so if you can install without charging
<Ke>
manjaro patches on 5.8 really lean
<Ke>
are
<samueldr>
great
<samueldr>
I haven't really kept up to date with the pinebook pro lately since I made the initial bunch of work
<Ke>
I think 5.8 mostly works even without
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]
<Cadey>
how do i build a custom raspi 4 image?
<Cadey>
i'd like this thing to work headless (i don't have a microHDMI adaptor)
<samueldr>
hi!
<samueldr>
Cadey: do you have another aarch64 to build from or do you only have x86_64?
<Cadey>
i have only a ryzen machine
<samueldr>
good, that gives us a starting point
<samueldr>
you can imperatively do an operation that will start sshd on the raspberry pi, if you have a usb keyboard
<samueldr>
unless you prefer *building* the image, which entails cross-compiling things, which may take some time
<Cadey>
i'd like to build the image and pre-bake it, yes
<Cadey>
i have the following configuration.nix so far: https://git.io/JfbAV, i'm just not sure how to turn it into a SD card image that the raspi will boot
<samueldr>
you won't be able to cross-compile that configuration, most likely, as once you stray from the base nixos system cross-compilation isn't "there" yet
FRidh has quit [Quit: Konversation terminated!]
* samueldr
is thinking about alternative approaches
<ryantrinkle>
gmr: well, what I do for my linux machines is ZFS with snapshots
<ryantrinkle>
i rsync things nightly over to another machine, which *also* keeps snapshots, separately
<samueldr>
but if it does, the same caveats for native/cross-compilation would apply
<ryantrinkle>
and the privileges are set up so that the machine getting backed up doesn't have the ability to delete snapshots on the backup machine
<ryantrinkle>
(this is to defend against things like viruses and ransomware which could compromise your backups as well as the machine being backed up)
<Cadey>
is it the binaries are built using qemu and things can get kinda weird kind of caveats or cross-compliation being kind of a miracle in general kind of caveats?
<ryantrinkle>
for android, i just now put in place a nightly rsync of my data partition
<ryantrinkle>
i don't really think that's enough, but i'm not exactly sure where to go from there
<samueldr>
qemu-based-compilation is a third option which has caveats too
<samueldr>
though some users have had good success with it, I personally don't look into that anymore as it *could* cause more headaches than desirable
<ryantrinkle>
with pinephone, I would certainly plan to try out zfs, but if its memory requirements are too large for pinephone, then i'd probably fall back to something simpler, possibly giving up the local snapshots
<ryantrinkle>
i'd still have snapshots on the backup machine
<ryantrinkle>
sadly, i'm upgrading my phone now, because my old one is dying and I haven't yet managed to get my pinephone in daily driver shape
<ryantrinkle>
hopefully i can switch to nixos before the next upgrade cycle
<ryantrinkle>
i'm willing to give up almost every feature of my phone :P
<ryantrinkle>
just need reliable alerts and comms
<Cadey>
samueldr: where can i get the raspi 4 image that's prebaked so I can yolo it headlessly?
<samueldr>
that would at least give you a native aarch64 system on which you could do a native build of the desired image
<samueldr>
to headlessly-yolo, you would first boot the image, blindly `sudo poweroff` wait for poweroff, copy your ssh key to /home/nixos/.ssh/authorized_keys, making sure it's only rw-------
<samueldr>
then boot, and sudo systemctl start sshd
<Cadey>
i love it
<samueldr>
the first boot is required as you have "nixos in powdered form" that needs to be rehydrated
<Cadey>
yep
<Cadey>
rehydraing the SD card, etc
<samueldr>
the first poweroff is also a good check that validates your usb input works on a console
<samueldr>
I think the hardest part in getting started with aarch64 nixos may be that you need an aarch64 to get started with builds
<samueldr>
I wonder if there is a trivial enough way one could setup a "throwaway" remote builder image that is still secure to getting start
<samueldr>
a minimal nix-daemon image
orivej_ has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
<clever>
samueldr: you can also just install nix on raspbian
<samueldr>
clever: raspios
<samueldr>
yeah, but until recently it was armv7l!
<clever>
still not used to the rename, heh
<samueldr>
and that kinda defeats the idea of a known root of trust, you're adding raspios, their contributors, and debian and its contributors on your root of trust
<Cadey>
i got the sd card baked
<Cadey>
i'm gonna boot up the raspi and run the sudo poweroff
<gchristensen>
how is nixfmt vs nixpkgs-fmt? (I have pretty much just use nixpkgs-fmt)
<Cadey>
my emacs config with spacemacs uses nixfmt, i have no complaints about it
<gchristensen>
cool
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
quinn has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
<colemickens>
one of them was very aggressive and was immediately disabled, the other was less aggressive but also got disabled (minimize diffs in PRs). I wish one were definitively authoritative.
<flokli>
heh, I got the fully-crosscompiled, custom uboot hackery fpga board to boot!
<flokli>
It's a Zynq / Pynq board with an FPGA on it.
<flokli>
Custom kernel, custom uboot, scary tooling for the hardware synthesis part (but fully nixified and sandboxed, so bearable) :-)
<irminsul_>
nice!
<irminsul_>
yeah I did some fpga courses in college, then kept telling myself I'd eventually do something interesting in CLaSH, and have 90% just been spectating cool stuff in fpga space
<samueldr>
Cadey: in the "firmware" partition there is an "old" directory with older boot files
<samueldr>
Cadey: copying those over the files at the root of that partition allows you to boot an earlier generation
<flokli>
irminsul_: yeah, one of my goals is to make that tooling more manageable
orivej has quit [Ping timeout: 258 seconds]
<flokli>
and actually having something like systemd running on the linux part is super cool