-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix nxm links #1
Conversation
Heh, the rebase conflicts did not went as planned, well that happens when you force push all the time, and not just at the end ;) |
f5f6e18
to
b91a471
Compare
Thank you! I've included your fix (I think) in my PR, with you as co-author. Do we need the |
dbf363c
to
a4c7eb0
Compare
No, thats is only to make it pass when you disable tests |
[Vidstab][1] is an useful ffmpeg video stabilization filter. Both [Debian][2] and [Archlinux][3] enable it on default ffmpeg build, we should also enable it on default ffmpeg in nixpkgs. On the `master` branch, closure size for ffmpeg-headless went up 182.9KiB. ``` $ nix store diff-closures nixpkgs#ffmpeg-headless^bin .#ffmpeg-headless^bin ffmpeg-headless: +18.1 KiB vid.stab-unstable: ∅ → 2022-05-30, +164.8 KiB $ nvd diff $(nix build nixpkgs#ffmpeg-headless^bin --print-out-paths --no-link) $(nix build .#ffmpeg-headless^bin --print-out-paths --no-link) <<< /nix/store/kwihalx7ryh51ghcp8f1hhy8skbdh8w9-ffmpeg-headless-6.1.2-bin >>> /nix/store/ps62y85p9jgjbf2x9s97199mpqnd0ggz-ffmpeg-headless-6.1.2-bin Added packages: [A.] #1 vid.stab-unstable 2022-05-30 Closure size: 78 -> 79 (4 paths added, 3 paths removed, delta +1, disk usage +182.9KiB). ``` [1]: http://public.hronopik.de/vid.stab/ [2]: https://salsa.debian.org/multimedia-team/ffmpeg/-/blob/debian/7%256.1.1-5/debian/control#L158 [3]: https://gitlab.archlinux.org/archlinux/packaging/packages/ffmpeg/-/blob/2-6.1.1-7/PKGBUILD?ref_type=tags#L73
The first assumption[1] we had was that the `aarch64-unknown-none` target was missing from rustc and that this was the cause for the regression. However, it turns out that the relevant code from `rustc` wasn't used anyways because the Makefile does `--sysroot /dev/null`[2] which prevents rustc from using its own libcore. So luckily we don't have to patch the Rust bootstrap to get aarch64-linux back working[3]. In fact, the Rust part seems broken for both 6.10 and 6.11[4], but I decided to not bother since none of those are longterm versions. So all that's left here is to enable Rust for aarch64-linux because it clearly works[5]. [1] NixOS#315121 (comment) [2] https://lore.kernel.org/all/[email protected]/ [3] Of course I only realized this _after_ I spent some time hacking a rustc patch together 🙃 [4] This broke with error[E0463]: can't find crate for `core` | = note: the `aarch64-unknown-none` target may not be installed = help: consider downloading the target with `rustup target add aarch64-unknown-none` = help: consider building the standard library from source with `cargo build -Zbuild-std` [5] While the build is fine, the VM tests are still panicking, but that's also the case for `kernel-generic` because of a 9p regression: switch_root: can't execute '/nix/store/zv87gw0yxfsslq0mcc35a99k54da9a4z-nixos-system-machine-test/init': Exec format error [ 1.734997] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 1.736002] CPU: 0 UID: 0 PID: 1 Comm: switch_root Not tainted 6.12.0-rc1 #1-NixOS [...] Reported as https://lore.kernel.org/all/[email protected]/T/#u
A lot of tests are failing, so for now I just disabled it.