From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id yJl0EEKGCGSqQwAASxT56A (envelope-from ) for ; Wed, 08 Mar 2023 13:57:38 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 6KBrEEKGCGSWdgEA9RJhRA (envelope-from ) for ; Wed, 08 Mar 2023 13:57:38 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 027DD713 for ; Wed, 8 Mar 2023 13:57:37 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pZtLs-0007lv-K0; Wed, 08 Mar 2023 07:57:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pZtLr-0007lR-AJ for guix-patches@gnu.org; Wed, 08 Mar 2023 07:57:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pZtLr-0006xH-0p for guix-patches@gnu.org; Wed, 08 Mar 2023 07:57:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pZtLq-0002x8-Ce for guix-patches@gnu.org; Wed, 08 Mar 2023 07:57:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#61959] [PATCH 0/7] Add some Asahi Linux packages Resent-From: Roman Scherer Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 08 Mar 2023 12:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61959 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Winter Cc: rekado@elephly.net, 61959@debbugs.gnu.org, GNUtoo@cyberdimension.org Received: via spool by 61959-submit@debbugs.gnu.org id=B61959.167828021111331 (code B ref 61959); Wed, 08 Mar 2023 12:57:02 +0000 Received: (at 61959) by debbugs.gnu.org; 8 Mar 2023 12:56:51 +0000 Received: from localhost ([127.0.0.1]:48018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZtLe-0002wf-Cb for submit@debbugs.gnu.org; Wed, 08 Mar 2023 07:56:51 -0500 Received: from mail-ed1-f41.google.com ([209.85.208.41]:46924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZtLb-0002wQ-ID for 61959@debbugs.gnu.org; Wed, 08 Mar 2023 07:56:48 -0500 Received: by mail-ed1-f41.google.com with SMTP id k10so41428253edk.13 for <61959@debbugs.gnu.org>; Wed, 08 Mar 2023 04:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=burningswell-com.20210112.gappssmtp.com; s=20210112; t=1678280201; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=ztOWXqh1iquaw9CAG2N/bECxDrVNbsV9LTzroitXRY8=; b=i6GjZh/tqAq+deF4sGcXkF/SqhVKYQ+nH0zkQobWfXGWf4lvCat9MyS+eVXG6YB0fo Agwhdppw801hcY8vS/JKLMG/A6xXh9BOgFx+9UcjvwS8XrYdtUmKZuI+KqNI6wUdSdw2 dJSIykagSg5/w8BtBzzhLWwPC8kPrV7o5i9w962xjyf6s50qG7WsLXxthw4Aw0LAZ5DQ hIKcoRGXIhMtEvJwou7/l0zzIkIl4opboXNb9GNatZuJ2r5e09GtpO0OEXymR70lKBdT oD1IAhSwxxRLaD4HDxddtSpVeGTze7NLCc2m+Bn1GUw9J7Kel8//YMDRDDe3WcAUmEe6 bACw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678280201; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ztOWXqh1iquaw9CAG2N/bECxDrVNbsV9LTzroitXRY8=; b=NGgouQSCuwXE9h/N+ehrGpVgYMyvmYFCNSYHtffAhhNMH1I1Xg8FlgNNk86nNtwfiW gB2GQDcumWUpYrzrhY5Bg34KlJhEf+TY1l3WceMGLTGyHviLz9sIonu/BNODcjF8HlFQ sO0orlfqyZfLQ49gyz386LH/V6Nyxq9g+jjQF38YypONtgiTVmPbGVDxUBFAxDNmm2Lr BiI7E3g/brtPutKRYOQkOG5cHFGdYZ2LjSH+mrc7Gsy59hT8JNpjSiqbBQpO5K6ejmZ5 IAXSvgqjb+APvRWkVvi4Rtb3OVlmSzYpy6VGgTYF+QrTrTuf+C1/G5QDkCjLGrSt1+/l GFhw== X-Gm-Message-State: AO0yUKU6Mjag9xJGSmn4qzyKCOIwzS1NT+N1M9kBS412OCNopMyppprZ yUYJVdwR8tl0awu2y7DHRs1R2g== X-Google-Smtp-Source: AK7set/5iF6IcGiotDmPk2G0Q7Kz3tanl8HyVAjisclqXnL5jld7wPgo4x3LGnfBJMjZ8GFtNdYZLQ== X-Received: by 2002:a17:906:c011:b0:877:ef84:c7de with SMTP id e17-20020a170906c01100b00877ef84c7demr16862389ejz.61.1678280201480; Wed, 08 Mar 2023 04:56:41 -0800 (PST) Received: from bombaclaat ([2a01:598:b1a6:a6ef:9056:798a:7775:63bc]) by smtp.gmail.com with ESMTPSA id y7-20020a50eb07000000b004bf28bfc9absm8048873edp.11.2023.03.08.04.56.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Mar 2023 04:56:41 -0800 (PST) References: User-agent: mu4e 1.8.13; emacs 29.0.60 From: Roman Scherer Date: Wed, 08 Mar 2023 13:14:25 +0100 In-reply-to: Message-ID: <86v8jbjta0.fsf@burningswell.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN Authentication-Results: aspmx1.migadu.com; none X-Migadu-Spam-Score: -4.00 X-Spam-Score: -4.00 X-Migadu-Queue-Id: 027DD713 X-Migadu-Scanner: scn1.migadu.com X-TUID: j28+DZfZ/LoQ --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 order= ed 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 pre= viously (0.59.2) somehow disappeared from crates.io. They now only have ver= sions > 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/a8c8638d28f135823e913dab69= b8a0d4fa4bbf15/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 se= em 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 clea= r to me. I'm guess I should use package/inherit to be able to use input tra= nsformations. 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 Asah= i Linux users need to opt-in and install a specific package to be able to u= se that. > > Correct, it comprises of a kernel built with a different config, and thei= r Mesa fork. > >> That would still need a special kernel package built with 16K pages (tha= t 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! P= lease 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFTBAEBCAA9FiEE0iajOdjfRIFd3gygPdpSUn0qwZkFAmQIhgcfHHJvbWFuLnNj aGVyZXJAYnVybmluZ3N3ZWxsLmNvbQAKCRA92lJSfSrBmQDiB/9M1DnH9HU3AisW kd+Q3liMwdbmAyvvb0xJv7NR9mu9duFo9npfKsvFqcfBfsUJg5R6DfrU0HDQ7YZ1 qm6iOlin1w5R38c6WG+qnhOzZIlRaocVTWDPcTL0fgoPumOSPEWSWeGNR0UqEK7b 2hFp2fCzNMFza6Prvcm6JMg4MSj1OLmmdLcvmPCVLA80W20/oLvDyIC7AewNZYLI xYarf7qPsR6zwmkaH31f+3rTQHuh1zdK9lazkoH1Su/zrSavSdFcaLzDSmaPUiTg SR8N0d6ToxOnTadlXCqXUkr3O5XeDZVjgzE7NKxSjwsU99+wG5GAWTc78CePLB+9 V9hRivqA =3dxf -----END PGP SIGNATURE----- --=-=-=--