I'm not an advocate of Onlyoffice, which I only discovered today, but it seems interesting to me because it differs from the alternatives we have in several ways:

Here is an example with matterhorn compiled with ghc 8.10.6 (which I got using ghcup):

It seems the clipboard is no longer working in MuPDF although the work done here had fixed it. Is it still being built with the shipped library or did it revert to the system freeglut libary again @livingsilver94?

There are now stable releases for Looking Glass.

The latest release of proxychains on Github is dated January 2021: https://github.com/haad/proxychains/releases

Until someone has the skills to submit a patch for the Solus repository, mu can be compiled and installed this way:

Interested in caddy too, I recently migrated from nginx to caddy on my Debian server and was impressed by the simplicity and possibilities in config files. I see above that it is not easy to package, but maybe things have changed regarding plugins since 2018 since I think they moved to caddy v2 which is significantly different? In the mean time, I'll look into just downloading a binary for my machine.

Great, thank you!

This has sat in accepted for inclusion for over 30 days. Clearly, there is a lack of demand for the inclusion of this software

True, I forgot that we are on i3-gaps (which is great). I don't have a good knowledge of all the other patches that were included since then and would be particularly welcome for our package, but I know this one fixes an issue many people would face with multimonitor setups.

Well to be completely honest, the fix that I was personally interested in was the one I linked, which in the end turns out not being included in the current release tarball. But then once I realized, this task was already opened, so I thought an update would still be useful to other Solus users anyway given that we are more than 8 months behind. For my personal use, the next release tarball would actually be the most important.

Is the decision to reject aspell final? The reason was that it was stagnating since 2011 with no new releases, but there was a release in mid October last year which shows that it is still alive, and some applications rely on it with no alternative (i.e., Kakoune text editor, Matterhorn CLI client for Mattermost).

I use browsh too occasionally, would love to see it included in the repo as well.

The MuPDF included in the repository was not built with the shipped third party library that is required for clipboard and unicode support in freeglut. The system freeglut package does not support system copy/paste or unicode, so these features are missing in our version of MuPDF in the Solus repository.

Is there any update on whether this can be accepted for inclusion?

The AppImage version doesn't offer easy updates as snap packages do, but I would recommend it if you care about features like minimize to tray and theme consistency across your system. I didn't check the snap package lately, but it was nos as polished as the AppImage version on these two aspects the last time I tried it (see my message above). However if you try the latest version and don't notice these issues, please report back.

Just curious about this task: it was closed long ago in favor of appimaged but I don't find appimaged in the repository. As @BrowncoatShadow said before, I don't really care about what we have (nor do I have skills to properly compare myself), but I think we should have one. For instance, if using a tiling WM with dmenu to launch applications, appimages won't be integrated in dmenu without appimagelauncher.

Not meaning to put any pressure on Josh, but just to bring grist to the mill, some recent observations on another Linux device:

I would also want to have MuPdf available in our repository. The reason is I wanted something lightweight, straightforward, with good benchmarks, and supporting keyboard navigation. I was sure it would be included based on those characteristics compared to alternative PDF readers, so I went straight to terminal and ran sudo eopkg it mupdf. When it failed, my first assumption was just that it was spelled differently in our repos because I was assuming it is a standard thanks to its performance and would be included, but later understood it just is not there.

There is also a snap, which I installed instead of the flatpak because I admit I am quite awkward with the dependencies of flatpaks and do not fully understand how the system works. I would recommend installing using snap install pdftk instead of sudo snap install pdftk though, as opposed to what is written in the pdftk snap page, to avoid any $PATH issue.

I have no experience with terminal-based-mail-clients so I don't know if alternatives have real benefits, but I wanted to bring grist to the mill on the potential value-add of neomutt. I think this post by the developer of neomutt sums it up. There is also a more in depth description from user and developer perspectives.

I followed all the steps mentioned in the Reddit guide or in your above post @tarkah, but it is still failing for me. Could you please elaborate on your last point about the .desktop file?

Is this indefinitely abandoned @miwilc? I don't think other terminals offer the same features as Terminology, even today.

Late to the party, but I would be interested in Terminology as well for the same reasons @miwilc teased. Terminology can play videos right into the terminal for instance, which can be very handy combined with the usually powerful features of terminal emulators like tabs, keybindings, borderless resizable windows, transparency, etc. Perhaps other terminals in the repository can do it too now, but I failed to find how this could be done.

Thanks a lot @joebonrichie.

I moved a folder containing small files into my /home partition and now my System is hanging because of tracker-extract chewing in my CPU. I hard to hard reboot because nothing was responsive, but the same happens when the system starts:

In my case, certificates are not populated as in @sunnyflunk's message:

\o/

It is great to see that @tkashkin considers the current versions stable, and seems pretty determined at helping making Gamehub available as an eopkg. It seems to clear the issues that lead @DataDrake to tagging this task as Wontfix earlier (correct?).

Not sure if this will ever be developed, but if someone at budgie-extras picks it up in the future, then I would love to see this one (invert colors on specific windows) added to your list.

Note that Blade recently released an AppImage version of their client. It is still a beta, but it works on Solus (at least with Intel chipset and AMD GPUs). With an AMD GPU, if the stream is pink/red/green, then creating /etc/drirc with the following content will solve the issue:

