<samueldr>
if it's those, I guess many will end up answered by =m
<colemickens>
notice I dropped the other patch that got dropped in nixpkgs too
<samueldr>
=y is a shortcut to also have the modules in stage-1
<samueldr>
otherwise you won't get display in stage-1... maybe
<colemickens>
I got hundreds of some EOF error with that in there though so I gave up
<samueldr>
you could also identify which drivers are needed
<samueldr>
ah, probably one or two options being renamed or something like that
<samueldr>
(something I find my approach with mobile nixos works better, for device-specific kernel builds)
<samueldr>
colemickens: so yeah, basically I expect your build might not have display during stage-1
<samueldr>
and uh, coming back to gadget mode and pinebook pro...
<samueldr>
using the mobile nixos tooling, I can make a linux system that exports the internal eMMC as usb storage!
<samueldr>
(or use adb, or well, anything else gadget mode allows)
<colemickens>
hm alright
<samueldr>
the fix is simple though
<samueldr>
identify the modules required
<samueldr>
and make them availableKernelModules
<samueldr>
(not all of these will be required)
<colemickens>
I don't really mind my display, I got what I wanted for effort/reward for now I think. I was more thinking about what I'd use gadgetfs for.
<samueldr>
ah
<samueldr>
display in stage-1 is needed for passphrase entry
<samueldr>
and for debugging issues
<colemickens>
ah yeah I didn't think about that, I just don't luks this one I guess
orivej has joined #nixos-aarch64
cole-h has quit [Ping timeout: 264 seconds]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
alpernebbi has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cptrbn has quit [Quit: Gooooooood niiiiiiiiiight]
justanotheruser has quit [Ping timeout: 272 seconds]
cptrbn has joined #nixos-aarch64
s1341 has joined #nixos-aarch64
<s1341>
hi
<s1341>
I'm trying to cross-build protobuf and protobuf-c for android...
<Ke>
sphalerite: I am not sure, if you solved the missing acceleration for amdgpu/radeonsi, but the problem is that radeonsi is not automatically compiled for aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
zupo has quit [Read error: Connection reset by peer]
<sphalerite>
Ke: I don't have a GPU on mine so I have no idea. That sounds easy to fix though
<s1341>
why is it looking for the c preprocessor in /lib?
<sphalerite>
Ke: maybe `hardware.opengl.extraPackages = [(pkgs.mesa.override { galliumDrivers = ["radeonsi"]; }).drivers];` is enough to make it work for you
<sphalerite>
not sure though, as I said I don't have a GPU in mine so I can't test
<Ke>
I looked at that, and not sure
<Ke>
does override work, as it's not part of mkDerivation parameters
<Ke>
or is it callPackage whose parameters are to be modified
<Ke>
I just modifies the opengl module in nixpkgs
<sphalerite>
That's also an option, though I think that'll get you mass rebuilds
<sphalerite>
override is indeed added by callPackage
<Ke>
nope no mass rebuilds
<Ke>
it's only used to generate one tmpfiles.d symlink
<Ke>
sphalerite: do you know, how can I poke mesa patches, if override comes from callPackage
<archseer>
samueldr: so I've noticed the built kernel only contains the image + dtbs
<archseer>
I've turned on gadgetfs features and set them as modules so I can pick which one to load in stage-2 then noticed the module folder is missing
<sphalerite>
Ke: if an option is internal, that just means it won't show up in the documentation. You should be able to do pretty much exactly the same thing directly in your nixos config too though, i.e. hardware.opengl.package = (pkgs.mesa.override {…}).overrideAttrs (…);
<sphalerite>
The mkForce shouldn't be necessary, since the default setting is already a mkDefault (i.e. low priority)
ryantrinkle has quit [Ping timeout: 240 seconds]
<Ke>
I tried mkForce before, but still did not work
<Ke>
maybe I tried wrong, could try again
<Ke>
sphalerite: setting it to null did not fail
<sphalerite>
Ke: yeah, it's silly but it's just added to a buildEnv, so if it's null nothing will get added…
<Ke>
with mkForce it fails
<Ke>
no it should be used in nix code, so definitely failure is expected
<Ke>
evaluated as string in nix
<sphalerite>
> "${null}"
<{^_^}>
cannot coerce null to a string, at (string):471:2
<Ke>
hmm, I clearly did something wrong before, at least freecad gets evaluated there
zupo has joined #nixos-aarch64
WilliButz has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
Darkmatter66 has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
WilliButz has quit [Remote host closed the connection]
WilliButz has joined #nixos-aarch64
drag0nius has joined #nixos-aarch64
<drag0nius>
how stable is nixos on aarch64? I'm reconsidering again whether i should try to run my k3s raspberry pi4 cluster on it (last time i gave up waiting for 20.09 release :P )
<samueldr>
NixOS mostly _is_ just Linux
<samueldr>
so not much more or less than Linux
<samueldr>
but is packaging in Nixpkgs (and NixOS) considering aarch64?
<samueldr>
not always, but most of the time it's fine
<samueldr>
but that only answers the question about aarch64
<samueldr>
is _your_ aarch64 platform well-supported?
<drag0nius>
i remember i had some issues building the system last time i tried around 4-5 months ago
<samueldr>
yeah, that's vague :)
<samueldr>
NixOS generally aims to support mainline Linux
<samueldr>
anything else is YMMV
<samueldr>
mainline Linux here means the kernel as released by kernel.org
<samueldr>
I guess it depends what were the issues you faced
<drag0nius>
well... might try again since 20.09 was released since then
<makefu>
drag0nius: as of right now, aarch64 build failures do not block a channel from advancing. build failures can still happen without much attention given to them
<samueldr>
yeah, there's that
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
but makefu, the channel _is_ blocked from advancing if the basic sd image fails to build
<makefu>
it_something.png
WilliButz has quit [Quit: bye]
<samueldr>
but the package set is not waiting for all of aarch64 to be tried to be built to advance
WilliButz has joined #nixos-aarch64
zupo has joined #nixos-aarch64
drag0nius has quit [Quit: Connection closed]
cptrbn has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
noonien has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]