- Spectrum Development - spectrum-os.org

[PATCH nixpkgs 0/6] Fix build failures after Nixpkgs update
by Alyssa Ross 03 Aug '21

03 Aug '21

Alyssa Ross (6): chromiumOSPackages.vm_protos: set full go_package chromiumOSPackages.modemmanager: disable patches chromiumOSPackages.modemmanager-next: add gtk-doc chromiumOSPackages.libqmi: disable QRTR linux_cros: fix build wlroots: update Spectrum patches ...ayland-downgrade-to-wl_compositor-v3.patch | 64 ++++++----- ...til-support-virtio_wl-shm-allocation.patch | 11 +- ...-mk-don-t-leak-source-absolute-paths.patch | 4 +- ...ommon-mk-.gn-don-t-hardcode-env-path.patch | 4 +- .../os-specific/linux/chromium-os/default.nix | 3 +- .../linux/chromium-os/libqmi/default.nix | 4 +- .../chromium-os/modem-manager/default.nix | 2 + .../linux/chromium-os/modem-manager/next.nix | 6 +- ...er-don-t-leak-source-absolute-paths.patch} | 6 +- ...tools-sommelier-Switch-to-the-stabl.patch} | 6 +- .../linux/chromium-os/sommelier/default.nix | 4 +- ...-goproto_library-source_relative-opt.patch | 48 +++++++++ ...tools-proto-set-go_package-correctly.patch | 102 ++++++++++++++++++ .../linux/chromium-os/vm_protos/default.nix | 5 + 14 files changed, 222 insertions(+), 47 deletions(-) rename pkgs/os-specific/linux/chromium-os/sommelier/{0003-sommelier-don-t-leak-source-absolute-paths.patch => 0005-sommelier-don-t-leak-source-absolute-paths.patch} (82%) rename pkgs/os-specific/linux/chromium-os/sommelier/{0004-Revert-Revert-vm_tools-sommelier-Switch-to-the-stabl.patch => 0006-Revert-Revert-vm_tools-sommelier-Switch-to-the-stabl.patch} (99%) create mode 100644 pkgs/os-specific/linux/chromium-os/vm_protos/0003-common-mk-add-goproto_library-source_relative-opt.patch create mode 100644 pkgs/os-specific/linux/chromium-os/vm_protos/0004-vm_tools-proto-set-go_package-correctly.patch base-commit: cab13e087c80c4e7476bb7df432e2b7deb56563d -- 2.32.0

2 8

This (Last) Week in Spectrum, 2021-W30
by Alyssa Ross 02 Aug '21

02 Aug '21

