<samueldr>
really looks like, in a good sense, that this is the "kitchen sink to build your rom" project :)
<danielrf[m]>
Haha, well I personally don't plan on implementing it myself--but if someone else wants it I'll merge it
<samueldr>
at first, since you focused on GrapheneOS, I was pretty sure it was going to be laser-focused around security and such
<danielrf[m]>
Yep, I just need to make the documentation clear about what level of security to expect from different configurations
<danielrf[m]>
and I do worry a bit about the exponential complexity increase when adding more options, so I'll make clear exactly what configurations are supposed by me
<danielrf[m]>
and if people want to fix up other combinations then I'm open to it
<danielrf[m]>
s/supposed/supported/
<samueldr>
perfectly understandable
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 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
Acou_Bass has quit [Ping timeout: 260 seconds]
Acou_Bass has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 260 seconds]
Acou_Bass has joined #nixos-aarch64
<clever>
samueldr: having weird problems with /dev/gpiomem now on my rpi
* samueldr
can't help
<samueldr>
I could be a bouncing board
<samueldr>
but other than what the name tells me it must do, I don't know more
<fps>
still grappling with getting my patches applied. stumbled over fixed output derivations not redownloading the source once again (i did the same thing many times in guix - seems that this is such a general problem that it would be cool to have like a generic option to redownload and recheck all hashes in a derivation)
<clever>
fps: if you modify something, you must invalidate the hash
<clever>
if you claim the hash is the same, it wont re-download, because it already has a product by that hash
<fps>
yeah, i know
<fps>
i did it know by changing the hash in the expressions
<fps>
but that's annoying :)
<fps>
something like --revalidate-hashes would be awesome.
<clever>
garbage collection would wipe that
<fps>
oh, good point
<fps>
but that is like using a hammer where a feather would be more suitable
<clever>
any time you change a url, switch to insert mode and change a few digits of the hash to 0
tilpner has quit [Read error: Connection reset by peer]
tilpner_ is now known as tilpner
FRidh has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
<fps>
hmm, -j 4 was ignored by nix-build it seems. it goes full ahead on all 16 virtual cores
<fps>
another segfault after a couple of hours.. waiting 2 1/2 for a compiler error is annoying
<sphalerite>
fps: -j is for number of derivations to build at a time, but you may also want to specify --cores, which defines how many jobs will be used within each derivation build
<sphalerite>
fps: is it the same segfault?
<fps>
sphalerite: nope, but the build isn't deterministic due to the number of cores i gues
<fps>
will try limiting the jobs to see if it's maybe a thermal thing
zupo has joined #nixos-aarch64
<fps>
i will know more in ca. 3h ;)
<fps>
maybe it's a bug in my machine :(
<sphalerite>
could be. I've had the most exciting build failures from a failed SD card, and spurious segfaults from bad RAM before
<fps>
and damn it takes long to build a kernel on a qemu-binfmt hacked "aarch64" build ;)
<sphalerite>
oh!
<sphalerite>
qemu-user also isn't the most reliable.
<fps>
hmm. maybe i should try building it on my rpi4 directly?
<sphalerite>
yeah
<fps>
hmm, ok
<sphalerite>
USB storage might be faster than the SD card FWIW
<fps>
true
<sphalerite>
or even network storage :D
<sphalerite>
(I have no idea)
<sphalerite>
(now I want to try out /tmp-on-nfs)
<fps>
hehe
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<fps>
hmm, it compiler errors even with --cores 4
<fps>
let's try 1 and also a build on the rpi4
<fps>
the rpi seems to be quite a bit faster than the qemu binfmt hack, too
<sphalerite>
yes, machine emulation is horrendously slow
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 246 seconds]
tilpner_ is now known as tilpner
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Darkmatter66 has quit [Ping timeout: 240 seconds]
rasmusm has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej_ has joined #nixos-aarch64
<srk>
clever: one idea was to use systemd generators to scrape the nice names and create udev rules
<srk>
fps: cross-compiling works as well, I've had to use staging since I'm on some random commit but 20.03 might work just fine
<srk>
fps: managed to cc images for pi3 and pi4
<srk>
my armv7 imx6 can't compile kernel on 4 cores either, needs --cores 3 otherwise it overheats and produces errors :)
<samueldr>
I knew it wouldn't be factory reset protection, but that was the only thing I had in mind
<ryantrinkle>
clever: nice :)
<clever>
ryantrinkle: under raspbian, it works great, but under nixos+open-firmware, it fails, /dev/gpiomem returns all nulls
<ryantrinkle>
srk: yup! i mostly use it for GUI programming (that's what my company does), but it's useful for anything where you've got a variety of event sources that need to be dealt with as they fire
<srk>
ryantrinkle: I'm writing something like oui-blendish in haskell on top of nanovg-hs
<srk>
ryantrinkle: to be able to combine 2d and 3d in opengl