Andreas Sturmlechner
Andreas Sturmlechner
> sounds like redhat et al already removed qt5, so sooner is better than later. Gentoo is trying hard to remove qt5, I expect they may succeed before the end...
### Qt5 is now declared deprecated in Gentoo At this point in time, Linux distributions are already tracking which packages are blocking Qt5 cleanup. Real Qt Company OSS support stopped...
Please note the following changes I just made in 1.3.5-r1: ```diff --- aseprite-1.3.5.ebuild 2024-12-29 19:23:17.518044041 +0100 +++ aseprite-1.3.5-r1.ebuild 2024-12-31 20:16:49.554094915 +0100 @@ -4,7 +4,6 @@ EAPI=8 PYTHON_COMPAT=( python3_{10..12} ) -...
How do you upstream this, if it is no patch? :)
We shouldn't drop best practice just because something isn't likely to get upstreamed. It helps the next person randomly looking at your ebuild for how to do things, $other-distro person...
I don't see a blocker, honestly. Porting to Qt6 does not impede your wish to implement a new logger. Certainly, these split up commits would enable you to cherry-pick easily...
@hartwork ^
Please note that in the meantime at least Gentoo and Ubuntu are running Qt5 removal trackers. So getting this done gets more important.
Do we need to be careful with some Portage peculiarities since a config protected file is changing ownership?
> We've decided no news item then? Not decided yet.