Missing QT platform plugin for Wayland, GRUB menu-entry, and service/package definitions

[Genevieve Mendoza]

Hello,

I've started using Guix recently, and have accumulated a lot of
questions since I started (it's been a good experience though - and I
really appreciate the great documentation!) I'm listing them below in
ascending order of complexity:

1) I've noticed that there are service definitions which automatically
pull in the packages they require, with the main example being
desktop-services. I set up some of my own home services, e.g. for
Pipewire, and they work fine if I also have Pipewire installed
(via my profile or home environment). If I don't, then they can't find
the binary and fail. Is there a way to have them specify required
packages that I missed in the docs?

2) I also want to run Nextcloud, and I'd like to run it under Wayland.
I made sure to install qtwayland-5 alongside it. However, I still get
an error message about missing the "Qt platform plugin "wayland"".
I found another bug report which stated that installing qtwayland-5
did solve the problem, and it also was all I needed back on Arch,
so it feels likely I'm doing something wrong here. I'd appreciate any
suggestions!

    https://mail.gnu.org/archive/html/bug-guix/2021-11/msg00216.html

2) Alternate menu-entries specified in my OS configuration seem to
fail to boot by default, but I thought I'd ask if I'm doing something
wrong before filing an issue. I have the following:

    (menu-entry
      (label "Arch") ;; menu entry name, not partition label
      (linux "(hd0,gpt5)/boot/vmlinuz-linux")
      (linux-arguments '("root=PARTUUID=[partuuid]" "rw"))
      (initrd "(hd0,gpt5)/boot/initramfs-linux.img"))

which creates this GRUB entry, which does not boot:

    menuentry "Arch" {
      search --file --set /root(hd0,gpt5)/boot/vmlinuz-linux
      linux /root(hd0,gpt5)/boot/vmlinuz-linux root=PARTUUID=...
      initrd /root(hd0,gpt5)/boot/initramfs-linux.img
    }

Since I did not specify (device), I expected it to create the
following, which successfully boots:

    menuentry "Arch" {
      linux (hd0,gpt5)/boot/vmlinuz-linux root=PARTUUID=[partuuid] rw
      initrd (hd0,gpt5)/boot/initramfs-linux.img
    }

3) I tried packaging some rust apps which are not in the repositories.
I needed to use two 'hacks' to succeed:

Some have a minimum supported rust above 1.60, so I did the following:

    (define rust-1.65 (@@ (gnu packages rust) rust-1.65))

The cargo build system would then fail due to "invalid inclusion of
reserved file name Cargo.toml.orig," a test added to Cargo in the
following patch: https://github.com/rust-lang/cargo/pull/10551.

I tried adding a step to delete Cargo.toml.orig, based on Nicolas
Graves's code in issue 25327 (https://issues.guix.gnu.org/25327#5):

    #:phases (modify-phases %standard-phases
      (add-before 'package 'hacky-delete
        (lambda _
          (delete-file "Cargo.toml.orig")
          #t)))

I was then able to successfully build. This raised a few questions:

a) Is there a better known workaround than this?

b) I couldn't find much discussion in the mailing lists - is cargo
packaging with more recent rust versions in progress, or is
there nobody currently working on it? (I don't mean to sound entitled
in asking this - just wondering the context!)

c) Semi-related - when packaging, I had to also package some more
recent dependency crates, including some platform-specific Windows
crates. In the cargo build system file, I found the following comment:

> Building a package definition does not require actually building /
> checking any dependent crates. This can be a benefit ... the build
> will not fail if cargo ends up internally ignoring the dependency.

However, I noticed that various crates had #:skip-build? #t and
various others had it set to false, and I couldn't make sense of
when or why to set it. What are the best practices for this option?

Best regards,

Genevieve