<copumpkin>
pierron: :( maybe just needed more spreading understanding? it wasn't obvious how it worked IIRC and people might not have welcomed it simply because they didn't understand it
<pierron>
copumpkin: possibly
<copumpkin>
I'd be sad if your mechanism didn't end up making it in, at least :)
<pierron>
copumpkin: maybe we should discus this topic at the next NixCon
<pierron>
but I am not going to present it again.
<copumpkin>
yup!
<pierron>
copumpkin: the problem is that it sounds complex, and people do not see the logic behind it on the first sight
<copumpkin>
maybe we can think of other ways to get people on board after nixcon
<copumpkin>
or ways to simplify it for people
<pierron>
copumpkin: while this might sound complex this is at the same time making tons of assumption about Nixpkgs which are necessary to make this problem manageable.
<pierron>
copumpkin: the problem is that making Nixpkgs fit to this manageable state is not trivial without a community effort, and we cannot get a community effort without convincing.
<pierron>
copumpkin: basically the problem today is more pollitical than technical.
<copumpkin>
I see
<pierron>
S.O.S. is one way to simplify the problem, by solving other issues at the same time, but again this is a lot of pollitical efforts.
<pierron>
copumpkin: Today I have other technical spare time project to keep me occupied, and hopefully one for which I would make a public annoucment soonish.
<pierron>
copumpkin: nothing related to Nix.
<copumpkin>
how could it be unrelated to nix!??!?
<copumpkin>
such a thing is inconceivable to me
<pierron>
copumpkin: This is a new JIT compiler ;)
<copumpkin>
nice!
<copumpkin>
for nix ;)
<pierron>
copumpkin: no, but it could later be.
<copumpkin>
cool :)
<pierron>
copumpkin: if we were to rewrite the Nix interpreter in Rust.
<copumpkin>
I'm sure quite a few folks wouldn't mind seeing that happen
<pierron>
I am sure the investment of rewriting the Nix interpreter in Rust to add this JIT would be cheaper than adding a JIT to the C++ implementation.
<gchristensen>
pierron++ !m pierron
<copumpkin>
:)
<copumpkin>
niksnut: any reason you don't use modulesPath in your maintainers (image generating) amazon-image.nix, instead going for the relative nix path?
<niksnut>
I would turn that around, what would be the reason for using modulesPath?
<copumpkin>
would be nice to have a convention that if you're talking about a module, you use modulesPath. I'm getting some duplicate imports from another module importing the same amazon-image.nix module because it only has access to modulesPath
<niksnut>
I think it's better to use relative paths
<copumpkin>
I just don't know how to avoid duplicate imports with relative paths
<copumpkin>
I want to evaluate the same config when building the image and later once the image is loaded
<copumpkin>
and have it produce the same outcome
<niksnut>
why would you get a duplicate import?
<copumpkin>
because when I evaluate maintainers/amazon-image.nix, I automatically get modules/amazon-image.nix based on its imports, and then I include my own config as well. That config needs to import modules/amazon-image.nix on its own too because I need to be able to evaluate it once the image is booted too. I can't in general ensure that pkgs.path is the same as the maintainers/amazon-image.nix so during image evaluation the paths might
<copumpkin>
differ. If I use modulesPath they'll definitely differ
<copumpkin>
basically it's just an awkward dance to get the same config to evaluate cleanly during image building and after the image is built
<niksnut>
amazon-image.nix is *only* intended for building an image
<copumpkin>
sorry I'm not making a very clear case for it
<copumpkin>
the two files having the same name isn't helping my clarity :P
<copumpkin>
I know
<copumpkin>
I'm saying that the way I build a semi-preconfigured image is `evalModules { modules = [ maintainers/amazon-image.nix myconfig.nix ]; }`
<copumpkin>
myconfig.nix gets dropped into the box
<copumpkin>
and I still want to be able to evaluate it on the box
<copumpkin>
so myconfig.nix has `imports = [ "${modulesPath}/amazon-image.nix" ];`
<copumpkin>
which without some really awkward jumping through hoops will cause duplicate definitions for modules/amazon-image.nix
<copumpkin>
so basically this arises when you want to evaluate the same config when building the image and inside the booted image
<gchristensen>
that sounds like an awesome follow-up to nixcon, I hope people go
<gchristensen>
my wife would kill me if I took that time away from our vacation though :)
<fpletz>
nice, our berlin office is right next door… :)
<copumpkin>
is there a way to ask systemd to send a specific service's logs to /dev/console as well as the journal?
<copumpkin>
thinking about amazon-init
<copumpkin>
would make bootup issues much more pleasant to diagnose
<niksnut>
gchristensen: vacation in europe?
<niksnut>
I won't be able to go, but it would be great if we had some NixOS representation
<gchristensen>
niksnut: yeah, Emily and I will be flying back home out of Munich on november 9 IIRC
<niksnut>
cool
jtojnar has quit [(Read error: Connection reset by peer)]
<copumpkin>
TIL that nix accepts spaces around the attrset indexing dot
<copumpkin>
so `with pkgs . lib`
<copumpkin>
is equivalent to `with pkgs.lib`
<copumpkin>
!
jtojnar has joined joined #nixos-dev
zraexy has quit [(Quit: Leaving.)]
zraexy has joined joined #nixos-dev
jushur has joined joined #nixos-dev
MichaelRaskin has joined joined #nixos-dev
<copumpkin>
niksnut: any chance you can take a look at the retry PR sometime soon? it's causing me a fair amount of pain, and although I can add an ad-hoc patch, I'd rather not deviate too far from upstream
<copumpkin>
if it's the right general direction but you want more changes/time to think about it, that's fine
goibhniu has quit [(Ping timeout: 258 seconds)]
MoreTea has joined joined #nixos-dev
taktoa has quit [(Remote host closed the connection)]
taktoa has joined joined #nixos-dev
<gchristensen>
is it possible to only list the interpreter from `ldd` of a binary?
Sonarpulse has quit [(Ping timeout: 246 seconds)]
<gchristensen>
ie: I want to know if the executable is pointing at `/nix/store/7crrmih8c52r8fbnqb933dxrsp44md93-glibc-2.25/lib/ld-linux-x86-64.so.2` or something-like-/lib64/ld-linux-x86-64.so.2
<gchristensen>
ah ha, of course, $ patchelf --print-interpreter
Sonarpulse has joined joined #nixos-dev
<LnL>
does anybody know why postgres has hydraPlatforms = linux