No Linters Available
No Unit Test Coverage
Those packages are commented out right now because they don't exist in the repos yet. Currently I cannot test it because it crashes on start due to missing dependencies. Before this package is submitted those dependencies need to be packaged into the repos.
Those packages are commented out right now because they don't exist in the repos yet.
That's why we have solbuild local repositories: https://getsol.us/articles/packaging/local-repository/en/
This kind of discussion is better to be done in our irc channel #Solus-Dev.
Also GtkStressTesting is named gst from its developer. Other distros followed also same naming, just gst.
I think it is better for solus too, to use name 'gst' instead of gtkstresstesting.
Changes didn't address my comments. Have further review items as well.
Not a valid SPDX 3.x identifier: https://getsol.us/articles/packaging/packaging-practices/en/#licenses
This is going to conflict with any usage of the oh-my-zsh git plugin. Their meson.build for the gst binary should be patched to have binary be outputted as something like gtk-stress-testing.
Their service and desktop files will also likely need to be patched for the changed binary name: https://gitlab.com/leinardi/gst/-/tree/release/data
[Info] Building gtk-stress-testing-0.7.1 [Build] Building native package [Source] Extracting source [Build] Running step: build [Build] Enabling ccache + cd /home/build/YPKG/root/gtk-stress-testing/build/gst-0.6.1-4179e7af494ef457a30e3a7c5af5f0868afea992
Sorry for the nonresponse, and sorry for abandoning my patch after you guys spent a lot of your time teaching me about Solus packaging. I'm on Gentoo right now, with no intention of going back to Solus. I still believe Solus is the best distribution but I want to use the Sway window manager without a desktop environment and it's a bit harder to do that on Solus. I will try to set up a virtual machine to continue contributing to Solus, but I'm very busy with other stuff at the moment.
I'm on Gentoo right now, with no intention of going back to Solus.
In that case we don't really have a reason to merge this. The goal is to have dedicated package maintainers that actively use Solus and ensure the package is well integrated. Closing.