IRC channel logs
2024-11-19.log
back to list of logs
<fossy_>can't say i'm particularly familiar with nix/guix type systems, but if a package build changes - in any way - the whole dependency tree under it is rebuilt??? <fossy_>so if say, glibc is changed, you get a pretty much near world rebuild??? <jackdk>Yeah that's the point of the Nix attitude towards builds, and Guix-style grafts are one proposed solution to this problem <jackdk>That way you're never depending on accidental behaviour of a particular version <fossy_>i suppose so, but even just in the case of changing whether tests is run, you're going to have bit-for-bit identical output (hopefully) from that build -- why it couldn't at least skip over everything below it in the tree in that case? <unmush>it turns out that mechanically proving that a given change to source code results in bit-for-bit identical output is a bit challenging (that is to say, impossible in the general case) <unmush>oh, I see, you mean checking after the build <stikonas>of course it comes with it's own problems <stikonas>yeah, all the hashes are checked against the expected result of the build <stikonas>which is a bit of a pain during development <stikonas>as even a simple change means you need to re-run everything <unmush>yeah, if we used fixed-output derivations we could disable tests without rebuilds <stikonas>if we add other arches, that will become a bit unscalable... <jackdk>Yeah it's a challenge because the nix model (and presumably the guix model) are input-addressed, and changing the `doCheck = true;` flag (or guix equivalent) means that the derivation runs a different build script. content-addressed derviations where the output is hashed would help solve this AIUI <stikonas>yeah, but hash output is only possible in perfectly reproducible system <unmush>behold, mono commit 2729605554a10de4ebc74cc163409792885420af. This unassuming commit, somewhere between mono 5.2.0.224 and mono 5.4.0, described only as "bump corefx", marks when mono stopped being self-hosting. <unmush>they started out with microsoft's compiler and they ended up with microsoft's compiler. The circle is complete. <fossy_>hm, little confused, doesn't mono still require mono to build? <stikonas>is anybody still using mono on Linux though? <fossy_>don't you need mono as a runtime for compiled C# binaries on Linux? <stikonas>but are there any useful / popular apps in C#? <unmush>as far as I can tell commit 2729605554a10de4ebc74cc163409792885420af can't be built with any earlier mono, and therefore requires roslyn in order to be built <unmush>to be clear, by "mono" I here mean "the complete mono package, including runtime, class library, and compiler" <unmush>the mono runtime is still used within microsoft's official "dotnet" package <unmush>so I'm not sure what to try next, patching to try to get past this hurdle or trying to package microsoft's dotnet starting from mono 5.2.0.224 <lanodan>there's also dotnet-sdk from microsoft instead of mono but it's much more recent (so unlikely for pnet to work) and as far as I can tell doesn't bootstraps <lanodan>err, should have backlogged entirely, yeah maybe mono 5.2.0.224 -> dotnet-sdk could be an interesting way <unmush>it's proving quite difficult because it seems like the first thing every single msbuild-based build system tries doing is downloading a bunch of binary blobs <unmush>doesn't even try checking whether the environment already provides what they want <unmush>roslyn requires some immutable collections thingy that mono doesn't have, so I'm going to need to go mono --> corefx --> roslyn <unmush>as far as I can tell (it's hard to be sure because the build systems seem to have such strong anti-packaging properties), pretty much all dotnet things depend on msbuild, including roslyn, and msbuild depends on roslyn, and msbuild depends on msbuild, and roslyn depends on corefx (which in 2020 was combined with a bunch of other stuff into dotnet-runtime).