| 20 Apr 2025 |
 Tristan Ross | pkgs/top-level/all-packages.nix: hello-x86_64 = if stdenv.hostPlatform.isx86_64 then hello else pkgsCross.gnu64.hello;
pkgs/top-level/all-packages.nix: hello-x86_32 = if stdenv.hostPlatform.isx86_32 then hello else pkgsCross.gnu32.hello;
pkgs/top-level/all-packages.nix: pkgsCross.gnu32.callPackage ../applications/emulators/box86 args
pkgs/top-level/all-packages.nix: pkgsCross.armv7l-hf-multiplatform.callPackage ../applications/emulators/box86 args
pkgs/top-level/all-packages.nix: # pkgsCross.aarch64-multiplatform.freshBootstrapTools.build
pkgs/top-level/all-packages.nix: gccCross = pkgsCross.ben-nanonote.buildPackages.gccWithoutTargetLibc;
pkgs/top-level/all-packages.nix: avrgcc = pkgsCross.avr.buildPackages.gcc;
pkgs/top-level/all-packages.nix: avrlibc = pkgsCross.avr.libcCross;
pkgs/top-level/all-packages.nix: gcc-arm-embedded = pkgsCross.arm-embedded.buildPackages.gcc;
pkgs/top-level/all-packages.nix: binutils-arm-embedded = pkgsCross.arm-embedded.buildPackages.binutils;
What...
| 16:34:48 |
| Tristan Ross | Yeah, I think that's good. We can do something like this:
- Merge the optional overlay PR
- Go through and make a tree-wide PR for each nixpkgs variant to move things over the best we can (we'll probably have like 4 PR's lol)
- Disable
allowVariants in CI
| 16:39:15 |
| Tristan Ross | pkgsStatic definitely looks easy | 16:39:25 |
| Tristan Ross | Oh good, nobody consumes pkgsLLVM in nixpkgs | 16:39:43 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @rosscomputerguy:matrix.org
Oh good, nobody consumes pkgsLLVM in nixpkgs Nobody cares about pkgsLLVM except... | 16:42:32 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | 😈 | 16:42:45 |
| Tristan Ross | 🤔 | 16:43:14 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | @[Tristan Ross] I think for the two PRs of mine, if the next staging-next rebuilds the world, we let it in, otherwise we wait until branch off | 16:48:04 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | So we don't waste anything | 16:48:17 |
| Tristan Ross | In reply to @aleksana:mozilla.org
@[Tristan Ross] I think for the two PRs of mine, if the next staging-next rebuilds the world, we let it in, otherwise we wait until branch off I think that sounds fine | 16:50:23 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | If we don't fix it at all, people would not be able to create new bootstrap tarballs for exotic architectures following our guide, which can be considered as a regression caused by gcc14 update | 16:53:19 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | * If we don't fix it at all, people would not be able to use new bootstrap tarballs for exotic architectures following our guide, which can be considered as a regression caused by gcc14 update | 16:54:07 |
 emily | -next is pretty much guaranteed to rebuild the world | 17:00:04 |
| emily | it's likely there are already stdenv rebuilds in staging | 17:00:17 |
| emily | certainly I'm going to add one for Darwin ASAP | 17:00:24 |
| Tristan Ross | I remember doing a tall at Planet Nix about the different channels but I forget what they each do lol. | 17:01:47 |
| Tristan Ross | * I remember doing a talk at Planet Nix about the different channels but I forget what they each do lol. | 17:01:56 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @rosscomputerguy:matrix.org
I remember doing a tall at Planet Nix about the different channels but I forget what they each do lol. I fixed the graph at some point so I can't forget it | 17:09:22 |
 Randy Eckenrode | That would break Wine and DXVK. What is the replacement for things that need to build Windows DLLs? Wine’s use of MinGW is kind of bad (because it mixes cross- and native tools in an ugly way), but DXVK builds things as cross-to-Windows then symlinks those from the unversioned dxvk derivation). | 17:57:39 |
| Randy Eckenrode | I intend to package DXMT, which uses LLVM plus deps. I just haven’t had time (and it needs Wine patches, which sucks). | 17:58:51 |
| Randy Eckenrode | * I intend to package DXMT, which uses LLVM plus deps. I just haven’t had time (and it needs Wine patches, which kind of sucks). | 17:59:03 |
| Tristan Ross | I'm not sure what the solution is but we're not moving everything over until after the release this PR is merged in lol | 17:59:36 |
| Tristan Ross | So we do have time to come up with a solution | 17:59:46 |
| Tristan Ross | DXMT sounds like a good solution | 18:00:06 |
| Randy Eckenrode | I’m not sure how to structure DXMT. It’s a mix of native and Windows stuff. Ideally, cross from aarch64-darwin should build x86_64-darwin and x86_64-windows stuff. | 18:03:38 |
| emily | does it actually depend on Nixpkgs-packaged Windows stuff at runtime? | 18:04:30 |
| Randy Eckenrode | I also would like to rewrite the Wine derivation to be less ugly and support aarch64. I saw something on r/asahilinux about using FEX with Wine itself, so you could end up with a Wine that supports x86, x86_64, and arm64ec. | 18:04:33 |
| Randy Eckenrode | Yes. One of the things it builds a DLL that exposes Metal to the Windows side. | 18:06:23 |
| Randy Eckenrode | It’s like DXVK but for Metal. | 18:06:37 |
| Randy Eckenrode | * Yes. One of the things it builds is a DLL that exposes Metal to the Windows side. | 18:06:52 |
