<simpson>
It's so cute. I just wanna hold it and, like, bite it.
<samueldr>
really has a good look
lovesegfault has quit [Quit: WeeChat 2.7]
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
<colemickens>
Is it expected that `esphome` refuses to build on aarch64 due to platformio?
<colemickens>
Looks like it might stem from the FHSUserEnv in platformio's chroot setup? I see that there are attributes, multiPkgs, targetPkgs that seem possibly related.
<colemickens>
I'm curious if there's potentially an easy unblock. (I did see also that platformio was marked as broken on aarch64 but I was hoping that maybe things have changed.)
<thefloweringash>
good thing it's a short build? /s
<thefloweringash>
is that an oom kill? is llvm9 not cached?
<thefloweringash>
both llvm_9 and clang_9 are cached for nixos-unstable -- but only on my server, not on cachix
<thefloweringash>
you appear to be on something other than nixos-unstable though
<srk>
master, 5 days ago, might switch to unstable
<srk>
trying with swap enabled, no oom kill msg in dmesg tho
<thefloweringash>
the problem I have is that my hydra builds a bunch of random things, if I pushed them all to cachix it'd burn through the 10gb quota pretty quickly
<srk>
heh, yeah
<thefloweringash>
so I only push the outputs of things listed. this means that a lot of the build dependencies are missing
<thefloweringash>
I'm not aware of an expression for the build dependencies, and stopping somewhere before bootstrap binaries
<srk>
found some like autogen, libidn, libiberty (but might be due to different commit)
<thefloweringash>
and I think a post-build hook is in the wrong place
<srk>
would be nice if we could share builds via torrents or some other distributed manner
<srk>
like if hashes from N builders match consider build good
<simpson>
srk: Do you want Sybil attacks?
<simpson>
'Cause that's how you get Sybil attacks.
<srk>
well if you establish trust somehow
<simpson>
Well, to repeat myself, "trust" means "can be exploited by". The current way that the community does this is by centralizing the builds and ensuring that a community-governed structure protects them. We hope (which is a terrible strategy!) that the community's leaders have the integrity to not compromise the cache.
<thefloweringash>
for the aarch64 community builder the group of trusted users is currently "everyone who can build", we could reduce this "nixos infrastructure admins"
<srk>
yep. you can always disable caches and compare with centralized store if stuff is reproducible
<srk>
it could be done with a bittorrent tracker, with a concept of 'register my store as well and allow usage of other ppls stores' which is kind-of similar to http caches
<simpson>
srk: Because of how torrents are internally structured, different packages would have different torrent hashes, even if they have the same Nix hash. This means that you wouldn't even be able to *look up* packages by Nix hash to see whether they'd match; you'd already have to know that you're pulling the right torrent.
<srk>
right, that makes sense. but can't you make torrents reproducible? :)
<srk>
it probably wouldn't scale with current bittorrent implementations but who knows
<simpson>
That's kind of what I'm saying: Yes, torrents *are* reproducible, because they don't have a build step!
<srk>
ah
<simpson>
Like, put yourself in your package downloader's shoes. You're tasked with finding some specific hashed version of a package. To start, you're going to download a torrent. How do you get the hash *of the torrent*?
<srk>
you ask a meta-tracker
<simpson>
Okay. So now the trust is moved to this meta-tracker which maps Nix hashes to torrent hashes. Didn't help at all, did it?
<simpson>
Regardless of how far up we try to push that mapping, the *information* in the mapping still has to exist.
<srk>
indeed, but if combined with a pgp like key exchange and trust model?
<simpson>
This is almost a no-free-lunch situation: you can't just borrow Somebody Else's CPU. There's gotta be some sort of associated proof, as in homomorphic encryption, I think, in order to improve.
<simpson>
Then you get to know which PGP key built the package that exploits you, which is cold comfort if they're on the other side of the Web of Trust.
<srk>
I don't want to borrow CPUs - just re-use builds done by others who I exchange keys with
<simpson>
A web of trust, again, is just a structured way to confer blame after the betrayal.
<simpson>
c.f. *the* Web of Trust, which is largely collapsed after the fracas with the keyservers.
<srk>
yeah but that's a different story
<srk>
so what's better than a web of trust?
<simpson>
srk: Please think more critically about this. When somebody else does a build, they must put in CPU in order to do the build. We believe, as a general behavior of compilers, that there aren't any shortcuts in compilation; you have to compute to get the binary. So of *course* CPU is being borrowed, and that's the entire point.
<srk>
the way I think about it is that if I build something spending my precious CPU time I can share it with other ppl so they don't have to waste more CPU of their own
<simpson>
That is very neighborly of you! Similarly, I have a coworker who brings in cookies. The cookies are delicious, but we have to trust them to have washed their hands and kept their kitchen clean.
<srk>
you should ask few other coworkers if they can reproduce the cookies ;)
<thefloweringash>
that sounds messy ;-)
elvishjerricco has quit []
elvishjerricco has joined #nixos-aarch64
shad has joined #nixos-aarch64
wavirc22 has quit [Ping timeout: 240 seconds]
pbb has quit [Ping timeout: 246 seconds]
pbb has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
pbb_ has joined #nixos-aarch64
pbb has quit [Ping timeout: 272 seconds]
lirzhv has quit []
lirzhv has joined #nixos-aarch64
bdesham has left #nixos-aarch64 [#nixos-aarch64]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
orivej has joined #nixos-aarch64
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<DigitalKiwi>
is your cookie policie GDPR compliant
mDuff has joined #nixos-aarch64
<mDuff>
Hmm. I've configured ``hardware.deviceTree.base = "${pkgs.raspberrypifw}/share/raspberrypi/boot/bcm2711-rpi-4-b.dtb"; hardware.deviceTree.overlays = [ "${pkgs.raspberrypifw}/share/raspberrypi/boot/overlays/dwc2.dtbo" ];``, but when the build process tries to apply the overlay, it's failing with ``Failed to apply '/nix/store/dn9n503g8ckl8r9xnz68wwb5zvfx48s1-raspberrypi-firmware-1.20190925/share/raspberrypi/boot/overlays/dwc2.dtbo': FDT_ERR_NOTFOUND``.