ryantrinkle has quit [Remote host closed the connection]
ryantrinkle has joined #nixos-aarch64
wavirc22 has quit [Read error: Connection reset by peer]
wavirc22_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
zupo has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 272 seconds]
h0m1 has joined #nixos-aarch64
MatrixBridge has joined #nixos-aarch64
MatrixBridge has left #nixos-aarch64 ["User left"]
bqv90 has joined #nixos-aarch64
MatrixBridge has joined #nixos-aarch64
MatrixBridge has left #nixos-aarch64 ["User left"]
MatrixBridge has joined #nixos-aarch64
MatrixBridge has left #nixos-aarch64 ["User left"]
<bqv90>
anybody here an op?
<bqv90>
looking to bridge this channel to matrix so i don't have to be here on irc :) chanserv doesn't see this as registered and nobody's currently +o afaik
<samueldr>
that was written when I was trying to work on hydra-eval-jobs
<bennofs>
ah, release-20.03 has a buildable hydra package it seems
<samueldr>
hydra.conf held values for heap size and such
<samueldr>
though not required IIRC
<bennofs>
cool, seems to work, thanks
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 250 seconds]
zupo has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
<bennofs>
actually, what's the advantage of having a separate jobset for aarch64
<bennofs>
ah, I guess we don't want to make the main channel wait on aarch64 builds
ZoomZoomZoom has joined #nixos-aarch64
<samueldr>
it was required in the past due to limitations in the eval
<samueldr>
how with string-based evals the limitation has been lifted up
<samueldr>
(we basically broke some memory allocation limits)
<samueldr>
with the following release (20.09) we should be doing a common channel
<bennofs>
well, why would we want to block the x86_64 channel if there is a backlog in aarch64 builds? doesn't make much sense to have a common channel to me
<samueldr>
I don't think we are having issues with load
<samueldr>
so it shouldn't break it
<samueldr>
what happens with a split channel is what we're seeing
<samueldr>
it stops working for over a month
<bennofs>
the current setup is a little bit weird. The main jobset (nixos-20.03) still runs the tests for aarch64 nixos, but doesn't build all of nixpkgs for it
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bennofs>
so it depends on the parts of nixpkgs required for the tests, but nothing more
<samueldr>
yep
<samueldr>
that's the main reason this slipped past
<bennofs>
if we have enough capacity, why wait for the next release though?
<samueldr>
let's not rock the boat for the currently ongoing release
<samueldr>
anyways, bennofs, this needs to go through master first, and cherry-picked/adapted
<samueldr>
the same issue exists on master, it's just that we don't have a split eval there
<bennofs>
oh ok. Well master has had some tests added, and this doesn't really merge cleanly
<samueldr>
yep, I kinda assumed adaptation was going to have to happen :)
<bennofs>
so I need to basically do it twice anyway :)
<bennofs>
I wasn't quite sure if we even want this for master, if we want to switch to a different style for next release?
<bennofs>
anyway, I'll make a version for master
<samueldr>
all changes to releases like these should go through master, generally
<bennofs>
hmm, do we want aarch64 nixos tested to become part of the tested job on trunk-combined?
<samueldr>
ooh, good question
<bennofs>
we don't have this problem for the release jobsets, since they're split
<bqv[m]>
so i'm starting to understand how linux on phones works, or at least how postmarketOS works. i'm guessing the mobile nixos project is just about creating a working rootfs, nothing to do with getting working mainline kernels etc.
<bqv[m]>
so this project is kinda dependent on pmOS's efforts still
<samueldr>
bqv[m]: exactly, mainlining efforts are orthogonal
<samueldr>
and no, we're independent from postmarketOS
<samueldr>
though what applies to one applies to the other generally
<bqv[m]>
gotcha
<samueldr>
my opiniong on mainlining: yes, please, but the project will keep working on vendor-kernels for the devices without mainlining efforts
<bqv[m]>
ah, right
<samueldr>
especially since it's kinda expected that vendor kernels will at some point be able to use all the hardware features, while mainlining, well, there's mor work for that
<bqv[m]>
hmm
<samueldr>
Mobile NixOS will prefer pragmatic over idealistic, if only for ensuring people can *use* it
<bqv[m]>
i like that
<samueldr>
but I personally would like it if all devices could have mainline support!
<samueldr>
when I'll have a mainline-able device, I'll look into making it trivial enough to build both the mainline and vendor based kernels
<bqv[m]>
honestly i'm just trying to get pmOS to even boot