<Irenes[m]>
it's a little weird to put import inside the imports like that, but...
<samueldr>
if you didn't know, imports does not only take paths
<Irenes[m]>
hmmm
<samueldr>
you can `imports = [ { a.nixos.option = true; } ];
<Irenes[m]>
I did not previously know that, yeah
<samueldr>
which is how and why this works :)
<Irenes[m]>
right, yeah
<Irenes[m]>
honestly it feels like it would be more idiomatic to just do `imports = [ <nixos-mobile/...> ]; config.nixos-mobile.device = "xxx-yyy";`
<Irenes[m]>
and then have the result of setting that option be to set all the other config things it wants to set
<samueldr>
cyclic dependencies, the device cannot be defined in the config with how some things work
<Irenes[m]>
hm
<Irenes[m]>
I'll take your word for that
<samueldr>
at least, last time I tried to do away with the way the devices were handled, that's what I think the result ended up being
<Irenes[m]>
I see
<samueldr>
though now I'm doubting
<Irenes[m]>
it feels like that's what the whole fixed-point evaluation of nixpkgs is meant to address
<samueldr>
I'll try again tomorrow
<Irenes[m]>
good luck!
wavirc22 has quit [Read error: Connection reset by peer]
wavirc22 has joined #nixos-aarch64
<leonardp>
samueldr: isn't that a problem that would/could be solved by using flakes?
<samueldr>
flakes are for the future
<leonardp>
or is it way to early to use flakes?
<leonardp>
oic, then i really like the approach
<samueldr>
though I wouldn't mind being compatible with flakes *also*
<samueldr>
but I have not much experience with them for now
<leonardp>
way more transparent than somehow juggling with overlays
<samueldr>
my main concern with that PR, btw, is that I want an API that can stay stable even if the implementation changes
<samueldr>
also why it's a set-pattern function
<leonardp>
thats good to hear, i also played around a little with flakes but their incompatibility with nixops makes it impossible for me to use them right now :/
<leonardp>
i do not know enough about the underlying implementation of nix/nixos to be able to judge that, but from a 'user' point of view i like it :)
<samueldr>
that's a valid point of view, more so that I want it to be palatable to less experienced users too
zupo has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
FRidh has quit [Ping timeout: 256 seconds]
zupo has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-aarch64
FRidh2 has joined #nixos-aarch64
FRidh has quit [Ping timeout: 264 seconds]
zupo has joined #nixos-aarch64
fooker has quit [Ping timeout: 240 seconds]
fooker has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
FRidh2 has quit [Ping timeout: 256 seconds]
zupo has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
thefloweringash has quit [Ping timeout: 246 seconds]
thefloweringash has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
lordcirth has quit [Remote host closed the connection]
<samueldr>
okay, just looked quickly, `imports` relying on a config indeed makes it an infinite recursion
<samueldr>
this could be solved like system types are, by making the device config conditional by name on the device name, and always import all devices
<samueldr>
but this means that adding a device is adding a file and condition, and the device file gets more unwieldy
<samueldr>
in addition, this makes it harder to pass "special" configurations to use, rather than a device name
<samueldr>
or even something I want to add, allow passing a path, so you can use an out-of-tree device
orivej has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 264 seconds]
zupo has quit [Ping timeout: 250 seconds]
zupo has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
<ashkitten>
hmm i wonder if mobile nixos could be built as a gsi-compatible image to be used with android 10's "dynamic system update" thing
zupo has joined #nixos-aarch64
<ashkitten>
oh, but that requires a signature from google or the vendor i think
<ashkitten>
unfortunate
<samueldr>
GSI-compatible maybe, but not exactly trivial as it would require us to actually use the system partition
<samueldr>
and yeah, installing through those fun bits probably out of the question :(
<samueldr>
(I also don't know what would have to be done with userdata)
<samueldr>
I also think we'd have to deal with the actual vendor kernel image, and not only the tree
<ashkitten>
i figure we could potentially build a gsi-compatible image that's just stage-1 and requires you to have an sdcard for stage-2
<samueldr>
which would mean we'd have to deal with android paranoid networking
<samueldr>
among other non-android unfriendly options
<ashkitten>
oh i see
<samueldr>
though an interesting idea
<ashkitten>
we could kexec into our own kernel though, yes?
<samueldr>
if the vendor kernel left kexec in
<ashkitten>
oh right
<samueldr>
it would be an interesting endeavour later on, though, to make a system image that is compatible to run with a standard vendor kernel
<ashkitten>
yeah
<ashkitten>
but if we can't even run it in the first place because of keys...
<ashkitten>
meh
<ashkitten>
easier to just fastboot boot
<samueldr>
well, here I'm thinking about GSI-compatible devices with unlocked bootloaders
<samueldr>
it could maybe help users that can't really or don't know how to make the kernel work getting started?
zupo has quit [Remote host closed the connection]
<samueldr>
though yeah, not as useful as if it was a one-tap thing through that dynamic system update thing
<ashkitten>
oh, yeah
<ashkitten>
that makes sense
<ashkitten>
to build it as a gsi image without a kernel
zupo has joined #nixos-aarch64
<ashkitten>
hmm, i wonder if that would let us have working drivers without libhybris, at least for the moment...
<samueldr>
I don't think it would help more than a custom built kernel
<samueldr>
in fact it would lock us more in using libhybris
<samueldr>
but I'm not 100% sure
<ashkitten>
hm
<ashkitten>
dunno
<ashkitten>
i mean, obviously not as a long-term solution
<ashkitten>
i'm just wondering if it would work
<samueldr>
we're basically building the same kernel, but with more options enabled. In the past I accidentally booted Android using the mobile nixos built kernels :)
<samueldr>
(this makes me think I could be doing that on my current daily driver device rather than rely on whatever was built...)
<samueldr>
>> [The low-level] commands are generally referred to as Git’s “plumbing” commands, while the more user-friendly commands are called “porcelain” commands.
<ashkitten>
git is a toilet?
<samueldr>
yes!
<samueldr>
(or a sink)
<ashkitten>
lol
<samueldr>
that command is a wrapper on top of doing it manually using what the nix expression gives us
<ashkitten>
i see
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Irenes[m]>
samueldr: you shouldn't need imports to rely on config though, you can always include all the files but then make the *options* rely on the config
<samueldr>
yep, next lines :)
<Irenes[m]>
sorry, still catching up on scrollback
<samueldr>
no worries
<samueldr>
it ends up being problematic for other designs that I have in mind, to do it that way
<Irenes[m]>
I would, in fact, appreciate being able to make imports rely on config, personally, there are a lot of things it would be cleaner for
<samueldr>
though I figure it could be done that way at some point in the future
<samueldr>
yeah
<Irenes[m]>
hmm
<Irenes[m]>
the way imports are resolved is implemented within nixpkgs. I wonder if there's already been a principled decision not to let it depend on config.
<Irenes[m]>
I'll go ask in #nixos-dev I guess.
<samueldr>
infinisil may know as he looked at it to conditionally load parts of the nixos options as a way to reduce the time spent evaluating the options, and do ask
<Irenes[m]>
good to know, will do
<samueldr>
if it wasn't for the added boilerplate, I think I would do it that way