cosmic-{comp,panel,applets}: init

[alyssais]

Description of changes

This is the bare minimum that was necessary for me to have a usable COSMIC environment. (With just cosmic-comp, there's no way to e.g. start an application.) There are many more components of COSMIC that are not included here.

Since I know a lot of people have been waiting for this, I'll do some expectation management: This is enough to get COSMIC running, but I haven't done any work to integrate COSMIC into NixOS, because running it on NixOS is not my use case. It will probably work if you add all the packages to environment.systemPackages (because COSMIC relies on some stuff being globally available), and run cosmic-comp and cosmic-panel manually.

Also, COSMIC is pretty usable now, but it's still in very active development. Please be mindful of that when interacting with upstream. I've made sure that upstream is okay with us having it packaged in Nixpkgs.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[Philipp-M]

because running it on NixOS is not my use case

Out of curiosity: What's your use case then?

[alyssais]

because running it on NixOS is not my use case

Out of curiosity: What's your use case then?

https://spectrum-os.org/

[RaitoBezarius]

Built successfully via nixpkgs-review pr:

4 packages built:
cosmic-applets cosmic-comp cosmic-comp.debug cosmic-panel

Code looks excellent to me.
Tested multiple binaries without success because I am running X11/i3, so it obviously fails, but binaries do not crash for wrong reasons.

[alyssais]

Tested multiple binaries without success because I am running X11/i3, so it obviously fails, but binaries do not crash for wrong reasons.

It has an X11 backend — I think you should be able to run cosmic-comp. What errors?

EDIT: alternatively, you can of course try running cosmic-comp in its own VT.

[RaitoBezarius]

Tested multiple binaries without success because I am running X11/i3, so it obviously fails, but binaries do not crash for wrong reasons.

It has an X11 backend — I think you should be able to run cosmic-comp. What errors?

EDIT: alternatively, you can of course try running cosmic-comp in its own VT.

I do not have DRM on my X11 server I believe.

2023-08-25T13:53:34.095630Z ERROR smithay::backend::egl::ffi: [EGL] 0x3002 (BAD_ACCESS) eglInitialize: EGL_BAD_ACCESS error: In eglInitialize: EGLDisplay (0x55ba11929660): Backend failed to allocate context

2023-08-25T13:53:34.095657Z  WARN smithay::backend::x11: Failed to init X11 surface via egl, falling back to dri3: Failed to initialize EGL. Err: EGL cannot access a requested resource (for example a context is bound in another thread).
2023-08-25T13:53:34.095686Z ERROR smithay::backend::x11: error=The X server is not capable of direct rendering
2023-08-25T13:53:34.095739Z  WARN cosmic_comp::backend: Initializing X11 Backend failed. err=Could not get DRM node used by X server

Caused by:
    The X server is not capable of direct rendering
2023-08-25T13:53:34.096950Z ERROR panic: thread 'main' panicked at 'Failed to initialize any backend! Wayland status: NoCompositorListening X11 status: LibraryOpenError(OpenError { kind: Library, detail: "opening library failed (libXcursor.so.1: cannot open shared object file: No such file or directory); opening library failed (libXcursor.so: cannot open shared object file: No such file or directory)" })': /build/cargo-vendor-dir/winit-0.28.6/src/platform_impl/linux/mod.rs:757
   0: <backtrace::capture::Backtrace as core::default::Default>::default
   1: log_panics::Config::install_panic_hook::{{closure}}
   2: std::panicking::rust_panic_with_hook
   3: std::panicking::begin_panic_handler::{{closure}}
   4: std::sys_common::backtrace::__rust_end_short_backtrace
   5: rust_begin_unwind
   6: core::panicking::panic_fmt
   7: smithay::backend::winit::init
   8: cosmic_comp::backend::winit::init_backend
   9: cosmic_comp::backend::init_backend_auto
  10: cosmic_comp::main
  11: std::sys_common::backtrace::__rust_begin_short_backtrace
  12: main
  13: __libc_start_call_main
  14: __libc_start_main@@GLIBC_2.34
  15: _start

[alyssais]

I've added the missing libraries to fix the X11 backend. If it still doesn't work for you, it's likely Nvidia nonsense.

[siph]

I was able to get cosmic-comp running with wayland.

I couldn't figure out how to run anything from cosmic so I tested the cosmic-applets with Hyprland and everything that didn't depend on anything cosmic specific works like expected.

[ghost]

because running it on NixOS is not my use case

Out of curiosity: What's your use case then?

I too run a nixpkgs-based, non-NixOS system and am very interested in this package.

[ghost]

@ofborg build pkgsCross.aarch64-multiplatform.cosmic-panel

[ghost]

LGTM but the changes below are needed in order for cross compilation to work. Up to you whether to apply them here, or else leave them to a follow-up PR:

• cosmic-comp: fix cross compilation #251555

Only major question/concern: I think using patchelf instead of RUSTFLAGS will be less of a headache in the long run -- unless there's some reason why we can't use patchelf --add-needed?

With the changes below:

Built successfully on:

• x86_64-linux
• aarch64-linux (cross from x86_64-linux)

These require setting the use_bindgen feature flag on drm-sys, which cargo can't do (but crate2nix can!) because it is an indirect dependency:

• powerpc64le-linux
• mips64el-linux mixed n32/64 (cross from x86_64-linux)

[alyssais]

Only major question/concern: I think using patchelf instead of RUSTFLAGS will be less of a headache in the long run

Modifying the binary after the fact, rather than just having the linker generate what we want in the first place, feels like way more of a hack/headache to me.

[ghost]

Modifying the binary after the fact, rather than just having the linker generate what we want in the first place, feels like way more of a hack/headache to me.

Well yes, if cargo/just gave us a way to ask for exactly that, sure.

Anyways, going the environment variable route, we really should use one that applies only to linking, and only on the hostPlatform; either:

• NIX_CFLAGS_LINK_${suffixSalt} or
• CARGO_TARGET_*_RUSTFLAGS with -Clink-arg=

It does seem weird that, for native builds, any tools built by build.rs (like bindgen) will be linked against libEGL and libwayland-client -- even with the change above. But I guess it can't hurt.

[ghost]

Note: cosmic-comp builds with crate2nix!

If you want to use nix to hack on cosmic-comp, this is the way to go. Incremental+distributed builds without "build pollution" strewn all around your $HOME directory.

You need the very latest crate2nix plus:

• src/render.rs: handle CfgExpr::Any(vec![]) nix-community/crate2nix#288
• default-crate-overrides: add libseat-sys #251534

git clone upstream's source and run crate2nix generate to get Cargo.nix and crate-hashes.json. Here are mine (yours should be identical).

• Cargo.nix.gz
• crate-hashes.json.gz

Keep those two files, discard the rest of the upstream source. These two files are what would go into a PR if we allowed it. Then nix-build the file below, passing --arg pkgs 'import <nixpkgs>' or similar.

{ pkgs }:
(import ./Cargo.nix { inherit pkgs; })
.rootCrate
.build
.overrideAttrs {
  buildInputs = with pkgs; [
    libinput
    mesa
    libxkbcommon
  ];
}

This just gets it built (without using cargo). For a nice finished package you still want the installPhase, meta, and other trimmings found in this PR.

The big wins with crate2nix are:

• You can use overrides! Deep down in the dependency tree too!
• Incremental builds, at crate granularity. Great for hacking. Build in /nix/store as fast and as incrementally as cargo does in $HOME.
• Distributed builds: each crate is a derivation, they build in parallel on different machines. This lets you build much faster than cargo does if you have more than one builder.

[ghost]

Hey I'm about to leave town for a while, so let's just postpone fixing cross to a later PR. I've marked all but one of my suggested changes as "resolved", and that last one might not matter. Thanks for writing this!

[RaitoBezarius]

Result of nixpkgs-review pr 251365 run on x86_64-linux 1

4 packages built:

• cosmic-applets
• cosmic-comp
• cosmic-comp.debug
• cosmic-panel

[nyabinary]

What's the status of this pr?

[colemickens]

@amjoseph-nixpkgs can you email, or matrix me (@colemickens:matrix.org)? I am quite intrigued at the Crate2nix and have a little spike related to this PR and your comments that you might be interested in, and that I could use your advice on.

[nyabinary]

Can't wait for this tbh
There has to be options related to COSMIC as well I assume right?

[alyssais]

I'll be able to revisit this once we have #247442.

[nyabinary]

#247442 has been merged into staging.

[alyssais]

I've updated this to take advantage of #257411, which was the last change I wanted to make. I think this is ready now.

[nyabinary]

Should a tracking issue be made for COSMIC in general?

[alyssais]

Wouldn't that be #199563?

[nyabinary]

@alyssais Whoops just saw your comment now, I made #259641

[ghost]

@amjoseph-nixpkgs can you email, or matrix me (@colemickens:matrix.org)? I am quite intrigued at the Crate2nix and have a little spike related to this PR and your comments that you might be interested in, and that I could use your advice on.

@colemickens I'm digging myself out from under a huge backlog right now. Give me some time to get caught up.

[KiaraGrouwstra]

i'm not sure how different these OSs are, but as expected i didn't quite manage to get this up and running on nixos yet:

• cosmic-panel: running separately from the command-line yields ERROR Failed to connect to the notifications daemon Ok(Err(environment variable not found))
• cosmic-applets: applications listed in ls /nix/store/*-cosmic-applets*/bin/ seem to do nothing when run from the command-line
• cosmic-comp: running yields ERROR smithay::xwayland::xserver: XWayland crashed at startup, will not try to restart it.

i'd be curious if anyone has had more success there. 🙏

[MtFBella109]

I tried it, I added all the cosmic-packages to environment.Systempackages, as I try to start cosmic-comp in a tty, I get a few Errors, that it can't read a few Configs, like something with xdg and input and doesn't start at all

[ghost]

I'm still waiting for the long-overdue merge of staging into master; this is one of the many tasks I have which are blocked on that.