I am having this issue since several months (probably around mid-2018) on a laptop that used to run acceptable temperatures with Solus. I am using tracker daemon -t since late 2018 as well every time I start a session, and can confirm it significantly reduces the CPU load and temperature, but this can only be a temporary workaround since it disables the tracker.

This task is tagged as "Needs more info" but I do not know what extra information should be provided, and I assume the problem is not restricted to my computer since it happens with different GPUs on Solus but not on Ubuntu Budgie. Maybe someone could test with different CPUs and GPUs, but I can't test more combinations than I already did.

I can confirm that this is still an issue.

I am away from home since early October and could not check if this is still an issue after the latest Solus updates, since I only have my laptop with me at the moment. I will be back soon and will be able to test again. However, I have ordered a new GPU and gave the old one to someone, therefore I will not be able to check the exact same setups with an AMD HD 7850 as I did when I opened this task. Since the new GPU is AMD as well, I believe the tests might still be useful.

I know a decision has been taken, but I am using the Mattermost client since more than 2 years now and would not use it in a browser at all.

In T6736#126464, @joebonrichie wrote:

It seems to be running fine on Ubuntu though with radeonsi so it may not be related (I missed that piece of information).

I can confirm the same broken video output in mpv with radeonsi and vaapi-glx, but correct output with vaapi-egl.

Thanks for the answer @joebonrichie. This is sad, I suppose we can only wait then.

After a few days of use, I can confirm the application is running flawlessly on the laptop with updated i965 driver (currently in unstable) as VA driver.

The Ubuntu laptop (let's call it Computer 4) I tried before was indeed older hardware, probably 6 or 7th generation CPU instead of 8th on Computer 2 in the tests above. But when I find a thumb drive, I can definitely compare Ubuntu and Solus on all three machines (computers 2, 3 and 4) if you think it could bring useful information. I cannot install Ubuntu on all three machines though, so it all comes down to whether tests can be done from LiveUSB or not.

I have not tested on Ubuntu yet because I was running out of thumb drives to install a new distribution or try on a LiveUSB, but I can borrow a thumb drive tomorrow at work and try. Just let me know what you want me to try exactly, the AppImage or the i965 driver?

Another tester is getting the same black screen and "vaPutSurface failed" issues on Solus on a computer with Kaby Lake CPU and i965 driver for VA, just like me on another Solus computer with Kaby Lake CPU and i965 driver for VA. However, using the AppImage, I do get the Shadow stream on another Solus machine that uses radeonsi as VA driver, with no such "vaPutSurface failed" logs. This suggests that i965 is the reason for the black screen and "vaPutSurface failed" issues.

Someone built an executable AppImage using the 18.10 .deb file from Shadow, and embedded all libraries except qt and libva, those libs being loaded on the OS. When running this AppImage on Ubuntu, Debian or Arch, everything seems to be working fine as long as the user belongs to group input and h.264 and h.265 are supported on the machine. Yet, when I run it on Solus, I get the exact same issue I had when I manually loaded Ubuntu 18.04 libraries (see above message), *i.e.*, the ClientSDL renderer application runs, shows the distant cursor and can be interacted with, but the stream is just black. The crashlog seems to be identical as well:

They are both already installed apparently, probably because I have Steam installed. How can I check which version is being used? Uninstalling those packages to force the use of an alternate version would uninstall Steam.

Some progress, but maybe a new dead end:

Just out of curiosity, I tried running the application on an Ubuntu 18.04 LiveUSB and the libva lines were there too, so I this is not the issue.

Thanks for the answer @sunnyflunk. The output of vainfo shows that it is working, yes, I can see many formats supported:

I have deleted all *login* files in ~/.local/share/keyrings and it might have fixed the issue, but still needs more time to be confirmed because I didn't test everything. Just normal use of my computer will tell. If you don't see me again here, consider this solved!

I have created another Solus user to do some testing, as advised by @sunnyflunk. With this user, I loaded one of my OpenVPN configurations with the network manager, had to type the VPN password the first time (!= Solus user password), and I could see that the corresponding entry was added in the keyring. I rebooted, logged in with this user again, tried to connect to the VPN again using the network manager, and it worked without the keyring prompting me to type my user (Solus) password. With my main Solus user, a keyring window would pop up and ask for my Solus password before it successfully loads the OpenVPN configuration and corresponding VPN credentials.

The code @TaronjaNegra posted doesn't cause any segmentation fault on my end, with the latest Rstudio version from the repository. As described above, I have had crashes even with simple things like just copy/pasting a line of code from one script to another (but not all the time), and I suspect these crashes might be of different nature. I have had segmentation fault issues as well but I don't think that was the case for the copy/paste crashes or single-line executions. How much free space do you have on /home? If I remember correctly, the segmentation faults I had occurred only when my /home was almost full. Or maybe / instead of /home, if Rstudio uses /tmp, I don't know.

I've been having the same issue with a rather old Canon reflex camera as well a couple weeks ago. It was at work and I had no time so I did not investigate much and instead just plugged the camera to another computer. Therefore I cannot give any relevant details, but just wanted to confirm having a similar issue although I could not investigate the real cause.

I did not know about this request but I was coincidentally discussing about another similar application last night on IRC. KDE Connect has nice features, but is heavy, complicated, made for KDE, and made for Android. This leaves a lot of people behind. Plus it also requires a browser add-on and therefore not all browsers are compatible either. It is not a simple solution for those who just want to control their Gnome-mpv instance from their couch.