I feel like this shouldn't be merged into a task that has seen no real movement for over 4 years.

Chatty 0.20 : Added experimental 7TV emotes support (currently only Windows and Linux x64),

I claimed that Chatterino has support for 7tv emotes. It had at the time of making this request, but has since dropped it because of 7tv API problems.

For non-native speakers face a lot of difficulties. But as technology grow rapidly there are several grammar, spell checking tools available on internet. I personally suggest to use spell Checking tool.

Image optimization programs rely upon MozJPEG which is a standard lossless JPEG compression format. The best thing about it is that it preserves the information in the image without losing quality or speed. Utilizing the most recent technology, this jpeg compress utility reduces the image size without sacrificing image quality or color depth.

Ah, I see. Just use the recent Appimage with Solus. So, no packaging possible. :(

Seems like the open source version of it was discontinued: https://github.com/ramboxapp/community-edition

Duplicate of T2532.

It appears that this software is active nowadays, with the latest version, 2.8.0 having been released on April 22, 2022, and the latest commit to master being 5 hours ago (and I can see that it was certainly active during the past few months).

In T10259#196745, @playforvoices wrote:

Hi @algent

You are maintaining the budgie-extra package? Is this possible to make it useable on Solus?

You are maintaining the budgie-extra package? Is this possible to make it useable on Solus?

So i updated it. Many other distros are on the 1.13 development fork

1.12.9 is the latest stable version.
1.13.x series are marked as Pre-release and Unstable from the developer.

I have updated all of it to 5.1.3, which is the newest version we can use with LLVM 14, and 5.2 doesn't build with it and will probably require LLVM 15.
After the changes I made to rocm-hip and finally managing to build a package depending on it I am confident in the whole stack and I hope it can land once LLVM gets updated to 14, and solbuild gets updated to latest git.

Currently OTPClient is packaged in the Solus repositories.

I already have this locally if Girt accepts

Well it still launches at least ^^
Unfortunately I don't have a NAS to really test the functionality. If some users can confirm to me that the version we have now is no longer functional for its purpose, then yes, I'd remove it from the Third Party Repo and guide user to the flatpak instead.

Please use the correct way for requesting packages https://getsol.us/articles/packaging/request-a-package/en/

@Staudey do suggest deprecating the existing thirdparty software in favour of the flatpak? Does it even still works?

This has already been requested. See T765.

If this is accepted, I would be willing to maintain it if nobody else is.

@DataDrake, could you mention what are the other VPN @JoshStrobl was referring to? The ones I wanted to use to connect Solus and Windows machines are Zerotier and Tailscaile,which are not in the repository. I would be curious in trying the other ones that are readily available in Solus, or at least compare them to try answering Josh's question above to support the request for Tailscale (or Zerotier).

Since this is technically a different piece of software (hence the changed name) and the Third Party Repository is deprecated, to be replaced with flatpak/snap, I guess the best solution is indeed to go for the flatpak.
Also the version of "Synology Cloud Station Drive" in Solus is actually 4.3.3-4469, which is the latest available for that discontinued software (https://www.synology.com/en-global/releaseNote/CloudStationDrive). Not 100% sure where you got that other version number from.

I know it isn't as good as a native package, but there is a flatpak package of the current version of Synology Drive Client. I've been using it without any problems for over a year.

The update was released literally two days ago, and I already pushed it to the Unstable repository a day after that: https://dev.getsol.us/R4442:f8fb77cb39d5b8560c44f9d76c70d060baeb3fc9

Still trying to figure out how to get (and verify) the bitmap fonts working, but I guess I can submit the TTF fonts for now.

Neither do gold or lld afair, ypkg will try to strip that flag out when building with clang. That logic could be extended to strip it if any other linker apart from ld.bfd is used. I do want to get rid of --copy-dt-needed-entries long-term but we'll basically have to rebuild the world to do it.

For future developers working on ypkg, note that mold doesn't yet support --copy-dt-needed-entries: https://github.com/rui314/mold/issues/530

I think waydroid needs wayland, and still depends on ashmem and binder kernel modules. I have tried to build waydroid on my system few months ago and gave up since solus doesn't support dkms. There are discussions on same issues involving anbox which also depends on ashmem and binder, to which joshua was strictly opposed to, with good reasons.

This project is under active development now (with recent releases). The next release of Budgie (10.7) will leverage switcheroo-control to launch applications with the correct GPU profile (though it is not required for Budgie to build or function; it will simply do nothing special if switcheroo-control is not present). I think this would have significant value-add for people with dual-GPU setups, since we can then switch to a dedicated GPU only when needed, helping to improve power usage and battery life.

In my opinion now the build is done, it should already be working with Vega, and is only waiting for LLVM 14 for full GPU support. I have tested it with new LLVM, it builds fine, so should be ready.
Edit: ypkg and solbuild pull requests allowing for renaming of sources need to be accepted too

Duplicate of T9796

I think the same. I had to compile it to use the network scanner.

For instance, how would I indicate that the package is at a different URL than the one provided in the request?

Posting here under request from kyrios to avoid making a duplicate ticket:

This is a request for different software, I just mentioned that previous ticket due to its similarity but lack of identical intent. For instance, how would I indicate that the package is at a different URL than the one provided in the request? It'd feel like hijacking someone else's request for different software.

Task T5376 wasn't rejected due to inactivity, it was rejected because no answer was given about the added value of this project compared to the alternatives that were already available in the repository.
If you think the situation has evolved or if you think the forked version brings some added value compared to the original one and/or to the alternatives that are already in the repo, you can mention it there.
If the project was forked under a different name it would have make sense open a new task for it to ease the search but here name was unchanged so having multiple tasks for the same package request only adds some confusion. Even if there are multiple forks actively maintained, it is better to mention them in the same tasks because if the request is accepted anyhow only 1 of them would go in the repository so it is much easier to have all the info at the same place and not spread across multiple requests !

I don't mind using the bundled llvm if it can be easily switched to if it helps with support.

So after a lot of research it turns out that using system's LLVM is reducing GPU compatibility. My personal APU is not yet supported in LLVM 13 that we are using. It also didn't work on @davidjharder's rx 480, but that is normal, Polaris has only partial support.
So GPUs supported by rocm are desktop Vegas and RDNA 1-2s. Could anyone with such GPU test it? Otherwise I think the package are fully functional, and only maybe rocm-opencl can be split into more packages, but otherwise it should be done.

The original request was for the original Github Desktop available from https://github.com/desktop/desktop , while this request is about Shiftkey's identically named Github Desktop available from https://github.com/shiftkey/desktop . This distinction was made in this request.

Please comment on the original task instead of making duplicates.