I just sent v4 of the patch series, addressing a concern from Winter
about the order of the patches.
Winter <email@example.com> writes:
Toggle quote (16 lines)
> 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
Yeah, I think that happend to me as well :)
Toggle quote (15 lines)
>> 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.
Toggle quote (7 lines)
>> 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
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
(uri (crate-uri "bindgen-cli" version))
(file-name (string-append name "-" version ".tar.gz"))
(add-before 'check 'disable-commandline-multiple-headers-test
(lambda* (#:key outputs #:allow-other-keys)
"#[ignore]\n fn commandline_multiple_headers")))))))
(inputs (list clang))
(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.")
Toggle quote (19 lines)
>> 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
Toggle quote (10 lines)
> 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 . I asked a while ago on the guix-devel  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.
Toggle quote (6 lines)
> (If any of you are interested in working on this, I'd be happy to help! Please reach out.)
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:
Replying to some of Denis questions:
Toggle quote (6 lines)
>> 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
> 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.
Toggle quote (5 lines)
> 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.
repository and usually update packages whenever there is a change on
Toggle quote (4 lines)
> 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