<colemickens>
elvishjerricco: sorry, missed the ping, I just did this: "nixpkgs.crossSystem = lib.systems.examples.raspberryPi;" and then import nixpkgs with `system = "x86_64-linux"`. So it builds on x86_64-linux and does the cross build, in theory, for the pi.
<elvishjerricco>
colemickens: But you needed patches for nixpkgs, right?
<colemickens>
elvishjerricco: the only thing so far was pulling the perl revert. this is the tree I'm working with so far:
<elvishjerricco>
colemickens: Thanks. I wonder why these perl packages are even needed. Could we just cut them out of the dependency graph somehow?
<colemickens>
the system activation script is written in perl ;)
<elvishjerricco>
colemickens: But why does the system activation script need `HTTPDaemon`?
<colemickens>
for more bike-shedding (another link I can't paste because Firefox has just had broken clipboard under wayland for nearly a year)
<colemickens>
oh yeah, I don't know about that!
<gchristensen>
(odd ... it has worked for me forever ...!)
<colemickens>
anyway, there was a PR for switching that script to python, it was interesting to read people's reasoning
tilpner_ has joined #nixos-aarch64
<elvishjerricco>
Anyway, I'm looking at the failed builds from my attempt to build this unpatched, and neither HTTPDaemon nor the activation script are listed in the builds that couldn't be built because of failed dependencies
tilpner_ is now known as tilpner
<colemickens>
yeah, I'm winding up with this when I try to build an initrd
<colemickens>
modprobe: FATAL: Module ahci not found in directory /nix/store/mrvshd1q2wwi3xjxwz1p2h5xls9g9309-linux-5.4.79-1.20201201-armv6l-unknown-linux-gnueabihf-modules/lib/modules/5.4.79
<colemickens>
oof, if I force my way around that I'm actually getting nix fialing to build now elvishjerricco
<colemickens>
but I'm also using nixFlakes, I can probably override that for this system and see if stable cross compiles
* colemickens
really needs to push guile to a cache after waiting on it to build again
<elvishjerricco>
Well, I find the right expression to cross compile the sd image, and it tried and failed to build qemu.... Why build it and why would it fail?
<elvishjerricco>
Why is it building git and rustc??
rajivr has joined #nixos-aarch64
<elvishjerricco>
Those aren't even being cross compiled...
<colemickens>
not sure about the latter, but the former is probably because we boot a VM to do the SD card image creation, IIRC
<elvishjerricco>
oh that would make sense
h0m1 has joined #nixos-aarch64
<colemickens>
anyone keeping an eye on PBP things? Seems like maybe mainline is expected to work?
<samueldr>
saw something along the line yesterday
<samueldr>
but "badly"
<samueldr>
not sure what it means
<samueldr>
but maybe it means "enough to let someone start themselves up with the mainline sd image"
<colemickens>
I'm not sure we actually use a vm t make the sd card image btw elvishjerricco
<colemickens>
I'm peeking at sd-image.nix and it seems to assemble it without a vm (like make-disk-image does)
* colemickens
built a nixos-sd-image-21.03.20210129.c2c140c-192f8916-armv6l-linux.img.zst
<elvishjerricco>
Oh. Interesting...
<elvishjerricco>
nice
<elvishjerricco>
Hm... `modprobe: FATAL: Module sun4i_drm not found in directory /nix/store/kka8970xir2w3g46i553z6y8gkn3kqxy-linux-5.4.79-1.20201201-aarch64-unknown-linux-gnu-modules/lib/modules/5.4.79`
<samueldr>
is it the actual error that caused the failure?
<samueldr>
I have in mind that the modules missing to be put in initrd shouldn't cause an actual failure
<samueldr>
though if that's the error I think it is, this is happening while assembling the image
<samueldr>
well, the initrd
<colemickens>
I wound up having to override the initrd availableKernelModules (presumably to exclude modules that don't exist for my chosen linuxPackages ??)
<samueldr>
I thought they wouldn't error out on missing modules because of myriad reasons
<samueldr>
1) customizing kernel config
<samueldr>
2) kernel modules from newer linux version not existing in previous versions
<samueldr>
maybe not myriad
<elvishjerricco>
samueldr: That error message was the last line in the log for the failed modules-shrunk derivation, so I assume that was an actual ereror
<colemickens>
wow, it booted! the otg ethernet stuff didn't work apparently (or requires to use separate power/data connections), maybe I'll hook up usb long enough to configure iwd
<elvishjerricco>
Ugh. I've got a nix expression that evaluates to a string with context, and I want to build that context but can't figure out how
<samueldr>
colemickens: pi zero?
<samueldr>
raspberry pi 1 B cannot do OTG
<samueldr>
well, it could
<samueldr>
if you removed the ethernet and usb stuff
<samueldr>
raspberry Pi A can because of that IIRC
<elvishjerricco>
It all comes down to talloc using wafHook which at some point uses targetPlatform.emulator
<elvishjerricco>
But yea, I appear to be down to just perl problems
<colemickens>
ah I forgot to include ssh :P
<elvishjerricco>
colemickens: Also, do you happen to know where I can find the PR that attempted to switch the perl to python? I'm having trouble finding it myself, and I'd consider working on that to get rid of perl
<{^_^}>
#48378 (by bgamari, 2 years ago, closed): [WIP] Port switch-to-configuration script to Python
<elvishjerricco>
colemickens: Found it just before you linked it :P
<elvishjerricco>
Looks like it's going to have to be rust or c++ so... looks like I'll be messing with some perl packages :P Definitely not going to try to rewrite that myself any time soon
ajs124 has joined #nixos-aarch64
<colemickens>
very odd...
<colemickens>
after adding ssh and tailscale, the image failed to resize and boot properly
<colemickens>
I had to delete/recreate/grow the ext4 partition myself for it to boot...
orivej has joined #nixos-aarch64
<elvishjerricco>
Uh... what does a rainbow screen mean for rpi?
<samueldr>
archseer: indeed actually not needing to obliterate the nixos config helps
<samueldr>
it can use the usual `evalConfig`, so I assume you can also just add the module list
<elvishjerricco>
Well combining the config.txt files from raspbian and NixOS fixed whatever that was. Now I get `mmc0 is current device **No partition table - mmc 0 **`, followed by usb then pcie the finally looping on ether net `BOOTP broadcast <n>`
<colemickens>
am I cross-compiling wrong if programs using "wrapProgram" don't work?
<samueldr>
could it be that this pkgs.runtimeShell is the buildPackages one?
<colemickens>
seems like maybe something like that?
<colemickens>
but the makeWrapper is specified in `nativeBuildInputs` so I was hoping that it would do the right thing somehow?
<samueldr>
it's a hard situation here
<samueldr>
putting it into nativeBuildInputs is like using `buildPackages.*`
<samueldr>
there's some automatic splicing shenanigans that happens at callPackage
<samueldr>
so you're using `buildPackages.makeWrapper`
<samueldr>
it might be an oversight that we actually need some more special handling for that `pkgs.runtimeShell`
<colemickens>
I'm surprised to be running into this, I guess.
<colemickens>
Surely others cross compiling have tried to use wrapProgram'd things?
<samueldr>
yes
<colemickens>
plus I don't understand how it could ever do the right thing?
<samueldr>
I think most cases were lucky enough to just pass through using bash's thing where it just falls through to itself
<colemickens>
aha oka
<colemickens>
weird
<samueldr>
clever _did_ notice that we were having many scripts wrappped with the build machine's bash
<samueldr>
I'm not sure how you could make buildInputs.makeWrapper aware of the runtimeShell
<samueldr>
it might be that makeWrapper needs to be handled separately
<samueldr>
Ericson2314: any idea about makeWrapper not using the runtimeShell of the target platform?
<Ericson2314>
yeah i think it should be
* samueldr
tries to make a sample reproducer
<jasom>
So trying to build an sd image with the instructions from https://nixos.wiki/wiki/NixOS_on_ARM#Build_your_own_image and I get "error: Package ‘raspberrypi-firmware-1.20200601’ in /nix/store/i03nyp29ps71c0qyay9299ivj5h15zsd-nixos-20.09.2750.85abeab48b5/nixos/pkgs/os-specific/linux/firmware/raspberrypi/default.nix:20 is not supported on ‘x86_64-linux’, refusing to evaluate."
<colemickens>
the line below the example implies that must be run from an aarch64 machine
<colemickens>
which would make sense for the error
<jasom>
colemickens: I have binfmt qemu-aarch64 set, can I tell nix-build to use that?
<samueldr>
Ericson2314: see previous link, it indeeds wraps with the wrong bash, if you observe the result
<colemickens>
jasom: Unfortunately, I don't really know anything about using that method, due to hearing mixed results.
<samueldr>
(btw, not putting this on your shoulders, asking for advice if any)
<colemickens>
jasom: did you also update the nix configuration so that it thinks your system can handle aarch64?
<jasom>
nevermind, it's like 3 lines lower in the wiki
<jasom>
"--argstr system aarch64-linux"
<Ericson2314>
samueldr heading to sleep but yeah I do recall it's wrong today. Should be fixed, but unfortunately many of the usages are also wrong to hack around this
<samueldr>
yeah, no worries
<samueldr>
been thinking a small bit about how this could be fixed and I really don't know, curious to see how that can be fixed
* colemickens
wonders how other distros target armv6, if it takes a lot of special care, just works, or if they native compile when targetting such systems
<samueldr>
I think some dirtily cross compiles packages they upload
<samueldr>
many just compile natively
<samueldr>
but they don't have our expensive stdenv rebuilds
<samueldr>
even a dependency changing does not require a rebuild of dependents!
<samueldr>
unless the ABI is incompatible
<colemickens>
I wonder what the slowdown factor is on qemu-system-arm no kvm. I could go back to trying to boot my cross-built system in a raspberry-like qemu. I was so ready to fall in love with crosscompiled nixpkgs though :)
ornxka has quit [Quit: No Ping reply in 180 seconds.]
evalexpr has joined #nixos-aarch64
alunduil has joined #nixos-aarch64
ornxka has joined #nixos-aarch64
shad has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cptrbn has quit [Quit: Gooooooood niiiiiiiiiight]
cole-h has quit [Ping timeout: 240 seconds]
ryantrinkle has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
cptrbn has joined #nixos-aarch64
zupo has joined #nixos-aarch64
feepo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
justanotheruser has quit [Ping timeout: 265 seconds]
aminechikhaoui has joined #nixos-aarch64
zupo has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
<colemickens>
So I built this cross-compiled system, right samueldr . Do you know if there's a way that I can use the cross-compiled base to build a native build now?
<samueldr>
yes
<colemickens>
If i try to do an armv6/armv6 build, it's going to have to bootstrap from scratch, I guess, which would stink.
<samueldr>
boot it and build from it
<samueldr>
that's exactly it :)
<samueldr>
the exact reason it's not really happening
<colemickens>
I guess even if I did some how bootstrap shortcut it, the hashes would change anyway again. Gah!
<colemickens>
Okay, I shall live with things the way they are for now then. :)
<samueldr>
that's one reason I personally think cross-compiling efforts shouldn't be put at the backseat
<samueldr>
there are some platforms where it is just too expensive to go with native builds
<samueldr>
like existing raspberry pi 1 hardware
<colemickens>
It seems ideologically neat too, at least with the perspective that I have.
<samueldr>
I would call it convenient
alpernebbi has quit [Quit: alpernebbi]
mla has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ket22 has joined #nixos-aarch64
<ket22>
Hello
<ket22>
I;m trying to build nixos for pinephone but I get "attribute 'isXen' missing, at /nix/store/i03nyp29ps71c0qyay9299ivj5h15zsd-nixos-20.09.2750.85abeab48b5/nixos/pkgs/top-level/all-packages.nix:17752:68"
<ket22>
How can I fix it?
orivej has joined #nixos-aarch64
<colemickens>
I wonder if just pushing `bash` into the systemd services that use pkgs that have wrapPackage would be enough to work around the cross-compiling issue.
<colemickens>
If that will trigger the "it-calling-itself" fall through workaround