<patagonicus>
Ok, having slept on it, at least I've realized that I don't need to test full system builds, I can probably a) reproduce the problem by just swapping out the kernel, b) can probably minimize the kernel config before looking for the breaking change and c) can probably remove some optional dependencies the kernel build has. Will still mean getting
<patagonicus>
out one of the MicroSD cards, changing the kernel with my laptop, putting it back in, resetting the device and then checking the serial output roughly 13 times, though …
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
<patagonicus>
Ok, it's not the kernel? Maybe stage1, then?
<patagonicus>
Also no. Hmm. Changed kernel command line? This is confusing.
zupo has joined #nixos-aarch64
bdju has quit [Quit: Reconnecting]
bdju has joined #nixos-aarch64
<patagonicus>
So, I built a fresh sd card image (custom stuff, including encryption) and that hangs at "Starting kernel ...". But I already tried the new kernel and initrd. The dtbs are unchanged. And uboot is not automatically installed on nixos-rebuild, so why did it fail when I did that on an existing installation?
<patagonicus>
Guess all I can do is to see if I can reproduce it with a minimal SD card image and then bisect.
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
I was showing the PR involved with elvishjerricco's error
<samueldr>
elvishjerricco's using stuff from a commit from before those changes right now AFAIUI
<Ericson2314>
well i missed your comment before
<Ericson2314>
`platform.linuxArch or platform.kernelArch`
<Ericson2314>
stuff like that is annoying but will ensure working with nixpkgs before and after
<samueldr>
yeah, though it's a more global discussion, not specific to these changes, what should Nixpkgs do with its API?
<samueldr>
it broke a lot of external users
<samueldr>
and doing so without warning, without error messages helping with migration steps
<samueldr>
(as I said, more global discussion is needed)
<samueldr>
it would have been nice for one full release cycle to keep the previous attributes with warnings
<samueldr>
inside of nixpkgs, they could have been disabled with the aliases config toggle
<elvishjerricco>
I'll just rebase on a newer commit
dev_mohe has joined #nixos-aarch64
<samueldr>
and Ericson2314, I totally know that these changes are made with good intention, and I approve of the idea behind... my only issue being with the instability of these APIs during this release cycle
dev_mohe has quit [Client Quit]
<Ericson2314>
unfortunately it's hard to put in warnings on these things before `hostPlatform != buildPlatform` stuff will evaluate them
<Ericson2314>
that's what happened with deprecation cycles before
<samueldr>
I'm not being fascetious, but how is it hard?
<Ericson2314>
because == and != is not overridable and will force every attribute
<Ericson2314>
so any builtins.trace will trace
<Ericson2314>
and then nixpkgs CI thinks there is a violation
<samueldr>
oh, so because `==` and `!=` check all attributes, they would trigger the warning, is that so?
cptchaos83 has joined #nixos-aarch64
<samueldr>
could, without a trace, these at least have been kept for a full release cycle aliased to their previous names, and documented in release notes?
<elvishjerricco>
samueldr: it says uas is built in
<samueldr>
that was a guess because cole//mickens had issues with something and usb
<samueldr>
(thus the laugh)
<elvishjerricco>
Now to get a configuration.nix set up that does my cross compiling stuff
<elvishjerricco>
huh, `lsmod | grep uas` gives no output. Is that expected for built in modules?
<samueldr>
I think so
<colemickens>
when things like ipxe are in use, is there some sort of virtual fs presented that cause additional files to be retrieved from tftp? I've never quite groked that bit.
<colemickens>
also, does anyone in the nixos community have the new compute module? just to be able to test all of my changes with other rpi4 variants
<samueldr>
colemickens: elvishjerricco does
<samueldr>
but u-boot doesn't support it yet in mainline
<samueldr>
and the kernel maybe doesn't have the right device tree files for it yet
<elvishjerricco>
colemickens: Yea I got it booting just a few minutes ago
<elvishjerricco>
samueldr: The rpi kernel does have the dtb for it
<samueldr>
yeah, colemickens is working on mainline stuff :)
<elvishjerricco>
or at least the latest version does.
<samueldr>
the pi 4 can apparently boot fine on mainline
<samueldr>
I would expect the same for the 400, colemickens
justanotheruser has quit [Ping timeout: 260 seconds]
<colemickens>
oh that's what you're booting, neat :)