<Ericson2314>
buildRustPackage worked fine for me cross
<Ericson2314>
but didn't try something hard like windows
Scriptkiddi has quit [Quit: killed]
ajs124 has quit [Quit: killed]
das_j has quit [Quit: killed]
Scriptkiddi has joined #nixos-dev
ajs124 has joined #nixos-dev
das_j has joined #nixos-dev
ris has quit [Ping timeout: 246 seconds]
<clever>
,profiling angerman
<{^_^}>
angerman: Use NIX_COUNT_CALLS=1 and/or NIX_SHOW_STATS=1 to profile Nix evaluation
evanjs has quit [Ping timeout: 264 seconds]
drakonis has quit [Quit: WeeChat 2.8]
drakonis has joined #nixos-dev
drakonis has quit [Client Quit]
justanotheruser has quit [Ping timeout: 244 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Client Quit]
justanotheruser has joined #nixos-dev
<pie_>
I dont really understand why cross compilation is even hard
<pie_>
which is obviously my lack of knowledge
<pie_>
but it sounds like it would be /more/ difficult to make a compiler only compile for its own architecture
<samueldr>
it's more about assumptions from everything in the stack that it only executes and builds on the same environment AFAIUI
<samueldr>
so genreally there will be less care taken to compartimentalise what is needed during build rather than during runtime
<samueldr>
and there's also some hardships that come from nix, and the way we don't just stuff things willy nilly in /usr/, so if we have to give a foobar package for build-time dependency and a foobar package for run-time dependency it can get messy compared to how just using whatever is in the ambient environment is
<pie_>
samueldr: yeah thats kind of what i guessed
<pie_>
thanks
<samueldr>
and then there's things like canadian cross
<pie_>
i.e. almost everyone uses a given environment so things just crust up around that and oh oops look now cross compilation doesnt work
<samueldr>
or it never did since they didn't care exactly how the compiler was used, so they used the same compiler for compiling build-time deps and run-time deps
<samueldr>
e.g. if your program needs to compile a C program to generate some code to then compile it for runtime
<samueldr>
you need two distinct compilers!
<samueldr>
(what I just described is not even canadian cross)
<samueldr>
>> The term Canadian Cross came about because at the time that these issues were under discussion, Canada had three national political parties.[1]
<pie_>
0_o @ canadian cross
<samueldr>
(off-topic a bit) I'm confused by "had"
bhipple has quit [Remote host closed the connection]
bhipple_ has quit [Remote host closed the connection]
alp has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
alp has quit [Ping timeout: 256 seconds]
alp has joined #nixos-dev
<pie_>
adisbladis: well, -stable seems to be dead in the bikeshed or something idk
nschoe has joined #nixos-dev
alp has quit [Ping timeout: 244 seconds]
bachp has joined #nixos-dev
tilpner has joined #nixos-dev
<yorick>
cross compiled python has a lot of fun with 2to3
<yorick>
I think it's just patchInterpreter'd wrong
<pie_>
various guesses at obvious solutions?: 1) breaking change on nixos-container 2) make nixos container realize whats going on and not fail 3) patch other utilities to have their own directories 4) patch other utilities to transparently have their own directories
<pie_>
5) something something namespaces?
<pie_>
the general problem being "how do you handle conflicting system utilities"
<gchristensen>
I have a question about tmpfiles.d: for `F` the manpage says: "Create or truncate a file. If the argument parameter is given, it will be written to the file." is "-" considered "given", or is that considered null? can I simply not specify that last column?
alp has joined #nixos-dev
<adisbladis>
pie_: I think this is an excellent case for stateVersion
<hexa->
gchristensen: imo - is a way to omit a value when you still want to use a later one
<hexa->
I'd think it's null
<gchristensen>
hexa-: I wish systemd-clean printed some more logs, hah
<gchristensen>
I get the impression systemd-tmpfiles.d isn't very ...good... at deleting files quickly
<hexa->
gchristensen: a snippet that I've alwasy got handy is systemd.services."systemd-networkd".environment.SYSTEMD_LOG_LEVEL = "debug";
<hexa->
maybe that can be applied to systemd-tmpfiles as well
<gchristensen>
cool, yeah
<gchristensen>
oh what it uses atime
<adisbladis>
Omg mdadm...
* adisbladis
wishes he went with zfs for this system instead :/
<adisbladis>
I have a raid5 array I cannot add another disk to
<gchristensen>
oof
<adisbladis>
It's always showing up as a spare :S
<adisbladis>
With no way to make it active
evanjs has joined #nixos-dev
<emily>
zfs isn't great at adding disks either :(
<adisbladis>
emily: At least with zfs I've never had an error this mystical happen
<gchristensen>
"49.5 wa" this is the right amount of io wait, right ( ._.)
<{^_^}>
#87268 (by adisbladis, 1 minute ago, open): nixos-container: Use new configuration & state directories
<emily>
adisbladis: stateDirectory could use configurationEtc (which should then probably be renamed?)
<emily>
adisbladis: startScript also probably needs adjusting
<emily>
oh, I guess that's /run so it's fine
<adisbladis>
Please direct any comments to the PR :)
drakonis has joined #nixos-dev
<julm>
adisbladis: I concur with emily, AFAIK ZFS' raidz are not growable without copying everything elsewhere, there is a work-in-progress PR to avoid that but it's still alpha. If adding disks is a concern, you may be better off with mdadm or btrfs. https://github.com/openzfs/zfs/pull/8853
<arianvp>
we should really only put things in /etc when they're cross-cutting (e.g. multiple pieces of software read the same config)
<arianvp>
if we can patch podman or whatever to read from a path in nix store instead; that's always preferred
<arianvp>
if those libcontainer configs are really cross-cutting; we should maybe just pick a different directory for libcontainer /etc/container2
<arianvp>
I think I prefer that over making breaking change to nixos-container
<gchristensen>
podman is super in to this global mutable state stuff, and also taking very generic names as if it is a race to land-grab as many generic nouns
<adisbladis>
"if we can patch podman or whatever to read from a path in nix store instead; that's always preferred" - agreed, but I don't think it's possible
<adisbladis>
This is hard-coded behaviour in many different libraries across that ecosystem
<adisbladis>
It's going to be a losing battle
<adisbladis>
Those libraries not being "regular" dynamic libraries but Go libraries makes changing this a lot harder
nschoe has quit [Ping timeout: 246 seconds]
<gchristensen>
any chance we can help influence the development ofthe project to be better in this way?
nschoe has joined #nixos-dev
<adisbladis>
Umm.. Maybe?
nschoe_ has joined #nixos-dev
<adisbladis>
I don't even have a firm graps of what projects are using /etc/containers & for what
nschoe has quit [Ping timeout: 260 seconds]
<adisbladis>
My gut says that sticking to /etc/containers for NixOS containers is not gonna work long-term
__monty__ has joined #nixos-dev
<flokli>
I'm also with adisbladis that /etc/nixos-containers seems to be better.
<flokli>
I'm just worried about state migrations
<flokli>
making this conditional on stateVersion is only gonna solve it for new installations. We still won't be able to use podman on older installations.
<gchristensen>
I'm with ya
<flokli>
I'd personally prefer having some migration code (if we can distinguish nixos-container state files) that we ship for 1-2 stable releases
<flokli>
I'll dump my thoughts in the PR, where this belongs
<flokli>
sorry for writing it down here
dongcarl has quit [Read error: Connection reset by peer]
<emily>
flokli: the PR solves podman on older installations by ignoring the config files in /etc/containers, doesn't it?
<emily>
maybe that's not a 100% solution but there's at least the potential for a workaround
<emily>
(it's super ugly to keep a clash like that around though admittedly, but given that people will have existing data from both systems in /etc/containers it's hard to see what other option there is)
<flokli>
emily: let's move the discussion to the PR ;-)
<hexa->
worldofpeace: can you enlighten me, why there are two patches applied against network manager, that are equal?
<hexa->
fix-paths.patch and fix-install-paths.patch
<hexa->
or jtojnar ^
<hexa->
nvm, i'm an idiot
<gchristensen>
hexa-: that SYSTEMD_LOG_LEVEL bit turned out to be helpful in debugging some completely unrelated thing, and I hadn't even considered it might be a think. thanks!