Holding this back until after the GNOME Stack upgrade since this'll need to be rebased and rebuilt anyways.

Abandoning. Is failing to apply currently, relnum was bumped from 23 to 25, etc. Going to get this updated locally and have it start using GNOME 3.32 stack. Sorry.

@kyrios123 If you want to push the rebuild directly to the build server I can get it cherry-picked onto stable.

Re-opening. Further action necessary to resolve various Qt5 apps can be addressed here. (@kyrios123)

Why was a new issue created for this.

Abandoning this. I'm doing the GNOME stack upgrade locally, this is either not relevant or should be tested after. Leave the GNOME stuff to me, as usual.

This issue has been deemed by the developers to be an issue related to Budgie, our primary desktop environment. As Budgie is a distro-agnostic project, developed by Solus but leveraged by other operating systems and projects, we maintain a dedicated issue tracker for it. This issue tracker can be found at https://github.com/solus-project/budgie-desktop

This is already a known issue

Any others?

I'm not really sure why people are concerned with them being Python or not. As stated by @kyrios123, budgie-desktop does not accept PRs for python-based applets. That does not mean third-party applets cannot be.

This is a known issue with Discord itself. See https://support.discordapp.com/hc/en-us/community/posts/360039152191-Linux-Update

I'm going to mark this as resolved since I have it updated locally. I've been performing the stack upgrade locally and it'll be pushed either Sunday or Monday, so it'll be resolved on a sync that'll happen on 3rd of May:

This is going to be permanently rejected. It requires libhandy, which is not only a library with a currently unstable API/ABI, but entirely oriented towards mobile UX. I find it entirely unacceptable to start requiring mobile UX libraries for desktop applications, or applications which in our case will only be used in a laptop / desktop environment.

This isn't going to land. It requires libhandy, which is not only a library with a currently unstable API/ABI, but entirely oriented towards mobile UX. I find it entirely unacceptable to start requiring mobile UX libraries for desktop applications, or applications which in our case will only be used in a laptop / desktop environment.

For that, I'd probably have gsettings-desktop-schemas as a rundep of libgtk-3 instead. That'll filter up to basically every GTK3 app, including Lutris. I'll get it done for the GNOME 3.32 stack upgrade since I had to update GTK3 for that anyways.

It's a GNOME app, I'm not sure why you'd want to arbitrarily remove these sorts of packages from your system...

Yea it's a sad frustrating that the d3d9 patches haven't been updated yet, but I appreciate the fact we've been able to use them for as long as we have. I think we need to look into the best way of supporting both wine proper and any active d3d9 / gallium nine-based wine forks, or alternatively do away with the concept of officially supported D3D9-based WINEs. Most of that aspect of the ecosystem is moving to DXVK+Proton, which I intend on officially supporting on the future, and there has been progress of having D39 support in DXVK to just translate those calls to Vulkan.

Currently this task is more of a holder, until an official stable version comes out, but feel free to check it out (things are currently working great for me).

Re-validated and it does appear that FFMPEG VAAPI support is correctly being enabled. Here's my OBS Studio with it being an encoder option:

Do you agree with this ?

The repo in question is not maintained, what you should actually be looking at is https://github.com/NicoHood/arc-theme

The above items have been deprecated from the unstable repository. I will be creating a countdown for python2 as a whole once I've sat down with @DataDrake and determined a date for it. I prefer for it to not be the 11th hour of December 31th, and no later than it.

Action Plan:

Started this last Saturday, further work yesterday. More in the morning. Hoping on landing it on Sunday or Monday in unstable, deferring next week's Friday sync to following week.

I will be removing bitmessage and puddletag from the unstable repository tomorrow, and from stable on Friday. puddletag hasn't seen a release since 2016 and does not appear to be actively moving to Qt5 or Python3, despite their dedicated branch for it (which sees sporadic activity). BitMessage also does not have regular releases and isn't making headway towards Python3 support.

I'll test it when it lands in the repo since I own some yubikeys.

So much nope. Stateless patch needs to be updated and functionality restored.