Hi, it's been a long time since I've done one of these, but so much interesting stuff happened this week, and there's been a bit of renewed interest in the project, that it _really_ needed an update. So here it is. As always when I'm not keeping up with TWiS, this update is limited to only things that happened in the last week, because otherwise it would just be far too long. Wayland ------- A problem I've been thinking about for a long time is Wayland access control. The Linux desktop ecosystem is moving towards access controls for most functionality through xdg-desktop-portal[1] (which sadly doesn't seem to have a website). But it doesn't cover stuff that's part of the core Wayland protocol, like access to the clipboard. And some compositors (wlroots-based ones) provide extra Wayland protocols for things like screenshots. And up to now, Wayland compositors haven't really done any authorization for these potentially dangerous APIs. (All of this is only really meaningful for sandboxed applications -- running in Flatpak or a Spectrum VM or something. Linux isn't really set up to do separation between processes running as the same user without namespaces.) So earlier this week, I posted[2] to the Wayland mailing list with an idea I'd been thinking about for a while[3], which was to place a proxy program in front of the Wayland compositor, that would intercept client->compositor requests and handle access control. I was quickly convinced that a proxy wasn't a good idea, but there was a lot of discussion, and it was really helpful to me figuring out what the right way to do it might be. There are really two problems to be solved here, one of which I hadn't even thought much about. The first is securely identifying a Wayland client. A compositor needs to be able to form the question "Should client X be able to do this?", and to do that it needs to be able to identify a client as client X, and know if it tries to interact with client X later, that it'll be talking to the same client. In a non-virtualized system, the obvious way to do this would be getting the pid of the client from the connection socket and then looking it up in proc(5) to find out executable path, but this approach is fundamentally insecure[4]. The way forward here (and one that would work for Spectrum) appears to be the proposed Security Contexts protocol[5], which would allow a sandbox implementation to provide a security context identifier for a client before handing off the Wayland connection to the client. Once the security context had been set up, it wouldn't be allowed to be modified, so once the sandboxed client was given the connection, it wouldn't be able to change the security context identifier. In Spectrum, the security context identifier here would likely be a unique, user-provided name for the VM, and the security context setup would be done by the virtio wayland implementation in the VMM. The second part of this puzzle is how the compositor should decide whether a client should be allowed to perform a particular operation, like a paste or going fullscreen (which is risky because it might spoof a desktop). There was actually a previous attempt at this a long time ago. libwsm[7] (short for Wayland Security Module) was a library that compositors would have integrated to make authorization decisions. But it wasn't adopted by compositors, and it some things we now know[8] to be bad ideas, like setting policy based on the executable path. It also made compositors responsible for any sort of authorization UI. In my opinion, it's better to have that done by the external piece, so that compositors have as little work to do as possible and therefore authorization is implemented as widely as possible. The compositor could implement an authorization system entirely on its own, but this would be a lot of code for each compositor to write, and it would limit the user to whatever permissions system the compositor came up with, which might not be able to accommodate their needs. (An example of this would be a Spectrum user that wanted to allow pasting between two applications, but not allow pasting between either of those and any other application.) It could also be implemented by having the compositors integrate with something like polkit[6], but compositor authors are reluctant to integrate directly with a single system like that, and even polkit might not support everything that would be desirable in an authorization system. (For example, it might be nice to implement libwsm's concept of a soft allow, where an action is permitted, but a notification is shown so the user is aware it's happened.) So a third solution, suggested by ifreund, a Wayland compositor author, in the Spectrum IRC channel, would be to have a privileged Wayland client that the compositor could ask authorization questions to, with a new protocol. The compositor would know that this particular client should be privileged because it either wouldn't be in a security context, or would be given a special security context identifier known to the compositor ahead of time. Then, implementations of this protocol could do authorization however they wanted, with the only limitation being the questions the compositor was programmed to ask them. I think this is a good way forward, but it'd be important to discuss with more compositor authors before getting to excited about it. Next steps from here with Wayland are: * Figure out what needs to happen to move the security contexts proposal forward. If it needs an experimental implementation, maybe we could help with that? * Inquire about the authorization protocol idea, and see how other compositor offers would feel about it. If there's a generally positive reaction, figure out how to move forward with it. [1]: https://github.com/flatpak/xdg-desktop-portal/ [2]: https://lists.freedesktop.org/archives/wayland-devel/2021-July/041896.html [3]: https://spectrum-os.org/lists/archives/spectrum-discuss/8735ueudel.fsf@alys… [4]: https://gitlab.freedesktop.org/wayland/weston/-/issues/206#note_176699 [5]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68 [6]: https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html [7]: https://github.com/mupuf/libwsm [8]: https://lore.kernel.org/lkml/87r1xplsku.fsf@x220.int.ebiederm.org/ Nixpkgs ------- I created a branch in Spectrum's nixpkgs repository[9] for the long-overdue merge with upstream, did the merge, and posted some patches[10] to spectrum-devel that fix all the builds that broke as a result. I've been letting them sit for a few days hoping for a review. Once that's done, it's time for another chromiumOSPackages upgrade, but that should be pretty easy this time because we're only one version behind. [9]: https://spectrum-os.org/git/nixpkgs [10]: https://spectrum-os.org/lists/archives/spectrum-devel/20210729100928.196534… Thanks for keeping up with Spectrum. :)

1 0

Updating Spectrum's nixpkgs
by Alyssa Ross 29 Jul '21

29 Jul '21

I've just pushed a branch to our nixpkgs repository called nixpkgs-update, where I've merged in yesterday's nixos-unstable. From here, I'm going to send some patches targeting that branch, until everything builds again and we can merge it back into master. And then we're never going to go this long between updates ever again.

1 0

[PATCH nixpkgs 0/2] spectrumPackages.spectrum-vm: switch compositor from Wayfire to tinywl
by Alyssa Ross 01 Jul '21

01 Jul '21

This is another change I want to get in before updating Spectrum's Nixpkgs, because once we do that the current approach will no longer work. As explained in patch 2's commit message, this change only affects this demo, not the eventual Spectrum system. Alyssa Ross (2): tinywl: init at 0.11.0 spectrumPackages.sys-vms.comp: switch to tinywl .../window-managers/tinywl/default.nix | 30 ++++++++++++++++++ .../linux/spectrum/vm/comp/default.nix | 31 ++++++------------- pkgs/top-level/all-packages.nix | 2 ++ 3 files changed, 41 insertions(+), 22 deletions(-) create mode 100644 pkgs/applications/window-managers/tinywl/default.nix base-commit: 129d329e3bcdcc972454ce284e17da16b28bd401 -- 2.32.0

