worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS stable: 20.03 ✨ | | | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm |
<clever> = note: /nix/store/h4bkk5lqfh80xsp64c1wsfag5p5qiigv-x86_64-w64-mingw32-binutils-2.31.1/bin/x86_64-w64-mingw32-ld: cannot find -lpthread
<clever> Ericson2314: libpthreadstubs doesnt provide the lib
<clever> nix-repl> pkgs.pkgsCross.mingwW64.threadsCross
<clever> «derivation /nix/store/d5nw4i04ivvcf337z683qrmvpnynldpy-mcfgthreads-git-x86_64-w64-mingw32.drv»
<clever> looks like a good one
evanjs has quit [Ping timeout: 272 seconds]
evanjs has joined #nixos-dev
bhipple has joined #nixos-dev
bhipple has quit [Ping timeout: 260 seconds]
bhipple has joined #nixos-dev
<Ericson2314> clever: yeah if it uses mfgthreads I am not sure it does pthreads
bhipple has quit [Ping timeout: 246 seconds]
bhipple has joined #nixos-dev
<clever> = note: /nix/store/h4bkk5lqfh80xsp64c1wsfag5p5qiigv-x86_64-w64-mingw32-binutils-2.31.1/bin/x86_64-w64-mingw32-ld: cannot find -lpthread
<clever> Ericson2314: still failed
<Ericson2314> clever: do you have a version of nixpkgs that lets one use pthreads for gcc?
<Ericson2314> not to distract but that is probably a good PR in its own right
<clever> Ericson2314: nixpkgs master
<clever> Ericson2314: and i already had to patch rust to fix target issues
<clever> nix calls it w64, but rust calls it pc
<Ericson2314> clever: if nixpkgs master isn't it still using mfcthreads?
_e has joined #nixos-dev
<clever> Ericson2314: maybe rust is to blame for trying to keep using pthreads?
bhipple_ has joined #nixos-dev
<Ericson2314> clever: I recall pthreads was working, in some fashion, the problem was no c++ threads
<Ericson2314> was the thing that threadsCross used to be not pthreads?
<Ericson2314> maybe it was just mingw headers?
<clever> i'm also confused as to why works, but naersk fails
asbachb has quit [Ping timeout: 245 seconds]
<Ericson2314> clever: naersk?
<clever> Ericson2314: origin (fetch)
<Ericson2314> oh mm
<Ericson2314> I'm sort of waiting for to make rust packaging a lot easier
<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
<yorick> (it uses the non-cross-compiled version)
<pie_> flokli: you do a lot of the systemd maintenance right? - well even for a little; has this been solved yet? just checking
<{^_^}> #73800 (by deliciouslytyped, 24 weeks ago, open): Migrate to cgroupsv2
<pie_> i mean can it be closed
<pie_> ah, this looke recent, so i guess not
<srk> "we have to wait" for all container runtimes to migrate sounds weird :)
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
nschoe has quit [Ping timeout: 244 seconds]
<flokli> so this reads to me that once #77925 is solved, we can in theory flip defaults
<{^_^}> (by arianvp, 15 weeks ago, open): Installing any libcontainer related software (runc, podman, cri-o) bricks nixos-container
<pie_> sure, i was mostly just wondering if anything changed since i made the issue a while ago
<flokli> I'd assume the cgroup version we're booting with will then depend on the container runtime that is being used
<flokli> it isn't "done", and there might be multiple stages in how it's done
<flokli> but you can help getting there ;-)
<pie_> (as always :p)
<flokli> heh
<pie_> for the moment i happen to be satisfied with disabing v2 because i dont use the v1 dependent container techs
<pie_> back when i was figuring it out, it was pretty hard to figure out what the problem was though 'xD
alp has joined #nixos-dev
<pie_> I just remembered I have a wrapper script that starts firefox in a ram limited scope - really needed that..
nschoe has joined #nixos-dev
phreedom has joined #nixos-dev
freethink has left #nixos-dev [#nixos-dev]
nschoe has quit [Ping timeout: 260 seconds]
<adisbladis> pie_: I'm actively working towards getting v1 disabled by default
<adisbladis> The big blocker there is indeed
<{^_^}> #77925 (by arianvp, 15 weeks ago, open): Installing any libcontainer related software (runc, podman, cri-o) bricks nixos-container
alp has quit [Ping timeout: 265 seconds]
<adisbladis> God I am annoyed at the libpod/skopeo/whatever runtimes picked /etc/containers as their path -.-
<adisbladis> Such hubris
<adisbladis> Anyone with a good idea how #77925 can be solved ?
<{^_^}> (by arianvp, 15 weeks ago, open): Installing any libcontainer related software (runc, podman, cri-o) bricks nixos-container
alp has joined #nixos-dev
<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"
ris has joined #nixos-dev
Bunogi has quit [Quit: The Lounge -]
Bunogi has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
<adisbladis> pie_: I think either number 1 or number 2 are the only reasonable solutions
<adisbladis> Number 2 feels brittle though
kcalvinalvin has quit [Ping timeout: 256 seconds]
kcalvinalvin has joined #nixos-dev
<ris> should see a doctor about that
<infinisil> Lol
<adisbladis> Hahah :D
<alexarice[m]> What is stopping nixos-unstable from updating, it seems like it has had successful builds recently but has not progressed?
WilliButz has quit [Quit: bye]
WilliButz has joined #nixos-dev
<LnL> did it get stuck again?
alp has quit [Ping timeout: 244 seconds]
<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-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 ( ._.)
cole-h has joined #nixos-dev
<{^_^}> #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.
<{^_^}> openzfs/zfs#8853 (by ahrens, 48 weeks ago, open): [WIP] raidz expansion, alpha preview 1
<emily> tbf, you can grow, you just need to do it by basically doubling your capacity
<emily> just pretend you're a hashtable
justanotheruser has quit [Ping timeout: 252 seconds]
<gchristensen> what if the nixpkgs-maintainers team by default got triage on *every* NixOS repo?
<julm> emily: ok, thanks
<gchristensen> cc domenkozar[m] ^
<domenkozar[m]> aren't there some private ones?
<gchristensen> just by default, so I don't think that would extend to private repos
<cole-h> I don't dislike the idea, but if somebody malicious does somehow make it into maintainership, that would expand their ability to wreak havoc
<gchristensen> would want to double-check that
justanotheruser has joined #nixos-dev
<gchristensen> nixos-unstable is not updating because of this: error: in package ‘php’: this derivation has bad 'meta.outputsToInstall'
<clever> gchristensen: how familiar are you with the rust cross-compile logic?
<gchristensen> I'm not familiar with rust's regular build logic, and I'm even less familiar with cross compilation in general -- sorry
<clever> kk
<julm> adisbladis: an article about ZFS expansion I've just read:
nschoe has joined #nixos-dev
<arianvp> adisbladis: so my idea about this is
<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!
<gchristensen> s/think/thing/
<hexa-> lovely
<flokli> gchristensen: a lot of stuff to do
<flokli> :-D
<gchristensen> :)
orivej has joined #nixos-dev
<adisbladis> What's up with the unstable channel not progressing?
<adisbladis> We have successful builds 2 days ago and earlier today
<cole-h> 08:37 <gchristensen> nixos-unstable is not updating because of this: error: in package ‘php’: this derivation has bad 'meta.outputsToInstall'
<cole-h> Maybe same issue?
<adisbladis> Looks alright to me...
<adisbladis> > php.meta.outputsToInstall
<{^_^}> [ "out" "dev" ]
<adisbladis> gchristensen: Where is this coming from?
<gchristensen> the logs from the hydra-chanel-scripts mirror channel program
<worldofpeace> hexa-: that just sounds like a mistake?
<worldofpeace> oops, you said nvm
<worldofpeace> k'bye nixos-dev
cransom has quit [Ping timeout: 260 seconds]
<hexa-> worldofpeace: i cp'ed one patch over the other … so :D
cransom has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
cransom has quit [Ping timeout: 256 seconds]
nick-korsakov has joined #nixos-dev
nick-korsakov has quit [Remote host closed the connection]
cransom has joined #nixos-dev
nschoe_ has quit [Ping timeout: 272 seconds]
nschoe has joined #nixos-dev
__monty__ has quit [Quit: Too slow, zaeph : /]
nschoe has quit [Ping timeout: 252 seconds]
<pie_> adisbladis: i kind of forgot to think about: maybe podman and stuff let you just configure what containers directory to use?
<pie_> adisbladis: stuff like idk
<{^_^}> containers/libpod#2395 (by jpork, 1 year ago, closed): Change the graphroot in storage.conf doesn't effect volume creation
justanotheruser has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-dev
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-dev