<rajivr>
Is there something special about `nixpkgs` flake or flakes in general, that turns a `set` into a `lambda` upon import? `builtins.typeOf (builtins.getFlake "nixpkgs")` is a `set`, while `builtins.typeOf (import (builtins.getFlake "nixpkgs"))` is a `lambda`. I've been using this pattern, without actually realizing what was going on under the hood.
Cale has joined #nixos-dev
sgo is now known as stigo
cole-h has quit [Ping timeout: 246 seconds]
kalbasit has quit [Ping timeout: 256 seconds]
thibm has joined #nixos-dev
<jtojnar>
rajivr: it works because you are importing an attrset with outPath attribute
<jtojnar>
IIRC
saschagrunert has joined #nixos-dev
teto has joined #nixos-dev
danderson has quit [Ping timeout: 240 seconds]
danderson has joined #nixos-dev
kini has quit [Read error: Connection reset by peer]
<rajivr>
Another question that comes to my mind is, does `import` attempt to coerce a `set` into a `string`, or is something else happening under the hood?
<regnat>
rajivr: yes, import needs its input to be a string, and tries to coerce it if it isn't
<rajivr>
Thanks jtojnar and regnat. :-)
AlwaysLivid has joined #nixos-dev
orivej has joined #nixos-dev
__monty__ has joined #nixos-dev
m1cr0man has joined #nixos-dev
m1cr0man has quit [Ping timeout: 240 seconds]
m1cr0man has joined #nixos-dev
AlwaysLivid has quit [Quit: We are a collection of 7 billion codependent atoms. Stop hating based on constructs and come along for the ride.]
pmy has quit [Quit: WeeChat 3.0]
kgz has quit [Ping timeout: 264 seconds]
kgz has joined #nixos-dev
<roberth>
who might be able to help with installer test failures in the nixos tests? These tests have maintainers = []
Baughn has quit [Ping timeout: 240 seconds]
Baughn has joined #nixos-dev
tilpner has quit [Quit: tilpner]
<infinisil>
Idea: We should have a way to mark channel revisions as broken immediately, such that we don't have to wait for the next channel update to prevent people from using it
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Client Quit]
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
tilpner has joined #nixos-dev
ckauhaus has joined #nixos-dev
<siraben>
Am I using the emulator feature correctly? http://ix.io/2H1r
<siraben>
Looks like it's not documented, I could only reason about it via the tests in `pkgs/test/cross/default.nix`
<samueldr>
2GB zfs filesystem (dataset?) into a 10GB partition
<gchristensen>
ah
<gchristensen>
zpool vdevs can indeed be expanded on startup
<samueldr>
anyway, we need to grow most filesystems, at least the sd image needs to grow because it is setup to be as small as possible, if it isn't there's not enough space to finish booting
ehmry has joined #nixos-dev
<gchristensen>
but adding support to make-disk-image for ZFS involves a bit of an expansion of the interface -- adding new parameters to support dataset options, for example. I'm trying to ask if that would be too "big" for that file, or if a new make-zfs-image would be better
<samueldr>
I think you're putting your finger right on it: I don't know if it's a proper interface to expand from
<samueldr>
(I really don't know)
<samueldr>
I'm not even sure it's the one used for SD images
<samueldr>
isn't there like 2 or 3 different image builders in Nixpkgs?
<gchristensen>
good question, it isn't! that is in modules/installer/cd-dvd/sd-image.nix
<gchristensen>
there are also make-ext4-fs.nix, make-iso9660-image.nix, make-squashfs.nix
<samueldr>
well, sd-image uses make-ext4-fs
<gchristensen>
ah yes
<samueldr>
so, right, already that's not the one I'm familiar with
<samueldr>
what needs to be done (and IIRC at least three authors tried to take on the idea) is to make something common with the right abstractions
<samueldr>
but yeah :/ development time is scarce
<gchristensen>
*or* not try to abstract it
<samueldr>
well, that's what you might want to do
<samueldr>
I'm a fourth author that did make an attempt too, and it's being exercised often through Mobile NixOS
<samueldr>
building filesystem images and full disk images
<samueldr>
MBR and GPT
<gchristensen>
yea
<samueldr>
what I'm getting at is maybe for now do the usual Nixpkgs things of keeping the status quo, if you aren't confident in the changes
<gchristensen>
so if I were to walk down this road I'd say whatever, mbr is so yesteryear, and not support both -- focusing on the complexities of the zfs bits
<samueldr>
we need MBR, sadly
<samueldr>
if we want to stay compatible with amlogic SBCs
<gchristensen>
we=mobile nixos, not we=users of the make-zfs-image.nix? is mobile nixos inclined to get fancy?
<samueldr>
so we need the interface to have a clear separation between filesystems and disk images in my opinion
<samueldr>
we=nixos-on-arm
<gchristensen>
yea.
<samueldr>
I thought "waslk down this road" meant work on the generic solution :)
<samueldr>
walk*
<gchristensen>
ahh :)
<samueldr>
but if you're making a generic~ish zfs-only opinonated builder, GPT only is probably fine
<samueldr>
opinionated*
<gchristensen>
a shame you can't mkzfsdataset without a zpool and kernel module
<samueldr>
and yeah, we totally need to keep the interface between partition content [filesystems], and partition scheme [disk images] totally distinct
<samueldr>
if we want to have a really generic solution
<samueldr>
as for Mobile NixOS, it needs to build filesystems without a disk image
<samueldr>
I really think we need a generic image builder, but we need the right interface, otherwise we're back at step one...
<samueldr>
which basically is why I'm trying to dogfood mine quite heavily
<samueldr>
as for using ZFS on mobile, I'm sure many users want to
<gchristensen>
this has turned in to a tall order :P
<samueldr>
yeah, don't feel like you should handle that
<samueldr>
but I also think the make-disk-image is maybe too organically grown to really be the place to add the weight of the additional options zfs requires
<gchristensen>
+1
<samueldr>
as for my planning, it's lacking one main feature
<gchristensen>
a make-disk-image which is comprised of a list of make-«patition»s would be nice
<samueldr>
I want to be able to either build it as one "mega-derivation", or discrete derivations per-filesystem
<samueldr>
yeah, that's basically what I did
<samueldr>
the "mega-derivation" is to help in situations, like on hydra, where it doesn't make sense to build a 3GiB image, to then pick it back up and shove it into a disk image
<samueldr>
though I didn't go further into checking it's defined or not
supersandro2000 has joined #nixos-dev
<samueldr>
though, my actual opinion about that is if you're dealing with numbers... go with something that is nicer to deal with
tokudan has quit [*.net *.split]
roberth has quit [*.net *.split]
aterius has quit [*.net *.split]
siraben has quit [*.net *.split]
jonge[m] has quit [*.net *.split]
matthewkenigsber has quit [*.net *.split]
kraem has quit [*.net *.split]
ky0ko1 has quit [*.net *.split]
ashkitten has quit [*.net *.split]
raboof has quit [*.net *.split]
hexa- has quit [*.net *.split]
Taneb has quit [*.net *.split]
sdier has quit [*.net *.split]
teehemkay has quit [*.net *.split]
Raito_Bezarius has quit [*.net *.split]
andi- has joined #nixos-dev
Taneb has joined #nixos-dev
teehemkay has joined #nixos-dev
sdier has joined #nixos-dev
tokudan has joined #nixos-dev
ashkitten has joined #nixos-dev
Raito_Bezarius has joined #nixos-dev
raboof has joined #nixos-dev
jonge[m] has joined #nixos-dev
ky0ko1 has joined #nixos-dev
siraben has joined #nixos-dev
<ryantm>
gchristensen: While it is nice to be optimistic that OfBorg Darwin will start working, I fear the constant yellow entry for it is slowly training us all to merge things that are yellow.
hexa- has joined #nixos-dev
aterius has joined #nixos-dev
roberth has joined #nixos-dev
kraem has joined #nixos-dev
matthewkenigsber has joined #nixos-dev
<gchristensen>
I agree with that, ryantm
<gchristensen>
it is possible we'll be getting a mac in the next 12h
<abathur>
gchristensen: on the declarative files topic (but more abstractly), I wonder about something like: dataDir must something like a BagofHolding, and a BagOfHolding must be something that can be mounted at that path
<gchristensen>
yes!
<abathur>
so the expression might be able to deal with that definition declaratively
<{^_^}>
undefined variable 'spook' at (string):440:1
<infinisil>
> spook = "👻"
<{^_^}>
spook defined
<supersandro2000>
> spook
<{^_^}>
"👻"
red[evilred] has joined #nixos-dev
<red[evilred]>
I guess in theory someone could adopt a PR
<red[evilred]>
But tend have to submit it again?
<samueldr>
there's no reason not to merge it
<samueldr>
especially considering there are other packages maintained by that now-ghost user
<samueldr>
maybe if that now-ghost was a new user to Nixpkgs then it'd need to be balanced out
<samueldr>
though obviously, only if it was ready to be merged
<red[evilred]>
Makes sense
<red[evilred]>
Speaking of, is there a package adoption agency?
<red[evilred]>
So for packages that are maintainerless
<red[evilred]>
Volunteers could be found to adopt potentially
<samueldr>
not really, that doesn't make sense when you could just go and add yourself to be maintainer of a package you want to
<samueldr>
and additionally considering that it's not because there's a maintainer listed that it's actively being maintained by them
<abathur>
gchristensen: I guess this stretches the metaphors, but it might be interesting if BagOfHolding could have an option dictating whether it should be GCed if there are no more references to it
<abathur>
which could be true for some ~app that uses a PG server as a quirky implementation detail, but false for someone using PG as a server component
<red[evilred]>
Well, even packages that I work on i feel weird adding myself as a maintainer unless specifically invited
<red[evilred]>
Whereas adopting orphans i wouldn't be concerned about
<samueldr>
don't feel weird if you've been involving yourself on things, you _are_ maintaining
<samueldr>
orphans? would you really care about an obscure package that you are not using?
<samueldr>
it's not about filling in empty fields, it's about care :)
<red[evilred]>
NixOS has been a real boon to my viewpoint and career, I want to support a I can
<samueldr>
then actually maintain what you care about first
<red[evilred]>
And if that means maintaining a few things nobody else does. I'm happy to
<samueldr>
I don't want to see you in the maintainer field of things just to fill them up, first start with what you're actively maintaining :)
<red[evilred]>
I should jump into that erlang discussion first i guess
<ryantm>
supersandro2000: I think we should close that PR since the author won't respond to comments and the package being added effectively has no maintainer.