1 2

[PATCH nixpkgs 0/2] Pre-merge fixes for Nixpkgs update
by Alyssa Ross 01 Jul '21

01 Jul '21

I'm working on merging in a new version of upstream Nixpkgs. These are a couple of small fixes that came up during that work, but can be taken care of first since they make improvements to the current version. Alyssa Ross (2): chromiumOSPackages.modemmanager-next: fix libqmi spectrumPackages.sys-vms.comp: don't pin Emacs .../linux/chromium-os/modem-manager/next.nix | 12 ++++++++++-- pkgs/os-specific/linux/spectrum/vm/comp/default.nix | 4 ++-- 2 files changed, 12 insertions(+), 4 deletions(-) base-commit: 129d329e3bcdcc972454ce284e17da16b28bd401 -- 2.31.1

2 5

[PATCH platform2 0/2] Make vm_protos compatible with protoc-gen-go 1.5.x
by Alyssa Ross 30 Jun '21

30 Jun '21

My previous attempt[1] at this was totally wrong, because I didn't understand what change needed to be made, and didn't have any way of testing it. To make sure this time that I got it right, I wrote a package for tremplin[2], which was the only Chromium OS component I could find that was written in Go and actually used vm_protos. With these changes, I was able to add "${vm_protos}/lib/gopath" to tremplin's extraSrcPaths, and get a successful build. [1]: https://spectrum-os.org/lists/archives/spectrum-devel/20210627165035.899276… [2]: https://chromium.googlesource.com/chromiumos/platform/tremplin Alyssa Ross (2): common-mk: add goproto_library source_relative opt vm_tools: proto: set go_package correctly common-mk/proto_library.gni | 7 +++++++ vm_tools/proto/BUILD.gn | 5 +++++ vm_tools/proto/tremplin.proto | 2 +- vm_tools/proto/vm_crash.proto | 2 +- vm_tools/proto/vm_guest.proto | 1 + vm_tools/proto/vm_host.proto | 1 + 6 files changed, 16 insertions(+), 2 deletions(-) -- 2.31.1

2 4

[PATCH platform2] vm_tools: proto: fix go_package import path
by Alyssa Ross 27 Jun '21

27 Jun '21

This is required by protoc-gen-go >= 1.4.0. --- I don't really have any idea what I'm doing here -- this is my best guess. If somebody could tell me if it looks sensible I'd be much obliged. vm_tools/proto/common.proto | 1 + vm_tools/proto/tremplin.proto | 2 +- vm_tools/proto/vm_crash.proto | 2 +- vm_tools/proto/vm_guest.proto | 1 + vm_tools/proto/vm_host.proto | 1 + 5 files changed, 5 insertions(+), 2 deletions(-) diff --git a/vm_tools/proto/common.proto b/vm_tools/proto/common.proto index 39a3e39528..f11d128ef1 100644 --- a/vm_tools/proto/common.proto +++ b/vm_tools/proto/common.proto @@ -8,6 +8,7 @@ option cc_enable_arenas = true; // Common definitions used by both host and guest messages. package vm_tools; +option go_package = "chromiumos/vm_tools"; // gRPC requires that every RPC has an argument and a return value. This empty // message is used when an argument or return value is not required. diff --git a/vm_tools/proto/tremplin.proto b/vm_tools/proto/tremplin.proto index aac76f7a9e..0a8968fe8d 100644 --- a/vm_tools/proto/tremplin.proto +++ b/vm_tools/proto/tremplin.proto @@ -8,7 +8,7 @@ option cc_enable_arenas = true; // This file defines services for tremplin, the container springboard service. package vm_tools.tremplin; -option go_package = "tremplin_proto"; +option go_package = "chromiumos/vm_tools/tremplin/tremplin_proto"; // This needs to be duplicated because the gyp rule for building // go code makes it difficult to have imports. diff --git a/vm_tools/proto/vm_crash.proto b/vm_tools/proto/vm_crash.proto index 6e4f62fe13..70d620fde8 100644 --- a/vm_tools/proto/vm_crash.proto +++ b/vm_tools/proto/vm_crash.proto @@ -7,7 +7,7 @@ syntax = "proto3"; option cc_enable_arenas = true; package vm_tools.cicerone; -option go_package = "vm_crash"; +option go_package = "chromiumos/vm_tools/cicerone/vm_crash"; import "common.proto"; diff --git a/vm_tools/proto/vm_guest.proto b/vm_tools/proto/vm_guest.proto index 34d2fd3d60..b3a742ec07 100644 --- a/vm_tools/proto/vm_guest.proto +++ b/vm_tools/proto/vm_guest.proto @@ -8,6 +8,7 @@ option cc_enable_arenas = true; // This file defines services that will be running in the guest VM. package vm_tools; +option go_package = "chromiumos/vm_tools"; import "common.proto"; import "google/protobuf/timestamp.proto"; diff --git a/vm_tools/proto/vm_host.proto b/vm_tools/proto/vm_host.proto index a8bd066f61..de31fa747f 100644 --- a/vm_tools/proto/vm_host.proto +++ b/vm_tools/proto/vm_host.proto @@ -8,6 +8,7 @@ option cc_enable_arenas = true; // This file defines services that will be running on the host for the VM. package vm_tools; +option go_package = "chromiumos/vm_tools/vm_host"; import "common.proto"; -- 2.31.1

