<samueldr>
ah, I didn't state what the issue was at the time
<samueldr>
well
<samueldr>
I didn't repeat the issue
<samueldr>
I'm not facing it right now, it's 1080p + 1440p, the rendering is basically broken
<samueldr>
not slow, just not working properly
stiell has quit [Ping timeout: 256 seconds]
stiell has joined #nixos-aarch64
<samueldr>
wow, vlc's perfs are much better
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 265 seconds]
ryantrinkle has quit [Ping timeout: 258 seconds]
stiell has quit [Ping timeout: 256 seconds]
<samueldr>
and had issues, which may or may not be caused by the raspberry pi, but too much to investigate in not enough time
stiell has joined #nixos-aarch64
<colemickens>
samueldr: you might see scrollback in Nix Community. I was asking about something you touched on in your latest flake reply.
<colemickens>
Basically there IS an implicit nixpkgs provided to flakes that is the system nixpkgs.
<samueldr>
oh, while I saw the question, it didn't dawn on me it was relevant
<colemickens>
I'm wondering if the PR could simply omit that. Though, I also feel the problem is the same either way.
<colemickens>
Actually no, I think I see the point, if there was a CI job advancing flake.lock it would be an easier sell, I think.
<colemickens>
Eh, poor communication, I'm talking past myself. I do think a solution might be just omitting the explicit nixpkgs input in the PR, then it should follow the users system/nix_path pkgs as it does now.
<samueldr>
would it really be? without cache I'm not sure
<{^_^}>
#72715 (by saboteurspk, 44 weeks ago, open): Phosh - Mobile-friendly replacement for the GNOME shell
<colemickens>
samueldr: isn't that just the same situation as now? It builds against whatever is in NIX_PATH?
<samueldr>
if we omit, yes
<samueldr>
I was talking about advancing with CI
* colemickens
is failing at both r/w tonight
* colemickens
nods
<samueldr>
without a cache there's no real advantage compared to falling back to the user's nixpkgs, I think
<samueldr>
I'd prefer keeping the status quo of hoping for the best with any given nixpkgs than having a tested stale nixpkgs
<samueldr>
if it matters to the user, they can pin as they want
<colemickens>
I think that makes sense to me too, I just hadn't had to consider this exact usage of flakes until now. It seems it might be worth advising omitting nixpkgs in cases like this almost.
<samueldr>
I think it also hinges on what you want to do
<samueldr>
do you provide a cache? if so it makes sense to pin
<samueldr>
or is it a self-contained solution with careful testing and planning? yet again makes sense
<samueldr>
here it's a pile of patches I'm throwing at whatever kernel is current
* colemickens
thinks one sounds more ideal maybe, given infinite resources
justanotheruser has quit [Quit: WeeChat 2.7.1]
<samueldr>
can you rephrase?
<colemickens>
oh I just mean ideally there would be CI-gnomes to come and build out CI jobs to try advance a pinned nixpkgs and verify all builds pass.
<samueldr>
ah, right
<colemickens>
but in lieu of that, and given constrained resources, and lack of those things...
<samueldr>
yeah, I'd like to throw a trustable hydra infra to that and give out binaries
<samueldr>
and flakes sure would help into pinning the right inputs!
<Jake[m]>
Ha I just responded on the PR but I see the flakes discussion here too. I guess my take (and feel free to disagree) is that pinning doesn't cost anything in that you can always override it, whereas without flakes there's this secret dependency on the environment that makes debugging and reproducing more difficult, which is supposed to be nix's strength.
<Jake[m]>
Though I agree that that does impose a cost in that you have to know that a) the default is to ignore your channel and b) how to override inputs. So those are practical costs today.
<Jake[m]>
So I don't think it's so much about CI. It's more about extending the Nix idea of reproducibility all the way and getting rid of the impurity of NIX_PATH
<samueldr>
yeah, I think mainly pragmatically speaking, for this specific use cases it has more drawbacks to pin since we can't pin *only if it's being nix-built*
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 256 seconds]
<Jake[m]>
If by being nix-built you mean built using nix flakes, then I think we actually might be able to.
<Jake[m]>
... able to only pin when using flakes.
<samueldr>
I meant using the repository as the "main input", in a way, like git clone ... ; nix-build -A ubootInstaller # or whatever incantation for using nix flakes
<samueldr>
but if you used it in your configuration, as a flake, it would default to using the default nixpkgs for your config
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Jake[m]>
Oh, well I think we can distinguish between cloning and running "nix-build" on the one hand as the non-flake, "default.nix" case AND either cloning and running "nix build", not cloning and running "nix build github:samueldr/wip-pinebook-pro", or using it in some other "flake.nix" on the other hand as the flake case.
<Jake[m]>
The distinction between "nix-build" and "nix build" for non-flake and flake is dumb, and tbh I'm not sure what's planned for that going forward if the old commands are deprecated, or if we'll all be forced to use flakes. I think that you can use nonflakes with the new style commands with the "-f" flag but maybe that's wrong.
<samueldr>
I shouldn't have used "nix-build" to make it confusing
<samueldr>
but I mean the use case
<samueldr>
when used as an input to a user's config vs. when used directly
<Jake[m]>
No I don't think we can do that.
<Jake[m]>
But also, I do think it's a little tricky, in that for example if you use the overlay exposed by the flake, you're not actually using the pinned nixpkgs at all, your using whatever nixpkgs you apply the overlay to. So in that sense using in a config is not pinning whereas using directly is 🙃
<samueldr>
I guess I really need to play more with flakes to grok all that
<samueldr>
and by more, I mean at all
<Jake[m]>
Okay, sorry if I'm making it sound more complicated than it is.
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
stiell has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
stiell has joined #nixos-aarch64
stiell has quit [Ping timeout: 265 seconds]
stiell has joined #nixos-aarch64
stiell has quit [Excess Flood]
stiell has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has quit [Ping timeout: 246 seconds]
cript0nauta has quit [Remote host closed the connection]
criptonauta_ has joined #nixos-aarch64
alp has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 260 seconds]
Darkmatter66 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
<superherointj>
samueldr, thanks again for helping with GIT. Now I know I don't know using Git. Still got 20.03/20.09 backport PR ready: https://github.com/NixOS/nixpkgs/pull/97614
<justanotheruser>
why do some devices not require a `mobile.device.firmware` definition? e.g. asus-x018d
<samueldr>
it's not that they don't require one, but that they don't have one yet
<justanotheruser>
so they don't work?
<samueldr>
some features won't
<justanotheruser>
I see. Thanks!
<samueldr>
if they're listed on the site, they can boot to a GUI
<samueldr>
touchscreen should work too
<samueldr>
but things like graphics acceleration, wifi, bluetooth, modem, etc, are not a given
<samueldr>
still need to figure out the best strategy to gather and show that information
orivej has quit [Ping timeout: 246 seconds]
alp has joined #nixos-aarch64
juliosue1ras has joined #nixos-aarch64
juliosueiras has quit [Read error: Connection reset by peer]
alp has quit [Ping timeout: 272 seconds]
ryantrinkle has quit [Ping timeout: 240 seconds]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 240 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
<justanotheruser>
Probably a dumb question. Why does nixos-mobile need to load firmware? Couldn't it just leave the existing firmware on the machine untouched?
<clever>
justanotheruser: the bootloader may not initialize things like wifi or cellular firmware
<samueldr>
justanotheruser: depends on the device
<samueldr>
some don't ship firmware at all
<samueldr>
it's part of the android system image
<samueldr>
some have a vendor partition, like more recent devices
<justanotheruser>
clever: wait, does the firmware in package definitions refer to the software interface to the firmware, or is it flashing the firmware?
<samueldr>
those we can reuse it
<clever>
justanotheruser: often, the card just lacks flash to hold the firmware
<samueldr>
clever: please don't confuse people with the overloaded firmware word
<samueldr>
but yeah
<clever>
yeah, firmware is a very vague term
<clever>
some devices lack flash to hold firmware, so it has to be loaded into device ram at boot
<samueldr>
just like on your laptop you are likely to load a firmware to the wifi adapter
<clever>
yep, exactly
<samueldr>
except now you have quasi-bespoke firmware per-device instead of being per adapter
<justanotheruser>
ah, I didn't realize firmware was ever kept on disk
<justanotheruser>
I mean, the same device as the OOS
<justanotheruser>
OS*
<samueldr>
yeah, that's an annoying truth :)
<samueldr>
otherwise it'd be easier to deal with
<samueldr>
justanotheruser: looking at something particular with Mobile NixOS?
<justanotheruser>
well, I want to try to install it on my fairphone 3+