[bug#61959] [PATCH 0/7] Add some Asahi Linux packages

[Roman Scherer]

Hello everyone,

I just sent v4 of the patch series, addressing a concern from Winter
about the order of the patches.

Winter <winter@winter.cafe> 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

signature.asc
Description: PGP signature