<edrex>
gchristensen: A follow-up on the OT from the other day: I just learned the new Quartz64 board has a driver for a 10.3" eink panel. Soooo i know what my next SBC is going to be.
<edrex>
samueldr it would be interesting to start to document "expected to be working" user envs. I'd be happy to work on some docs as I'm getting that moto configured (assuming that works out, but it seems like it should)
<edrex>
do you get a tty console if you don't configure anything?
<samueldr>
ignoring the "get a known working Nixpkgs revision"
<samueldr>
if you build at the root of the project you get different results depending on the device
<edrex>
since this is all hypothetical for me at this point i don't feel any of this pain yet
<samueldr>
if there's a working "tty" driver, you'll have a console
<samueldr>
otherwise it'll appear to hang
<samueldr>
(many vendor trees don't have a working tty)
<edrex>
does nixpkgs break a lot with aarch64? or just upstream breaks mobile-nixos generally?
<edrex>
oh, ok
<samueldr>
cross-compilation is what breaks generally
<samueldr>
but that's if you build at the root
<samueldr>
since at the root it's uh... a scratch space
<samueldr>
this cross-compiles fine [when no issues upstream]
<samueldr>
and it provides enough to test that the display works, and touch, and other things
<edrex>
what are your thoughts on providing a flake.lock with a "suggested" nixpkgs revision?
<samueldr>
I don't want to start using flakes until it's ready
<samueldr>
though I guess an in-repository entry point that uses a known good Nixpkgs revision isn't a bad idea
<edrex>
like, no longer behind experimental flag? seems like most projects are providing some level of support now, but yeah, that makes sense. I'm like one of those kids that grew up with smart phones. There was a time before flakes?
<samueldr>
yes, there was a time before flakes :)
<samueldr>
and yeah, no longer behind an experimental flag
<gchristensen>
17 years without flakes :P
<samueldr>
it's also because that since I don't know flakes, and don't want to have to follow an in-development thing, I don't want to have to support it :)
<samueldr>
unless I start having a proven long-term collaborator maintaining the project with me, it won't happen with flakes for now
<samueldr>
but yeah, I'll think about a good way to have a known good nixpkgs revision usable
<gchristensen>
niv is nice
* gchristensen
forces himself to actually disappear now.
<samueldr>
haha
<samueldr>
yeah, I wanted to look at niv, I don't need "fancy" locking or anything
<samueldr>
and I don't want it to _default_ to a locked version either
<edrex>
I wonder how the user base has grown in that time
<edrex>
<samueldr "and I don't want it to _default_"> this is IMO a rough edge in flakes, you have to say `inputs.mobile-nixos.inputs.nixpkgs.follows = "nixpkgs"` to avoid using the pinned nixpkg
<samueldr>
yeah
<edrex>
and those lines will explode as things move more away from nixpkgs monorepo
<edrex>
but maybe there will be a handy helper to force everything to follow
<samueldr>
*if* things move away from the monorepo, it's not a foregone conclusion that Nixpkgs will split, or that it will not continue acting as the de facto monorepo
<samueldr>
AFAIUI it's more meant for better wrangling of non-Nixpkgs things
<DavHau[m]>
Isn't flakes just a more mature version of niv? If you haven't looked into any of these yet, then I'd assume that you will waste your time with niv. Flakes is nicely integrated into the nix tool itself. And for simply managing a few inputs it should be stable enough.
<samueldr>
not really, it's way more
<samueldr>
flakes also deals with discovery
<samueldr>
and interfaces
<samueldr>
niv AFAIUI is really just about making a lock file
<edrex>
yeah, i don't doubt that nixpkgs will remain the main place people get software, and also it's a really appropriate place for a monorepo. just there is a slow creep of new repos, and flakes encourages small repos so...
<samueldr>
small repos always have been a thing :) now they'll have a better **interface** both to use other things, and be used by other things
<edrex>
Is the underlying reluctance for flakes from folks who have been here awhile something to do with concern that things start to look like npm?
<samueldr>
I don't know
<samueldr>
I haven't been looking too much into Flakes, the truth, nor the FUD
<edrex>
anyway, sorry OT again. i have a problem with that, i am chatty
<DavHau[m]>
<samueldr "flakes also deals with discovery"> It does, but you can also just use it for simple version management ;). And that is not more difficult than with niv
<samueldr>
niv works without me needing to use unstable Nix
<samueldr>
(I assume)
<samueldr>
I haven't used niv either
orivej has quit [Ping timeout: 252 seconds]
<samueldr>
and to date, every time I have had to use flakes, the command line or some other part of it was different enough to break my existing limited knowledge
<samueldr>
which is fine, since it's not ready yet
<DavHau[m]>
To be honest I never really used niv as well. I just know, since i started using flakes, I'm amazed and don't want to ever go back again. Same story like with nix itself. Flakes feels like kind of the next step in the nix evolution.
<samueldr>
oh, most probably
<samueldr>
I'm not a flakes-sceptic
<DavHau[m]>
Nix expression finally become reproducible
<samueldr>
well
<samueldr>
see
<samueldr>
the evaluation will
<samueldr>
as it can already
<samueldr>
but that won't guarantee the same outputs :)
<DavHau[m]>
<samueldr "as it can already"> It can, but with flakes it is by default
<samueldr>
DavHau[m]: I don't know what you're trying to do
<samueldr>
but if you're trying to "convert me", it won't work
<samueldr>
I'm not against flakes
<DavHau[m]>
Hahaha ok
<samueldr>
but I won't promote an unfinished feature until it is ready to be used
<samueldr>
it has already caused damage by being overhyped
<samueldr>
when I say "limited knowledge" about flakes, it's about day-to-day usage
<samueldr>
I know the foundational concepts well
<samueldr>
so I'm most likely to be a flakes user the moment it's ready to be "actually" pre-release
<DavHau[m]>
Sounds reasonable
<samueldr>
and I don't think what I'll do will end up using niv either
<samueldr>
probably will be something bespoke and simple, since the only dependency to track is Nixpkgs
<samueldr>
something like `nix-build --arg pkgs '(import ./nixpkgs.nix)'`
<samueldr>
I'll see if there's a better end-user UX for that, but that would be more for "things are broken, is it a nixpkgs regression? let's have a known good revision to test against!)