rajivr has joined #nixos-aarch64
heywoodlh has quit [Ping timeout: 256 seconds]
heywoodlh has joined #nixos-aarch64
__red__ has joined #nixos-aarch64
<__red__> Is the Raspberry Pi the most common target for this arch?
<__red__> anyone else running anything more exotic?
<__red__> (I don't suppose anyone's got any of those 128 core servers yet eh? ;-)
<andi-> Do not go done that path :D
<andi-> and yes we've a community machine with 64ish cores or so
<__red__> tee heee
<__red__> I want one :-)
<gchristensen> ampere's machines are affordable (for servers) and have great cpus
<__red__> Ím waiting for the first generation of ARM servers to fall out of the cloud and onto ebay
<__red__> shhouldn't be long now
<gchristensen> probably already did as the cavium thunderx2 has been out for quite some time
<andi-> clever: have you tried the recent RPi kernel images? I just built 5.4.72 with the matching firmware and the machine is a lot more responsive.. Reboots do not take forever.. It doesn't load audio drivers anymore thought and after loading the manually there is no interface..
<__red__> the closest I've seen to affordable ARM server gear for a human is on ebay, about $1330 ish
<gchristensen> the cavium thunderx's 96 cores were kinda junky though
<__red__> I'm wishing I still had access to Niagara CPUs
<__red__> but they're long in my past :-(
<gchristensen> you might find even more exotic hw out there: experimental runs where a few racks were made and discarded
<__red__> that would be nice
cole-h has quit [Ping timeout: 260 seconds]
<__red__> I'd like to target my phone at some point too
<__red__> but that's another story
<gchristensen> the very experimental runs are *annoying*
<gchristensen> I've got access to a dozen or so of them and I can't really be bothered to make them run properly
<__red__> How do you get access to such things?
<gchristensen> being friendly with Equinix Metal / Packet at the time
<gchristensen> and being able to put the hw to good use
<__red__> makes sense
<__red__> so just wishing into thin air doesn't work
<__red__> got it :-)
<gchristensen> they have hw they can't really sell, but already have and providing power, cooling, and bandwidth is cheap compared to buying good will and training platform experts :)
<__red__> every so often the AWS / Google / Facebook recruiters poke me via email
<__red__> and each and every time I go "nope" to facebook, and I never gather up the courage to ask how much AWS / GCP resouurces AWS/Google employees get
<__red__> I never ask because I'm worried the answer might make me want to change companies ;-)
<gchristensen> hehe
<gchristensen> I have reason to believe Googlers get ... uh ... generous ... amounts of GCP
<__red__> hah
<__red__> I have a friend of mine that told me the same thing about AWS
<__red__> At some point it is inevitable taht I will end up in one of those places
<__red__> or in one of the security consultancies
<__red__> it's inevitable with the way the industry is going, but I really don't want to move right now.
<__red__> ho hum
<__red__> anyways - a conversation for another time and place
justanotheruser has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
alp has quit [Ping timeout: 256 seconds]
jakimfett has joined #nixos-aarch64
jakimfett has left #nixos-aarch64 [#nixos-aarch64]
jakimfett has joined #nixos-aarch64
<jakimfett> I've got a nixos system running on a pi 4, and it all works...except 'nixos-rebuild switch' doesn't seem to be making the new configuration persistent (reboots put me back to the default user, without the software installed from before the reboot).
<jakimfett> ...kinda uncertain which layer I've borked things at, anyone want to give their thoughts on the matter?
<jakimfett> That said, I also tinkered with the boot device, and it's possible I've forked myself over with that, somehow. Specifically, I ran into the '/boot device full' issue (as described here https://github.com/NixOS/nixpkgs/issues/23926), which led me to the page which recommends removing the /boot device entirely:
<{^_^}> #23926 (by joepie91, 3 years ago, open): When /boot is full, system rebuilds fail
<samueldr> with the current pi 4 image, you'll have to make sure the FAT32 partition is mounted at /boot
<samueldr> otherwise you're making copies of the files on the ext4 partition that won't be used by the raspberry pi proprietary bootloader
<__red__> does anyone here have any experience with this? https://www.solid-run.com/nxp-lx2160a-family/honeycomb-workstation/
<__red__> it doesn't seem too insane price-wise
<samueldr> IIRC at least one user has one
<samueldr> looks interesting, though I was turned off by the initial batch being shipped without a complete firmware
<samueldr> the developer batch also had other misc. differences / issues, but I can't remember what
<__red__> thanks, looking
<thefloweringash> I'm running nixos on a developer batch one
<samueldr> hi, didn't want to needlessly point you out :)
<samueldr> I was curious, are you using it as a workstation?
<thefloweringash> hello :-)
<thefloweringash> I'm using it headless
<samueldr> I'd really like an overview/opinion/review/opiview? of someone who's using one as a workstation :)
<__red__> me too
<__red__> it looks like an interesting option
<__red__> I'd love to get a comparison with this:
<thefloweringash> with all that sfp+ I'm tempted to use it as a router
<samueldr> >> Your Kobol Innovations order has shipped
<samueldr> !!
<__red__> Kobol Innovations?
<__red__> looking
<samueldr> it had been discussed here a couple of times in the past
<samueldr> and I feel like I'm the last one here that will git it lol
<__red__> huh
<samueldr> that will get it*
<__red__> I standardized what feels like an age ago on the odroid HC-2s
<__red__> I have 4 of those running a local glusterer
<samueldr> I don't like the fact it's armv7l
<samueldr> also, the helios64 has more "fun" features, e.g. you can directly attach it to a computer through USB
<samueldr> it's like 80% of a full NAS box product, the missing part is the software
<__red__> What I really want is an ARM box I can plug an SF86(ish?) connector into
<__red__> lemme get the correct name for that
<__red__> sec
<__red__> SF08088
<samueldr> the Helios64 also has interesting small tidbits, like a standard form factor (mini ITX IIRC)
<__red__> SFF-8088
<__red__> even
<samueldr> ah, SAS
<__red__> so it can run my backup software
<__red__> for my tape robot
<samueldr> so yeah, you *could* run the Helios64 board in a normal tower PC case, and run a normal Mini-ITX board in the case
<samueldr> which makes it an attractive proposition compared to bespoke hardware incompatible with anything and everything
<__red__> I'm still drooling over this for my next keyboard and interface for a console
<__red__> but I can't justify driving to CA
<jakimfett> Thanks, samueldr. That explains my issue.
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<jakimfett> Hmm. So, now I'm back to the same issue as before...getting the error saying "no space left on boot device", is there a way to just bump the boot partition size up to a gig (or at least something larger than 128mb)?
<samueldr> manually
<samueldr> sorry :/
<samueldr> (or edit the derivation in Nixpkgs and build a custom .img)
<jakimfett> Yeah, working towards custom images, not quite there yet on my homelab.
justanotheruser has quit [Ping timeout: 244 seconds]
<jakimfett> Any deviation from the normal process on juggling partitions, or is it pretty much the same as Adafruit makes it out to be?
<jakimfett> (in essence, delete the existing boot partition, resize the main one, create a new one with the desired size, then restore the files from pre-delete?)
<samueldr> I have skimmed the PDF, not sure where it tells you to delete
<samueldr> but you can just resize "from the left" the ext4 partition, and resize the FAT32 one accordingly
<samueldr> I would use gparted for that
<jakimfett> Page 14
<jakimfett> And I'm about to attempt that, but I've got to reboot first. brb.
jakimfett has left #nixos-aarch64 [#nixos-aarch64]
<samueldr> it seems unnecessary to delete the partition
<samueldr> oh, maybe FAT16
<samueldr> probably limited in total size
<samueldr> in that case yeah
<samueldr> there is nothing special to do with the FAT32 partition
jakimfett has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
jakimfett has quit [Quit: Leaving.]
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
FRidh has joined #nixos-aarch64
ehmry has joined #nixos-aarch64
taktoa[c] has quit [Ping timeout: 260 seconds]
taktoa[c] has joined #nixos-aarch64
<sphalerite> __red__: if you have the budget, you could get a https://shop.solid-run.com/product/SRLX216S00D00GE064H06CH/ and plonk a PCIe SAS HBA on there.
<Ke> or mcbin for slightly cheaper
<Ke> though mcbin just stopped working on mainline linux
<Ke> or at least when booting with u-boot
alpernebbi has joined #nixos-aarch64
orivej has joined #nixos-aarch64
cole-h has quit [Ping timeout: 272 seconds]
alp has quit [Ping timeout: 272 seconds]
superherointj has joined #nixos-aarch64
alp has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
alp has quit [Ping timeout: 244 seconds]
monk has joined #nixos-aarch64
alp has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
<__red__> sphalerite: Indeed. I guess I just need to be sure that the kernel driver for the SAS cards actually work
monk has joined #nixos-aarch64
zupo has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
veleiro has joined #nixos-aarch64
alp has quit [Ping timeout: 260 seconds]
monk has left #nixos-aarch64 ["Error from remote client"]
superherointj has quit [Quit: Leaving]
monk has joined #nixos-aarch64
<veleiro> has anyone gotten the pinebook pro to suspend properly+
alp has joined #nixos-aarch64
veleiro has quit [Ping timeout: 260 seconds]
PetitOrion has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: Textual IRC Client: www.textualapp.com]
alp has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
veleiro has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<veleiro> woo the pinebook pro trackpad much better after colemickens fork
<colemickens> wut
<colemickens> I don't think I have any relevant fork of wip-pinebook-pro around?
<veleiro> it was relevant to me
<veleiro> i'm a few months behind
<colemickens> aha, that's a fork of samueldr's work. I merely contributed a tiny change.
<colemickens> (which was someone else's work from a different project that I just ported into wip-pinebook-pro)
alp has quit [Ping timeout: 240 seconds]
<veleiro> its more than I was able to find
<colemickens> It would be nice if GH made it easier to distinguish what type of fork a repo is. Some GH forks are merely for contributions to their parent, whereas others are meant as standalone forks.
<veleiro> true, i shouldnt say fork in that case
<veleiro> branch or feature
<colemickens> veleiro: I just like to give credit, and also I don't know that my fork stays up to date with the changes made in the upstream wip-pinebook-pro.
monk has joined #nixos-aarch64
<veleiro> well the flake stuff wont be merged in the repo yet i'm sure
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
ardumont has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
PetitOrion has left #nixos-aarch64 ["Quitte"]
justanotheruser has quit [Quit: WeeChat 2.9]
justanotheruser has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
veleiro has quit [Ping timeout: 260 seconds]
ryantrinkle has quit [Remote host closed the connection]
ryantrinkle has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 265 seconds]
zupo has quit [Ping timeout: 272 seconds]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
<sphalerite> __red__: I have no experience with either in hardware, but thefloweringash has one and was running nixos on it last I heard.
<sphalerite> __red__: iirc the nixos aarch64 community box was a dual thunderx before the current one came in
<sphalerite> gchristensen might know a thing or three about getting nixos booting on that.
<gchristensen> pretty easy
<gchristensen> but lately they don't boot b/c it doesn't see sda
<sphalerite> I remember it had lots of cores (96), but the cores weren't that powerful individually
<gchristensen> yeah pretty crummy cores
<gchristensen> but hey you get a lot of them
<sphalerite> saw https://www.ebay.com/itm/Dell-PowerEdge-2950-Gen2-Server-2x-Dual-Core-CPUs-Dual-Power-Perc5i-SAS-RAID/141163997257 in the related listings, had to click on it, was very disappointed when I saw "cat not included" right at the top
<gchristensen> clever, putting pics of cats in their auctions to stand out
julm has quit [Remote host closed the connection]
<sphalerite> yep, they know exactly what they're doing.
<sphalerite> well, it's not just a picture of a cat, it's a cat sitting on the actual item.
<gchristensen> I'm pretty sure the cat took the rest of the photos
julm has joined #nixos-aarch64
<sphalerite> We've all heard that the internet is for porn, but I think that's a lie. Its _real_ purpose is distributing pictures of cats.
<gchristensen> lol
<sphalerite> gchristensen: the cat using a camera, or using the cat as a camera?
<gchristensen> cats have good vision!
<sphalerite> aw man, now I feel like I need a powerful ARM board again.
<clever> sphalerite: the pi4(00) is fairly powerful
<gchristensen> want to play with a 96 core box?
<sphalerite> I have 2 RK3399 devices and a 3rd on the way though, so…
<samueldr> clever: hahaha
<sphalerite> gchristensen: dual thunderx?
<gchristensen> yea
<clever> but not 96 core powerful
<clever> samueldr: relative to previous pi models
<gchristensen> if you can get it seeing its disks, I'll let you play with it for a few days :)
<samueldr> sphalerite: my helios64 is in the hands of Canada Posts :)
<sphalerite> clever: eh, rk3399s are similar, no?
<clever> sphalerite: which arm core in that?
<samueldr> it's a BIG.little
<sphalerite> samueldr: oh wow, so you're getting yours quicker maybe!
<samueldr> 2 A72 and 4 A53
<sphalerite> samueldr: my last status update was "In transit-Shipment in transit at Dostyq Kazakhstan"
<clever> sphalerite: ah, like they mashed a pi3 and pi4 into the same core, for power-saving
<samueldr> now expected for the 16th of this month
<samueldr> clever: kind of, but older design :)
<clever> samueldr: so it can basically swap between pi3 and pi4 cores at runtime
<samueldr> what I think sphalerite meant with "powerful board" was something that's actually workstation worthy
<samueldr> I would assume, too, one where you could put a Radeon GPU
<samueldr> clever: not only swap, can use the 6 cores at once
<sphalerite> clever: not swap, really, rk3399 allows operating them all at the same itme.
<sphalerite> aaah samueldr ninja
<clever> ahh
<samueldr> if you're thinking about NVIDIA's, it's a bit complicated
<clever> but can 4 A53 beat 2 A72?
<gchristensen> sphalerite: I'll take that as a no =)
<clever> pi4(00) has 4 * A72
<samueldr> clever: wasn't it A76?
<clever> samueldr: not sure exactly, i know it had a 7
<samueldr> ah no, A72
<samueldr> weird, I thought it was A76
<sphalerite> gchristensen: it's a "sure, if I have the time one day" :p
<__red__> gchristensen: would you consider a 48 core thunderx box vs the more modern honeycomb?
<__red__> sorry for the delay - ended up in a work meeting
<sphalerite> gchristensen: wait, is this on packet.net or hardware access?
<gchristensen> packet
<__red__> supposedly, giving me money gives them the impression that they can tell me what to d :-P
<samueldr> __red__: if you want something that's _meant_ for workstation use, the honeycomb is probably better suited as it's currently having devs working on the rough edges
<sphalerite> gchristensen: ok, I think I still have my intro credit on packet.net so I could also try it myself :D
<sphalerite> but yeah, time…
<gchristensen> __red__: I'm just a monkey who can press buttons, for real opinions I'd ask the other people here
<samueldr> what I personally want is any kind of box where I can put a GPU to have proper acceleratoin
<samueldr> anything else and ugh, not worth it
<samueldr> I would also accept built-in acceleration that is actually usable
<samueldr> the pi 4's isn't on 64 bit NixOS
<samueldr> at least, not in a way that matters
<samueldr> videos are all hitchy, and some other regular desktop use isn't smooth
<sphalerite> hm, I wonder how panfrost is doing.
<__red__> when I'm out of this meeting, I may ask what the steps are to get nixos-aarch64 to run on a different target
<__red__> bbiab
<samueldr> sphalerite: last I checked ~3 months ago, with stock Nixpkgs + community kernel for the PBP, it was somewhat better
<samueldr> but not by much
<samueldr> so I guess right now it must be better
<__red__> (I'm currently running a yum-based distro on my arm cluster - I would like to change that)
<samueldr> __red__: unless you do netboots, like gchristensen, you're likely to go through two scenarios: (A) u-boot (B) UEFI
<sphalerite> __red__: what's your arm cluster composed of?
<__red__> odroid HC-2
<samueldr> armv7l
<gchristensen> <3 netboot
<samueldr> and even then, with netboot you're still going through (A) u-boot or (B) UEFI
<samueldr> but with extra steps
<gchristensen> yup
<__red__> I'll snag a blank CD card and a machine with a kernel to my desk in the next hour or so and see if I can get the thing to at least boot
<__red__> I'm guessing I can't get my amd64 hydra to cross-compile arm images right?
<__red__> images will need to come from the community aarch64 hydra?
<sphalerite> samueldr: hm, https://rosenzweig.io/blog/from-bifrost-to-panfrost.html suggests they've mostly been working on bifrost
<sphalerite> oh wait that's from april lol
<sphalerite> has it really been that long since I checked her blog? :o
FRidh has quit [Quit: Konversation terminated!]
<samueldr> __red__: somewhat yes for cross-compilation, with caveats
<samueldr> been a while I actually verified armv7l https://github.com/samueldr/cross-system
<__red__> thanks
<__red__> I'll take a peek
<samueldr> but a couple of the workarounds are in there
<sphalerite> 32-bit arm is a pain in general though.
<samueldr> it's a big YMMV imo
<samueldr> if you can cross-compile your everythings for armv7l, it should be fine enough
<__red__> getting to the image will be the interesting part
<__red__> bbiab
<samueldr> your exynos CPU has a bit of "draw the rest of the owl" to it
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<blackriversoftwa> Hi all, I've been reading the nixos-mobile site a bit wondering if I should take the time to run it on a secondary phone to play with it a bit. Can it actually boot into a GUI e.g. phosh or plasma-mobile yet? I saw xfce in the examples but none of the made-for-mobile Linux GUIs
<samueldr> we don't have a made-for-mobile GUI going yet, but that's because I've been building from the gound up
<samueldr> been making the boot flow first-in-class, then worked on abstractions
<samueldr> I don't know exactly when I'll start working on that, but I will at some point work on porting one of those mobile environments
<blackriversoftwa> samueldr: ok cool. Are there several contributors or are you mostly working on your own?
<samueldr> some people contributed device ports
<samueldr> I've had a few contributions here and there come in
<samueldr> but as far as regular contributions, if we don't count all of Nixpkgs/NixOS (which this builds on), then it's me
<samueldr> I'm curious as to the secondary phone you have to port to
<samueldr> if you tell me what it is, I can try to guesstimate whether it's trivial, easy or hard to port to
<blackriversoftwa> samueldr: right now I have a Pixel 2 as my primary phone but I'm going to be retiring it from that and then trying out mobile-nixos on it
<blackriversoftwa> it looks like it already has a port?
<samueldr> the non-xl variant does
<blackriversoftwa> `google-walleye`
<blackriversoftwa> I don't think mine is an XL
<blackriversoftwa> is the XL substantially different?
<samueldr> the xl variant is likely trivial, would need a kernel config tweak or two
<blackriversoftwa> makes sense
<samueldr> which are all known factors
<blackriversoftwa> ok well once I have my new phone up and running I'll try flashing an image
<blackriversoftwa> would you take a patch to thread a `pkgs` param through instead of relying on `NIX_PATH` all over?
<blackriversoftwa> that would make it easier to pin nixpkgs
<blackriversoftwa> it also wouldn't disrupt using NIX_PATH since it would just default to `pkgs = import <nixpkgs> {}`
<samueldr> yes, but only if it also is a good first step into making it work with flakes; I don't want the work to be undone :)
<blackriversoftwa> ah. I don't actually like flakes all that much but I could make sure it is compatible with that.
<blackriversoftwa> I like using `niv`for external deps
<samueldr> yeah, I think you get what I mean; so it won't be problematic with flakes use
<blackriversoftwa> right
<blackriversoftwa> I think stripping out all the `<nixpkgs>` references except for a default would be necessary to use flakes as well
<blackriversoftwa> so I think the work has to be done either way
<samueldr> you can ignore all of `lib/image-builder/*tests*` for <nixpkgs> uses, btw
<samueldr> those are not referenced inside of Mobile NixOS proper; the image builder is relatively stand-alone
<samueldr> so you're left with not that many at least :)
<samueldr> I think half of them are in comments!
<blackriversoftwa> Well I tried just overriding `pkgs` using the nixos `nixpkgs.pkgs` option and there were still things from my `NIX_PATH` coming in from somewhere, so there is something remaining to be done
<samueldr> yeah, there are some
<samueldr> but not that many to go through
<blackriversoftwa> actually that is probably what I would do, use that option to thread it through and just set it if there is a non-null `pkgs`argument to `default.nix`
<blackriversoftwa> ok that will be a good first PR then
alp has quit [Ping timeout: 272 seconds]
<samueldr> overlay/mruby-builder/default.nix # is a helper to call `nix-build` in that CWD, so it can be ignored too I think
<samueldr> (I broke the expression and things still built)
<samueldr> if something _had_ to be done, it would be dropping that file
<blackriversoftwa> samueldr: ok I'll try to make a PR shortly
zupo has joined #nixos-aarch64
* samueldr was reading his own code
<samueldr> so yeah, there's "a" Nixpkgs that's used in default.nix and release.nix for lib stuff, but are not used for any outputs
<samueldr> the release.nix one is probably harder to get rid of
<samueldr> the default.nix one might be easier
<samueldr> but those are not used for their outputs, so that's why I was diving into the implementation
<samueldr> lib/release-tools.nix # evalWith <- this is what ends up using the NixOS modules system, and I think this is what ends up using the default <nixpkgs> for nixpkgs.path
<colemickens> (I had a very difficult time trying to find my way through all this)
<samueldr> I had a very difficult time trying to implement my way through all this the first time around
<colemickens> I do have something that is usable from flakes though
<samueldr> I'm 99% sure the reason you get <nixpkgs> in the build output is the reason you would get <nixpkgs> in a NixOS rebuild
<samueldr> so the solution is likely the same
<samueldr> release.nix can be ignored, it's used for Hydra
<colemickens> I do have a commit that mentions flakes though, maybe I have a patch that's helpful? let me look
<samueldr> yeah, equivalent to what's documented in https://mobile.nixos.org/getting-started.html
<samueldr> >> (import <mobile-nixos/lib/configuration.nix> { device = "xxx-yyy"; })
<samueldr> (with less NIX_PATH use)
<samueldr> which ends up using the NixOS configuration's nixpkgs
<samueldr> which by default is <nixpkgs> IIRC
<colemickens> the disabledModules use <> syntax, that's my patch
<samueldr> right
<colemickens> that's it though, and an easy fix
<samueldr> though, I'm open into accepting `pkgs` as an arg to default.nix for easier use
<samueldr> I guess it would have to go through `evalWith` in some way and set `nixpkgs.pkgs`
* colemickens nods
<samueldr> oh, you already kind of can
<samueldr> with additionalConfigurations
<samueldr> additionalConfiguration*
<samueldr> ah, ignore that, additionalConfiguration should stay relatively internal
<samueldr> I think it would be through the evalWith use; it's possible without changing it
<samueldr> ugh, harder without a reference to pkgs to get mkMerge though
<samueldr> oh, but `modules = { lib, ... }: lib.mkMerge [ { imports = default_configuration; } { nixpkgs.pkgs = pkgsFromParamters; } ]; # maybe could work
<samueldr> ah, with a mkIf so it's only added when `pkgsFromParameters` is given
<samueldr> (and obviously better variable names)
<samueldr> (like simply pkgs)
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64