<samueldr>
well, xz on both side of ssh takes 15 minutes, while bland scp is 9 minutes
<DigitalKiwi>
oh yeah i forgot to mention it takes a long time to compress :)
<DigitalKiwi>
hmm, have you tried rsync -z ?
* DigitalKiwi
wonders if rsync can handle a delta of that
<samueldr>
ah, that was easy
<samueldr>
`Compression yes` for ssh and it goes down to 3 minutes
<gchristensen>
nice
<DigitalKiwi>
woo
<DigitalKiwi>
where do you put that?
<samueldr>
that's an option, so either -o on the CLI or in .ssh/config or an included file there
<samueldr>
it can be done per-host if needed
<DigitalKiwi>
can we login to the build server and build from there
<gchristensen>
try it! )
<gchristensen>
:)
<gchristensen>
caveat -- the server goes away on a regular basis, so don't store anything there long term.
<gchristensen>
be ready for it to go away at any moment
<DigitalKiwi>
aye
<samueldr>
because of how nix uploads things to the server when it starts a build, I always ssh in and start builds in tmux
<DigitalKiwi>
is the one you're rebooting on (monday?) this one?
<samueldr>
upload speed is... not good here
<samueldr>
yes, that server is (now) reset periodically
<samueldr>
well, now automatically
<DigitalKiwi>
is the time in the readme
<gchristensen>
no
<gchristensen>
1600UTC Mondays, plus any other times I decide to
<samueldr>
I guess it's better not to say, and say "whenever" :)
<gchristensen>
yup
<samueldr>
SLA is ∞ zeroes
<gchristensen>
haha
<samueldr>
or better
<gchristensen>
>=0
<DigitalKiwi>
oh samueldr i fixed my .bashrc and replaced those two functions with one super function! https://dpaste.de/9OU9
<samueldr>
the next step is (though there's nothing wrong with that) never use nix-env again :)
<samueldr>
systemPackages or nix-shell
<DigitalKiwi>
lol in #qfpl i was just talking about it
<DigitalKiwi>
nothing usually stays there for long it's only temporary if i don't want to rebuild (which usually kills my DE, mouse, network...) and takes a while
<DigitalKiwi>
sometimes i don't even keep the program soooo yeah, if i decide to keep it i move it to systemPackages
<DigitalKiwi>
and by fixed i mean that change you said and also i ran shellcheck on it until it's clean
<DigitalKiwi>
and if i put it in systemPackages then i'm more likely to forget to get rid of it
<DigitalKiwi>
a lot of those commands were/are training wheels i either use the real command often enough to not need it or i don't use the real command often enough to remember it/want to type it (like the nixhs-* ones)
<samueldr>
I'd be interested in opinions, questions, anything about this change, as it brings a breaking change for the aarch64 sd image (new ones only)
<samueldr>
(already generated and installed images are not affected)
<DigitalKiwi>
how does this affect me a raspberry pi 3 user
<DigitalKiwi>
3b
<samueldr>
current implementation: absolutely nothing changes
<samueldr>
erm
<samueldr>
no
<samueldr>
nothing changes as far as firmware installation goes
<samueldr>
but one thing changes: /boot is not on the FAT32 partition anymore (on new images)
<DigitalKiwi>
i don't know what fusing is in this context
* samueldr
will add a note about that
<DigitalKiwi>
if you think it's better it's probably better i'm just not sure what i'll have to do differently for new images etc.
<samueldr>
most likely nothing
<DigitalKiwi>
oh well then go for it ;D
<samueldr>
if you build a couple generations with different kernels or initrds, you'll hit the limits of the FAT32 partition and need to remove a couple earlier generations
<samueldr>
the FAT32 partition is only 120MiB
<samueldr>
with that change, /boot is now on the main partition, so is limited by the size of the partition
<DigitalKiwi>
i use nix-collect-garbage -d judiciously
<DigitalKiwi>
oh so question that thing to enable usb boot (assuming i didn't already do it i might have i'm not sure i've had the board a while) what are the reasons i wouldn't want to do it? security if it was in public or?
<samueldr>
the page I linked yesterday has the drawbacks, IIRC it's only that you lose those GPIOs
<samueldr>
so if you intend to do things with those they won't be available
<DigitalKiwi>
oh i didn't see that part
<samueldr>
>> it effectively makes 5 GPIOs unusable for other purposes.
jackdk_ has quit [Remote host closed the connection]
<DigitalKiwi>
is it possible to check from nixos or do i have to do it from raspbian
<samueldr>
this is done by the firmware at boot
<samueldr>
so any distro
<DigitalKiwi>
why do they design it to make the changes permanent?
<samueldr>
no idea
<samueldr>
it sounds like this was an afterthought and slipped in before validation, thus hidden behind a conditional
jtojnar has quit [Read error: Connection reset by peer]
jtojnar_ has joined #nixos-aarch64
udev_error has quit [Ping timeout: 272 seconds]
Thra11 has quit [Ping timeout: 244 seconds]
udev_error has joined #nixos-aarch64
udev_error has quit [Ping timeout: 272 seconds]
udev_error has joined #nixos-aarch64
jtojnar_ has quit [Quit: jtojnar_]
jtojnar has joined #nixos-aarch64
jtojnar has quit [Ping timeout: 245 seconds]
udev_error has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 248 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
Thra11 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<DigitalKiwi>
how long should i wait to ping people again about my PR (and who should i ping?)