<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)
<gchristensen> what is nixhs?
<gchristensen> ah
<DigitalKiwi> see i do use nix-shell :P
<DigitalKiwi> (i use it a lot actually especially now because of lorri)
udev_error has joined #nixos-aarch64
udev_error has quit [Ping timeout: 248 seconds]
udev_error has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<samueldr> hey aarch64 board maintainers, and board users, and curious people
<{^_^}> #62462 (by samueldr, 29 seconds ago, open): sd-image: FAT free /boot
<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?)
<DigitalKiwi> and is the weekend a factor
jackdk has joined #nixos-aarch64
orivej has quit [Ping timeout: 245 seconds]