Hello everyone, I just sent v4 of the patch series, addressing a concern from Winter about the order of the patches. Winter writes: > Hi all, > > Hopefully everyone can see this properly (e.g. in their email clients). > >> I didn't receive Winter's email and just saw it in the web interface >> after I sent v2 of the patch series. Should I be subscribed to the >> whole guix-patches mailing list as well to receive them? I'm new to >> the email based workflow and sometimes still a bit lost. > > I mistakenly thought that Debbugs would forward my message to the > participants, but it turns out you have to manually CC everyone if you > don't have the existing conversation in your mailbox (e.g. through > subscribing to the list). Maybe there's a better way to join the > conversation I'm not aware of, but for now, I've just CC'd everyone > manually. Yeah, I think that happend to me as well :) >> I'm not sure about the ordering of libdrm. I saw the mails are not ordered by patch number on the web interface. > > Ah! Yes, you're right, I didn't realize they were out of order in the web interface... strange! > >> But looking at my Git history, and the patch number in the subject >> line, libdrm ([PATCH 4/7] gnu: libdrm: Update to 2.4.114) is updated >> before adding asahi-mesa ([PATCH 5/7] gnu: Add asahi-mesa). So, >> aren't they in the correct order? > > Yup, that looks good to me! Though, I do have to ask: is there a > reason you swapped the additions of asahi-fwextract and asahi-mesa in > v3? It's technically okay (that is, libdrm is bumped before asahi-mesa > is added), but it may make more sense to group the two related changes > together? Maybe I'm nit-picking too much ;) I hope I addressed this in v4 of the patch series. >> However, rust-bindgen-cli isn't yet packaged, and the version I used previously (0.59.2) somehow disappeared from crates.io. They now only have versions > 0.61.0 available, which I plan to package. > > bindgen and bindgen-cli split into two crates with v0.61.0, see > https://github.com/rust-lang/rust-bindgen/blob/a8c8638d28f135823e913dab69b8a0d4fa4bbf15/CHANGELOG.md#changed-4. I > suspect if you check your previous code, you were pulling bindgen > pre-split. Aha, interesting. However, I still have the impression that some code disappeared from the crates repository. This was my original package definition that does not build anymore (it did a month ago). I will look into it. ``` (define-public rust-bindgen-cli (package (name "rust-bindgen-cli") (version "0.59.2") (source (origin (method url-fetch) (uri (crate-uri "bindgen-cli" version)) (file-name (string-append name "-" version ".tar.gz")) (sha256 (base32 "1f4fpycxmbrqk8r2x9brhfgjh86mzc6bngn4a9631x78b2jaklib")))) (build-system cargo-build-system) (arguments `(#:cargo-inputs (("rust-bindgen" ,rust-bindgen-0.59)) #:phases (modify-phases %standard-phases (add-before 'check 'disable-commandline-multiple-headers-test (lambda* (#:key outputs #:allow-other-keys) (substitute* "src/main.rs" (("fn commandline_multiple_headers") "#[ignore]\n fn commandline_multiple_headers"))))))) (inputs (list clang)) (home-page "https://rust-lang.github.io/rust-bindgen/") (synopsis "Generate Rust FFI bindings to C and C++ libraries") (description "This package is the CLI to rust-bindgen and can be used to automatically generate Rust FFI bindings to C and C++ libraries.") (license license:bsd-3))) ``` >> The rust team is updating many packages at the moment, so my plan was to wait until those made it into the main branch. > > Got it, thanks for the clarification. I was just asking because it did seem like building it was as simple as adding a few packages to inputs, so I was wondering if there was something I was missing. > >> I think the differences of package/inherit vs (inherit) aren't very clear to me. I'm guess I should use package/inherit to be able to use input transformations. Is that correct? > > Per my understanding, it has to to do with grafting, so maybe it only > makes sense when a package is/can be grafted? I'm sure someone else > can chime in with more concrete advice though, since both forms are > used throughout the tree. > > Moving on to Denis' comments: > >> The 3D acceleration is also experimental anyway, so as I understand Asahi Linux users need to opt-in and install a specific package to be able to use that. > > Correct, it comprises of a kernel built with a different config, and their Mesa fork. > >> That would still need a special kernel package built with 16K pages (that is needed for some hardware features related to the IOMMU), but it could probably be derived from the main kernel packages. Yes, I think so as well. The only missing thing to build this kernel is the Rust support (if you want the GPU driver) for building kernel modules. > This is just a single configuration flag, AFAIK. > > In general, I'm unsure if upstreaming these packages are the right > thing to do at this point in time, due to how fast the project is > moving. The Asahi team is going to eventually upstream ~all of their > patches, so in the meantime, it may make the most sense to put > everything Asahi-related in a channel? Of course, once things have > stabilized and things are upstreamed, the channel will get smaller and > smaller, but I think it may be the best option here. @Winter I actually have a Guix channel where these patches are coming from [1]. I asked a while ago on the guix-devel [2] mailing list if there is interest in adding some of those patches to Guix itself. At least Tobias showed interest, that's why I'm sending those patches. [1] https://github.com/r0man/asahi-guix [2] https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00348.html > > (If any of you are interested in working on this, I'd be happy to help! Please reach out.) > > WDYT? > I'm interested in collaborating on this, be it here or in my channel. I'm especially interested in help writing a Guix bootloader for m1n1. I'm not too familiar with how multiple bootloaders work in Guix, and how updating m1n1 on a Guix reconfigure should work with regards to rolling back in case something went wrong. I think the m1n1 Guix bootloader should do something similar on system reconfigure, as this script here does: https://raw.githubusercontent.com/AsahiLinux/asahi-scripts/main/update-m1n1 Replying to some of Denis questions: >> u-boot-apple-m1 is a modified version of u-boot from the Asahi Linux >> team, which is unlikely to be upstreamed from what I heard in the >> internet. > > Do you have pointers and references for that? I can't find it anymore. :/ I might have read it somewhere on Reddit, the Fediverse or in one of Hector Martins presentation. I'll let you know when I find it again. > Another way would be to (also) package all Asahi Linux forks whenever > possible and use that. Though in that case I wonder what is the plan > for updating the packages. For instance does Asahi Linux makes some > releases? If not how to decide on the frequency of updates? I think they do rolling releases, since they are based on Arch Linux. You get support for the GPU by installing their linux-asahi-edge and mesa-asahi-edge packages. https://asahilinux.org/2022/12/gpu-drivers-now-in-asahi-linux/ In my channel I track their https://github.com/AsahiLinux/PKGBUILDs repository and usually update packages whenever there is a change on their side. > And will there be any plans for migrating to upstream projects when > forks are no longer necessary? > My plan was to update the Asahi package variants as long as they are needed, and fade them out eventually when everything is upstreamed on their side. Roman