1 0

[PATCH doc] Add note about spectrum-vm Mesa version mismatches
by Alyssa Ross 24 Jun '21

24 Jun '21

Cc: Cole Helbling <cole.e.helbling(a)outlook.com> --- developer-manual.adoc | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/developer-manual.adoc b/developer-manual.adoc index da37ef0..9db8b3c 100644 --- a/developer-manual.adoc +++ b/developer-manual.adoc @@ -121,6 +121,14 @@ spectrumPackages.spectrum-vm --run spectrum-vm` in a terminal, which will start up an instance of crosvm from Nixpkgs running Wayfire in a new window. +**** +If no Wayfire window appears, and you see error messages about EGL, +the cause is likely to be a mismatch between the Mesa version on your +host system, and the one Spectrum's Nixpkgs. If Spectrum's Mesa is +out of date, please report it using any of the project's +https://spectrum-os.org/participating.html[communication channels]. +**** + **** Be advised that Wayfire's default keymap is set to Dvorak https://spectrum-os.org/git/nixpkgs/tree/pkgs/os-specific/linux/spectrum/ro… -- 2.31.1

1 1

[PATCH nixpkgs 1/4] kernelPatches: drop export_kernel_fpu_functions
by Alyssa Ross 03 Jun '21

03 Jun '21

From: Atemu <atemu.main(a)gmail.com> Hasn't been necessary since ZFS 0.8.3 (cherry picked from commit 88f877e07def90a2c77106b86802b143ca8f97b3) Backporting this for Spectrum because it won't apply to future CrOS kernels. --- .../export_kernel_fpu_functions_4_14.patch | 60 ------------------- .../export_kernel_fpu_functions_5_3.patch | 42 ------------- pkgs/os-specific/linux/kernel/patches.nix | 11 ---- pkgs/top-level/all-packages.nix | 6 -- 4 files changed, 119 deletions(-) delete mode 100644 pkgs/os-specific/linux/kernel/export_kernel_fpu_functions_4_14.patch delete mode 100644 pkgs/os-specific/linux/kernel/export_kernel_fpu_functions_5_3.patch diff --git a/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions_4_14.patch b/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions_4_14.patch deleted file mode 100644 index 205497aee2d..00000000000 --- a/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions_4_14.patch +++ /dev/null @@ -1,60 +0,0 @@ -From 245e0f743d814c9ff2d1c748175e321301eb16cf Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= <joerg(a)thalheim.io> -Date: Thu, 2 May 2019 05:28:08 +0100 -Subject: [PATCH] x86/fpu: Export __kernel_fpu_{begin,end}() - -This partially undo commit: - -12209993 x86/fpu: Don't export __kernel_fpu_{begin,end}() - -We need this symbol in zfs for AES-NI/AVX support. ---- - arch/x86/include/asm/fpu/api.h | 2 ++ - arch/x86/kernel/fpu/core.c | 6 ++++-- - 2 files changed, 6 insertions(+), 2 deletions(-) - -diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h -index b56d504af6545..7d53388d266ea 100644 ---- a/arch/x86/include/asm/fpu/api.h -+++ b/arch/x86/include/asm/fpu/api.h -@@ -18,6 +18,8 @@ - * If you intend to use the FPU in softirq you need to check first with - * irq_fpu_usable() if it is possible. - */ -+extern void __kernel_fpu_begin(void); -+extern void __kernel_fpu_end(void); - extern void kernel_fpu_begin(void); - extern void kernel_fpu_end(void); - extern bool irq_fpu_usable(void); -diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c -index 2e5003fef51a9..2ea85b32421a0 100644 ---- a/arch/x86/kernel/fpu/core.c -+++ b/arch/x86/kernel/fpu/core.c -@@ -93,7 +93,7 @@ bool irq_fpu_usable(void) - } - EXPORT_SYMBOL(irq_fpu_usable); - --static void __kernel_fpu_begin(void) -+void __kernel_fpu_begin(void) - { - struct fpu *fpu = &current->thread.fpu; - -@@ -111,8 +111,9 @@ static void __kernel_fpu_begin(void) - __cpu_invalidate_fpregs_state(); - } - } -+EXPORT_SYMBOL(__kernel_fpu_begin); - --static void __kernel_fpu_end(void) -+void __kernel_fpu_end(void) - { - struct fpu *fpu = &current->thread.fpu; - -@@ -121,6 +122,7 @@ static void __kernel_fpu_end(void) - - kernel_fpu_enable(); - } -+EXPORT_SYMBOL(__kernel_fpu_end); - - void kernel_fpu_begin(void) - { diff --git a/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions_5_3.patch b/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions_5_3.patch deleted file mode 100644 index dc9ca64bdc1..00000000000 --- a/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions_5_3.patch +++ /dev/null @@ -1,42 +0,0 @@ -From 1e010beda2896bdf3082fb37a3e49f8ce20e04d8 Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= <joerg(a)thalheim.io> -Date: Thu, 2 May 2019 05:28:08 +0100 -Subject: [PATCH] x86/fpu: Export kernel_fpu_{begin,end}() with - EXPORT_SYMBOL_GPL -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -We need these symbols in zfs as the fpu implementation breaks userspace: - -https://github.com/zfsonlinux/zfs/issues/9346 -Signed-off-by: Jörg Thalheim <joerg(a)thalheim.io> ---- - arch/x86/kernel/fpu/core.c | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c -index 12c70840980e..352538b3bb5d 100644 ---- a/arch/x86/kernel/fpu/core.c -+++ b/arch/x86/kernel/fpu/core.c -@@ -102,7 +102,7 @@ void kernel_fpu_begin(void) - } - __cpu_invalidate_fpregs_state(); - } --EXPORT_SYMBOL_GPL(kernel_fpu_begin); -+EXPORT_SYMBOL(kernel_fpu_begin); - - void kernel_fpu_end(void) - { -@@ -111,7 +111,7 @@ void kernel_fpu_end(void) - this_cpu_write(in_kernel_fpu, false); - preempt_enable(); - } --EXPORT_SYMBOL_GPL(kernel_fpu_end); -+EXPORT_SYMBOL(kernel_fpu_end); - - /* - * Save the FPU state (mark it for reload if necessary): --- -2.23.0 - diff --git a/pkgs/os-specific/linux/kernel/patches.nix b/pkgs/os-specific/linux/kernel/patches.nix index 8ce1ac2b587..678cec34b70 100644 --- a/pkgs/os-specific/linux/kernel/patches.nix +++ b/pkgs/os-specific/linux/kernel/patches.nix @@ -76,17 +76,6 @@ }; }; - export_kernel_fpu_functions = { - "4.14" = { - name = "export_kernel_fpu_functions"; - patch = ./export_kernel_fpu_functions_4_14.patch; - }; - "5.3" = { - name = "export_kernel_fpu_functions"; - patch = ./export_kernel_fpu_functions_5_3.patch; - }; - }; - # patches from https://lkml.org/lkml/2019/7/15/1748 mac_nvme_t2 = rec { name = "mac_nvme_t2"; diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix index c22a62456db..6ba0505cb8a 100644 --- a/pkgs/top-level/all-packages.nix +++ b/pkgs/top-level/all-packages.nix @@ -17500,7 +17500,6 @@ in # when adding a new linux version kernelPatches.cpu-cgroup-v2."4.11" kernelPatches.modinst_arg_list_too_long - kernelPatches.export_kernel_fpu_functions."4.14" ]; }; @@ -17509,7 +17508,6 @@ in [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper kernelPatches.modinst_arg_list_too_long - kernelPatches.export_kernel_fpu_functions."4.14" ]; }; @@ -17517,7 +17515,6 @@ in kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper - kernelPatches.export_kernel_fpu_functions."5.3" ]; }; @@ -17525,7 +17522,6 @@ in kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper - kernelPatches.export_kernel_fpu_functions."5.3" ]; }; @@ -17533,7 +17529,6 @@ in kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper - kernelPatches.export_kernel_fpu_functions."5.3" ]; }; @@ -17563,7 +17558,6 @@ in kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper - kernelPatches.export_kernel_fpu_functions."5.3" ]; }; -- 2.31.1

1 3

[PATCH nixpkgs v2 0/8] chromiumOSPackages: 83.13020.0.0-rc1 -> 89.13729.0.0-rc1
by Alyssa Ross 02 Jun '21

02 Jun '21

Hi everyone, This is a continuation of the effort to update our chromiumOSPackages, which was started by Jamie a couple of months ago[1]. I've taken it over, and I think it should be good now. Specifically, since Jamie's original submission I: * Re-enabled xdg-shell in Sommelier, using the reverted upstream implementation[2] instead of Puck's. * Fixed the crosvm build by fixing its Cargo.lock, and stopping the boot test trying to open /dev/log, which doesn't exist in Nix builds. * Rebased a crosvm patch that was added to Spectrum in the meantime. * Removed a kernel patch that was added to Spectrum in the meantime but this update makes obsolete. I've tested that everything in spectrumPackages and chromiumOSPackages builds, and that spectrumPackages.spectrum-vm still runs. Jamie, thank you so much for getting us most of the way there with this -- you saved me a lot of time and I really appreciate it. [1]: https://spectrum-os.org/lists/archives/spectrum-devel/0100017891d36f4f-0c34… [2]: https://spectrum-os.org/lists/archives/spectrum-devel/87wntkwq7z.fsf@alyssa… Alyssa Ross (3): chromiumOSPackages.sommelier: update patches crosvm: fix build spectrumPackages.linux: drop evged patch Jamie McClymont (5): chromiumOSPackages: 83.13020.0.0-rc1 -> 89.13729.0.0-rc1 chromiumOSPackages.linux: fix config chromiumOSPackages.common-mk: update patches chromiumOSPackages.vm_protos: drop GN patch chromiumOSPackages.common-mk: disable clang-only warnings ...-mk-don-t-leak-source-absolute-paths.patch | 115 +- ...ommon-mk-.gn-don-t-hardcode-env-path.patch | 8 +- .../linux/chromium-os/common-mk/default.nix | 6 +- .../crosvm/Regenerate-Cargo.lock.patch | 681 ++++++++++++ ...om-tap-fd.patch => VIRTIO_NET_F_MAC.patch} | 202 ++-- .../linux/chromium-os/crosvm/default.nix | 20 +- ...er-don-t-leak-source-absolute-paths.patch} | 10 +- ...tools-sommelier-Switch-to-the-stabl.patch} | 981 ++++++++++-------- ...mmelier-make-building-demos-optional.patch | 100 -- .../linux/chromium-os/sommelier/default.nix | 5 +- .../linux/chromium-os/upstream-info.json | 44 +- ...03-vm_tools-proto-fix-parallel-build.patch | 39 - .../linux/chromium-os/vm_protos/default.nix | 2 - pkgs/os-specific/linux/kernel/linux-cros.nix | 6 +- pkgs/os-specific/linux/kernel/patches.nix | 9 - pkgs/os-specific/linux/spectrum/linux/vm.nix | 3 - 16 files changed, 1445 insertions(+), 786 deletions(-) create mode 100644 pkgs/os-specific/linux/chromium-os/crosvm/Regenerate-Cargo.lock.patch rename pkgs/os-specific/linux/chromium-os/crosvm/{0001-crosvm-support-setting-guest-MAC-from-tap-fd.patch => VIRTIO_NET_F_MAC.patch} (56%) rename pkgs/os-specific/linux/chromium-os/sommelier/{0004-sommelier-don-t-leak-source-absolute-paths.patch => 0003-sommelier-don-t-leak-source-absolute-paths.patch} (69%) rename pkgs/os-specific/linux/chromium-os/sommelier/{0005-sommelier-use-stable-xdg-shell-protocol.patch => 0004-Revert-Revert-vm_tools-sommelier-Switch-to-the-stabl.patch} (66%) delete mode 100644 pkgs/os-specific/linux/chromium-os/sommelier/0006-sommelier-make-building-demos-optional.patch delete mode 100644 pkgs/os-specific/linux/chromium-os/vm_protos/0003-vm_tools-proto-fix-parallel-build.patch -- 2.31.1

1 9