<samueldr>
at most, it should be ~1h out of sync with the upstream mirror, unless a ton of huge files were added
<sphalerite>
I use your mirror, my own binary cache, and cache.nixos.org
<samueldr>
neat
<sphalerite>
my own binary cache is at https://sphalerite.org/cache if anyone wants to use it, although I don't put stuff in it very methodically
<sphalerite>
I have my server pull everything from my chromebook into that cache every hour, but what's on my chromebook varies :p
<samueldr>
still better than nothing
<sphalerite>
(so that I can gc on my chromebook with its very limited storage without losing hours worth of builds)
<samueldr>
since anyway, the revision of nixpkgs would affect what's available
<sphalerite>
yeah, I run nixos-unstable + a few extra commits on it
<sphalerite>
and don't update it very frequently because rebuiiiiiilds
<sphalerite>
I do have a number of useful things on there though, like qt (for telegram-desktop and vlc) and gtk (for pavucontrol) and gstreamer stuff
<samueldr>
I don't know if there's value into getting a synchronized nixpkgs unstable checkout
<samueldr>
with a reduced and previsible frequency for updates
<samueldr>
(I mean, and unofficial user-coordinated effort, not a mechanism from nixos)
<sphalerite>
like, nixos-weekly?
<sphalerite>
Wait no that name is taken :p
<samueldr>
unstable-weekly, a git checkout of the tip of nixpkgs-unstable (nixos-unstable?) done e.g. UTC 0:00 between saturday and monday
<samueldr>
uh, saturday and sunday
<sphalerite>
nixos-snapshot? We could start builds on the state at 23:59 every Friday and update the "channel" 23:59 on Sundays maybe, on the assumption that most people will have most of the stuff they want built over two days
<samueldr>
or that, yeah
<sphalerite>
(times UTC obviously)
<samueldr>
something that helps out not having to rebuild the world, instead of following the upstream channels
<sphalerite>
yeah. Although there are dependencies there that make stuff more complicated.
<sphalerite>
e.g. I'll be building gtk but would like to use Dezgeg's already-built stdenv for it
<sphalerite>
so much for it being that simple… :D
<samueldr>
hmm
<samueldr>
could it be a chain? a 0-packages channel updates to $SNAPSHOT, dezgeg's build builds... then updates its own channel to the same snapshot, and then yours knows it should be able to build
<samueldr>
I mean, it needs some more mechanisms that aren't there yet, but it would at least provide a known "as full as possible" build always, right?
<sphalerite>
yeah, although I usually just kick of the builds manually when I need them…
<sphalerite>
off
<sphalerite>
Is the latest commit that's been fully built actually shown anywhere?
<samueldr>
from dezgeg?
<samueldr>
last time I checked, no
<samueldr>
though, AFAIUI, we could extract the git commit from the images and then *do something with it*
<sphalerite>
oh yeah lol
<samueldr>
that would work as and if the images are always built after a build task
<sphalerite>
still, probably easier to make a PR to his scripts that just adds a file containing the commit :p
<samueldr>
the scripts are available on github
<samueldr>
yes
<Dezgeg>
maybe redirect to a github archive url would work
<Dezgeg>
I don't know if my host supports redirects in .htaccess though
<samueldr>
Dezgeg: if you do, please also provide it in clear, as such a redirect wouldn't work with my mirroring shenanigans :)
<samueldr>
(the commit ID)
<Dezgeg>
yeah, that would be easy
<sphalerite>
not entirely related: it should be fairly easy to split the kernel into two derivations, one for modules and one for the image, right? Would it be beneficial (i.e. do they share much code)?
<sphalerite>
it would be really nice if I could reduce the kernel build time by just building different parts of it on different machines
<Dezgeg>
I don't think they could build in parallel
<Dezgeg>
the modules would depend on the kernel proper, probably
<sphalerite>
aww
orivej has joined #nixos-aarch64
Sonarpulse has joined #nixos-aarch64
<gchristensen>
Dezgeg: does your hydra have a channel?