Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
On Thu, Jan 02, 2025 at 07:56:03PM +, Sam James wrote: > Zoltan Puskas writes: > > >> > >> So, removing Qt5 will break computers of many users, including my computer. > >> In the course of many years of existence of Qt5 a large number of useful > >> programs have been created; not all of them have been ported to Qt6. Are we > >> going to throw away all this wealth? > >> > > > > I have to agree with Andrey here, the list contains quite a few items that > > are > > likely used by a lot of users and killing all these apps is going to be > > painful. > > > > Is there a timeline for killing QT5 completely or will just QT5 be stuck at > > the > > current version and patch level? > > > > I understand that QT5 is considered deprecated, but doesn't KDE project > > still > > maintain QT 5.15 for the time being? Can't we just keep that version? > > > > Even if we report bugs upstream, it may take time to port all these > > projects, > > especially the larger ones or if they are a single person project. > > We best get started now then, which is the purpose of Andreas' > email. This is the warning to start filing those bugs and asking > upstreams to port if not done already. Not that we're going to last-rite > such packages tomorrow. Right, albeit can add that anything depending on qtwebengine:5 should hurry more than the rest. As asturm already noted it's going to break faster than the rest and nobody really wants to handle keeping that one working. Most users also don't want two qtwebengine on their systems. Qt5 base packages aren't the biggest worry even if we leave them semi-abandoned (not that qtcore isn't pretty quirky and already with a lot of small issues that will likely get worse), albeit it'd be nice to get to a few other Qt modules out of the equation as packages ideally get aggressively ported. -- ionen signature.asc Description: PGP signature
[gentoo-dev] Last rites: sci-mathematics/lean:0/3 and sci-mathematics/mathlib-tools
profiles/package.mask: mask lean 3 and mathlib-tools # Maciej Barć (2025-01-02) # Deprecated LEAN 3 packages. The "mathlib-tools" repo is archived # (https://github.com/leanprover-community/mathlib-tools). Migrate to LEAN 4. # Removal on 2025-02-02 sci-mathematics/lean:0/3 sci-mathematics/mathlib-tools -- Have a great day! ~ Maciej Barć https://wiki.gentoo.org/wiki/User:Xgqt 9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C OpenPGP_0x14D74A1F43A6AC3C.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-servers/xsp
profiles/package.mask: mask www-servers/xsp # Maciej Barć (2025-01-02) # Upstream dead, repo archived (https://github.com/mono/xsp). Uses deprecated # "dotnet" eclass. Depends on old mono. As a replacement one can use official # .NET 6.0-9.0 ASP.NET instead. # Removal on 2025-02-02 acct-group/aspnet acct-user/aspnet www-servers/xsp -- Have a great day! ~ Maciej Barć https://wiki.gentoo.org/wiki/User:Xgqt 9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C OpenPGP_0x14D74A1F43A6AC3C.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
Zoltan Puskas writes: >> >> So, removing Qt5 will break computers of many users, including my computer. >> In the course of many years of existence of Qt5 a large number of useful >> programs have been created; not all of them have been ported to Qt6. Are we >> going to throw away all this wealth? >> > > I have to agree with Andrey here, the list contains quite a few items that are > likely used by a lot of users and killing all these apps is going to be > painful. > > Is there a timeline for killing QT5 completely or will just QT5 be stuck at > the > current version and patch level? > > I understand that QT5 is considered deprecated, but doesn't KDE project still > maintain QT 5.15 for the time being? Can't we just keep that version? > > Even if we report bugs upstream, it may take time to port all these projects, > especially the larger ones or if they are a single person project. We best get started now then, which is the purpose of Andreas' email. This is the warning to start filing those bugs and asking upstreams to port if not done already. Not that we're going to last-rite such packages tomorrow.
[gentoo-dev] Last-rites: dev-libs/libqt5pas
# Andreas Sturmlechner (2024-01-02) # No more revdeps, depends on Qt5. Removal on 2025-01-29. dev-libs/libqt5pas signature.asc Description: This is a digitally signed message part.
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
Andrey Grozin writes: > Here are some packages installed on my computer and (to various > degrees) important for me which depend on Qt5 > I'll note again that at the moment, we're talking about "things which support Qt 6, but the ebuild doesn't even acknowledge that right now, or the ebuild still unnecessarily supports Qt 5."
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
On 1/2/25 1:36 AM, Andrey Grozin wrote: > Here are some packages installed on my computer and (to various degrees) > important for me which depend on Qt5 > > 1. x11-wm/lumina > An excellent desktop environment. I use it for many years. > I contacted the upstream about the possibility to port it to Qt6. They > said that before that they have to port it from qmake to cmake (work > underway), then they will consider the possibility of the Qt6 port. > > 2. media-sound/qmmp > An excellent misic player. The site says there is qmmp2 based on Qt6, > but I don't see in in Gentoo. Indeed, that is why if you visit https://packages.gentoo.org and search for this package, there is a big infobox: " Version 2.2.2 is available upstream. Please consider updating!" So... do that? I bet the sound@ project would love your help here. > 3. media-video/vlc > An excellent video played. Its GUI is Qt5 based. Supports Qt 6 in upstream git, not yet enabled in live ebuild. I bet the media-video@ project would love your help here. > 4. app-text/master-pdf-editor > The only tool for editing pdf files. I have to use it every time I check > and correct proofs of my papers, i.e., rather often. There is no > replacement. Proprietary software that ships with a bundled Qt5. There is a strong rationale for debundling if possible, but in the event that Qt5 is dropped from ::gentoo you can always respond to that action by switching to the bundled Qt. You are not beholden to the qt@ team's support policy here. > 5. sci-visualization/gle > A very useful tool, its gui is Qt5 based. I use it practically every > day, it is essential for my main work. But I use the command-line tool; > personally for me, GUI is not important. Porting is rumored to be not hard. Try poking upstream about it: https://github.com/vlabella/GLE/issues/13 > 6. app-text/doxygen > GUI is Qt5 based. Personally I don't use the GUI. Supports Qt 6 since 2022, not enabled in the ebuild. I trust that you will agree with my analysis if I say that packages such as doxygen are ***the*** reason why Andreas is sending out email warnings asking for people to migrate immediately. > 7. sci-geosciences/qmapshack > The best tool to support large collections of gpx tracks. There is a > partially working Qt6 port: translations and the help system are broken > in it. Personally I can live without translations and the help system. > But stabilizing this version is out of question. > > So, removing Qt5 will break computers of many users, including my > computer. In the course of many years of existence of Qt5 a large number > of useful programs have been created; not all of them have been ported > to Qt6. Are we going to throw away all this wealth? Obviously nobody is proposing to throw away this wealth. For example, the qt@ team will continue to maintain Qt 6, but you can take over maintenance of Qt 5 for the sake of existing useful programs, and given that the Qt 5 packages will then have a maintainer, there is no reason to delete them. But assuming neither you nor anyone else concerned about Qt5 volunteers to personally maintain it, I don't comprehend what your objection is. Andreas has explicitly, loudly, expressed an unwillingness to continue devoting time and energy on Qt 5. Correspondingly, he has: - issued a warning to that effect - advised doing whatever you can to see packages start using Qt 6 - pointed out several potential reasons that may make Qt 5 fail to compile over the next year or so What you do with that information is entirely up to you, but objecting that Andreas is not permitted to determine the best use of his time is not a valid option. Andreas will not maintain Qt 5 due to personal choice, and the Treecleaner project will remove packages that are unable to be compiled and installed if nobody fixes them. Do not blame Andreas for the actions of the Treecleaner project. This is all especially weird since *most* of the packages you mention are examples of why this email was necessary and the packages in ::gentoo do need fixing or updating to enable the existing support for Qt 6. And *all but one* of the packages have upstreams that are active and interested in supporting Qt 6 if they don't already, with the exception of the single proprietary package that ships its own Qt for your convenience. I do not see why you are sending a worried reply indicating you think the situation is hopeless. Based on your list, the situation is the very opposite of hopeless. And your list is just a bunch of action points that you, yourself, can work on *today* in order to make things better. Why all the doom and gloom? -- Eli Schwartz OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] toolchain.eclass: Don't prefixify dynamic linker for cross-compilers
James Le Cuirot writes:
> Cross environments within a prefixed system do not have a nested prefix,
> i.e. they are located at ${EPREFIX}/usr/${CHOST}, not
> ${EPREFIX}/usr/${CHOST}/${EPREFIX}. Binaries built with the
> cross-compiler should therefore get an unprefixed dynamic linker path by
> default so that they work out of the box with QEMU's -L option.
Remember to CC eclass maintainers.
Looks good.
>
> Signed-off-by: James Le Cuirot
> ---
> eclass/toolchain.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index c605c437f355a..f5d3b83c2e03b 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -716,7 +716,7 @@ toolchain_src_prepare() {
>
> gnuconfig_update
>
> - if ! use prefix-guest && [[ -n ${EPREFIX} ]] ; then
> + if ! is_crosscompile && ! use prefix-guest && [[ -n ${EPREFIX} ]] ; then
> einfo "Prefixifying dynamic linkers..."
> for f in gcc/config/*/*linux*.h ; do
> ebegin " Updating ${f}"
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
On Thu, 2025-01-02 at 03:13 -0800, Zoltan Puskas wrote: > > > > So, removing Qt5 will break computers of many users, including my computer. > > In the course of many years of existence of Qt5 a large number of useful > > programs have been created; not all of them have been ported to Qt6. Are we > > going to throw away all this wealth? > > > > I have to agree with Andrey here, the list contains quite a few items that are > likely used by a lot of users and killing all these apps is going to be > painful. There may be some confusion here. The list includes packages like www-client/vivaldi, which already support both versions. It is also sometimes possible to simply rebuild against Qt6 with no changes but not always. signature.asc Description: This is a digitally signed message part
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
02.01.2025 11:22, James Le Cuirot пишет: > On Thu, 2025-01-02 at 03:13 -0800, Zoltan Puskas wrote: >>> So, removing Qt5 will break computers of many users, including my computer. >>> In the course of many years of existence of Qt5 a large number of useful >>> programs have been created; not all of them have been ported to Qt6. Are we >>> going to throw away all this wealth? >>> >> I have to agree with Andrey here, the list contains quite a few items that >> are >> likely used by a lot of users and killing all these apps is going to be >> painful. > There may be some confusion here. The list includes packages like > www-client/vivaldi, which already support both versions. It is also sometimes > possible to simply rebuild against Qt6 with no changes but not always. Yeah, to make this generated list more useful, would need to filter out lines with suffix like `:!qt6`, or something like that.
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
Am 02.01.25 um 12:13 schrieb Zoltan Puskas: So, removing Qt5 will break computers of many users, including my computer. In the course of many years of existence of Qt5 a large number of useful programs have been created; not all of them have been ported to Qt6. Are we going to throw away all this wealth? Is there a timeline for killing QT5 completely or will just QT5 be stuck at the current version and patch level? That's what I thought first, too. And I think that is the question which has to be answered before making a decision. As long as someone, who could be referred to as upstream, patches QT5, I would personally be fine with using QT5. But once that support drops, we are talking about an unsupported big piece of software which you don't want to have on your computer. I searched the web and found a blog entry [1] talking about extended commercial(!) support ending mid 2025. But I don't know QT enough to qualify this information. regards Daniel [1] https://www.qt.io/blog/qt-5.15-extended-support-for-subscription-license-holders
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
> On Wed, 01 Jan 2025, Andreas Sturmlechner wrote: > If you recognise your package(s) in there, please drop Qt5 in favor of Qt6 > aggressively. If there is no Qt6-based upstream release yet, bug upstream > about it. They may not even know yet this is important. Can you provide a pointer to a Qt upstream page saying that Qt 5 is deprecated? Just for the case that the upstreams of my packages need further convincing. Ulrich signature.asc Description: PGP signature
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
> > So, removing Qt5 will break computers of many users, including my computer. > In the course of many years of existence of Qt5 a large number of useful > programs have been created; not all of them have been ported to Qt6. Are we > going to throw away all this wealth? > I have to agree with Andrey here, the list contains quite a few items that are likely used by a lot of users and killing all these apps is going to be painful. Is there a timeline for killing QT5 completely or will just QT5 be stuck at the current version and patch level? I understand that QT5 is considered deprecated, but doesn't KDE project still maintain QT 5.15 for the time being? Can't we just keep that version? Even if we report bugs upstream, it may take time to port all these projects, especially the larger ones or if they are a single person project. Additionally there are some projects where the community's influence is limited, eg. Virtualbox which is controlled by Oracle. Looking through the list: app-office/kmymoney: I've been using this for accounting for more than a decade now, and I'm not sure if there are any worthy alternatives to it to be honest, nor do I want to go through a painful migration to some inferior accounting program. It's important enough for me that I would consider switching distros if I lost this, which would also mean I would end my involvement with Gentoo (i.e. retire from all my proxy maintained packages) as a result. Additional items on top of Andrey's list, that I'm familiar with (a lot of these I use personally too): app-backup/bacula: Fancy backup tool, while I don't use it personally, I know many prefer it. Breaking it would break an important data workflow for people, and while there are alternative backup solutions migrating is likely painful for someone with extensive backups. app-crypt/nitrokey-app: Isn't Nitrokey used officially by Gentoo devs?[1] I'm not sure it's a good idea to loos this. app-crypt/yubikey-manager-qt: I don't think there is an alternative UI for managing Yubikeys. I don't use it any more as I switched to the CLI tool, but again for users getting into hardware based 2-fac this is an invaluable tool. app-editors/okteta: I like this hex editor, it's one of the best available under Linux. Would be a great loss IMHO, and while I could swicth to hexedit or some similar tool, it would not be the same. app-emulation/virtualbox: Popular VM tool, I use this too. I'm aware for QEMU but some things just work better with Virtualbox. app-i18n/fcitx-qt: Anyone using Chinese/Japanese/Korean/etc. will be pissed if this is gone. app-office/scribus: Great software, I've used it to create posters for conferences and what not. Again, not sure if there are any reasonable alternatives for this. dev-db/sqlitebrowser and dev-db/sqlitestudio: I've used it in the past, not essential for my workflow, but I can see why people like these. dev-embedded/ponyprog: Convenient piece of software to use with microcontrollers, EEPROMS, etc. Again no real alternatives with such a wide programming capability. I don't frequently need to program HW, but when I do I prefer this. kde-apps/marble: Awseome desktop globe and mapping program. I prefer this to using OpenStreetMap in the browser. No alternative AFAIK. media-gfx/krita: Great drawing program for artists, manga, etc. Not sure if there is a equal quality alternative for it. I don't use it though. media-gfx/luminance-hdr: HDR photo creation tool. Not sure if there are alternatives for this. sci-electronics/pulseview: Great for interfacing with logic analyzers (and more), works with my Saleae (both OEM and clone) nicely, but there are no alternatives for this really. I'm sure there are other unique pieces of software, which if lost will significantly reduce the usefulness and usability of Gentoo as a desktop OS and will push users away. Cheers, Zoltan [1] https://wiki.gentoo.org/wiki/Project:Infrastructure/Nitrokey_Pro_2_guide_for_Gentoo_developers
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
On Thu, Jan 02, 2025 at 06:36:32AM +, Andrey Grozin wrote: > Here are some packages installed on my computer and (to various degrees) > important for me which depend on Qt5 > > 4. app-text/master-pdf-editor > The only tool for editing pdf files. I have to use it every time I check and > correct proofs of my papers, i.e., rather often. There is no replacement. Have you tried out app-text/xournalpp yet? It allows you to annotate PDFs, add text and images and export the resulting xopp file back to PDF. I use it at university to write proofs and to proofread my friends' essays. -- Lucio Sauer
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
La 02.01.2025 13:13, Zoltan Puskas a scris: Additionally there are some projects where the community's influence is limited, eg. Virtualbox which is controlled by Oracle. VirtualBox 7.1 switched to QT6. It is not yet stable, but it will be soon. sci-electronics/pulseview: Great for interfacing with logic analyzers (and more), works with my Saleae (both OEM and clone) nicely, but there are no alternatives for this really. I don't use this one, but from what I've seen on their git it might support QT6. I can look into it. Regards, Viorel OpenPGP_0x67992BD27934AEA4.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] toolchain.eclass: Don't prefixify dynamic linker for cross-compilers
Cross environments within a prefixed system do not have a nested prefix,
i.e. they are located at ${EPREFIX}/usr/${CHOST}, not
${EPREFIX}/usr/${CHOST}/${EPREFIX}. Binaries built with the
cross-compiler should therefore get an unprefixed dynamic linker path by
default so that they work out of the box with QEMU's -L option.
Signed-off-by: James Le Cuirot
---
eclass/toolchain.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index c605c437f355a..f5d3b83c2e03b 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -716,7 +716,7 @@ toolchain_src_prepare() {
gnuconfig_update
- if ! use prefix-guest && [[ -n ${EPREFIX} ]] ; then
+ if ! is_crosscompile && ! use prefix-guest && [[ -n ${EPREFIX} ]] ; then
einfo "Prefixifying dynamic linkers..."
for f in gcc/config/*/*linux*.h ; do
ebegin " Updating ${f}"
--
2.47.1
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
On Donnerstag, 2. Jänner 2025 12:13:22 Mitteleuropäische Normalzeit Zoltan Puskas wrote: > > So, removing Qt5 will break computers of many users, including my > > computer. > > [...] > > I have to agree with Andrey here, the list contains quite a few items [...] My message did not seek to getting everyone prematurely mourn the loss of their favorite packages. Many of those listed already have Qt6 porting work in progress but aren't quite there yet. Those will be safe. However, it should be absolutely clear that we cannot wait with preparations until the moment that Qt5 actually breaks. At that point our cleanup effort will be much more driven by dependency pressure lower down the stack. signature.asc Description: This is a digitally signed message part.
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
On Donnerstag, 2. Jänner 2025 12:29:01 Mitteleuropäische Normalzeit Alexey Sokolov wrote: > 02.01.2025 11:22, James Le Cuirot пишет: > > On Thu, 2025-01-02 at 03:13 -0800, Zoltan Puskas wrote: > > There may be some confusion here. The list includes packages like > > www-client/vivaldi, which already support both versions. It is also > > sometimes possible to simply rebuild against Qt6 with no changes but not > > always. > Yeah, to make this generated list more useful, would need to filter out > lines with suffix like `:!qt6`, or something like that. Where there is support for both right now, "drop support for Qt5 wherever possible" applies the cleanest. So the list is fine either way and will show us a clearer picture where the hold-ups are the more we sanitise those packages. signature.asc Description: This is a digitally signed message part.
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
On Donnerstag, 2. Jänner 2025 12:29:01 Mitteleuropäische Normalzeit Alexey Sokolov wrote: > 02.01.2025 11:22, James Le Cuirot пишет: > > On Thu, 2025-01-02 at 03:13 -0800, Zoltan Puskas wrote: > > There may be some confusion here. The list includes packages like > > www-client/vivaldi, which already support both versions. It is also > > sometimes possible to simply rebuild against Qt6 with no changes but not > > always. > Yeah, to make this generated list more useful, would need to filter out > lines with suffix like `:!qt6`, or something like that. Where there is support for both right now, "drop support for Qt5 wherever possible" applies the cleanest. So the list is fine either way and will show us a clearer picture where the hold-ups are the more we sanitise those packages. signature.asc Description: This is a digitally signed message part.
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
250102 James Le Cuirot wrote: > There may be some confusion here. The list includes packages > like www-client/vivaldi, which already support both versions. > It is also sometimes possible to simply rebuild against Qt6 > with no changes but not always. When I updated to KDE 6 , I reluctantly had to drop Krusader, but this thread prompted me to check its current status & version 2.9.0 for KDE 6 is available in Testing. I've installed it successfully & am looking forward to using it regularly. What seems to be needed is a list of packages which are (1) really important to some users & (2) show no signs of being updated to KDE 6 in the foreseeable future. Then some lobbying cb done to get that special problem solved. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatcadotinterdotnet
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
On Donnerstag, 2. Januar 2025 20:03:29 Mitteleuropäische Normalzeit Philip Webb wrote: > When I updated to KDE 6 , I reluctantly had to drop Krusader When you updated to *Plasma 6*, nothing forced you to do that at all. signature.asc Description: This is a digitally signed message part.
Re: Fwd: [gentoo-dev] Please actively drop support for Qt5 wherever possible
On Donnerstag, 2. Jänner 2025 12:37:47 Mitteleuropäische Normalzeit Ulrich Müller wrote: > Can you provide a pointer to a Qt upstream page saying that Qt 5 is > deprecated? Just for the case that the upstreams of my packages need > further convincing. Not sure I can, without accompanying explanations: https://www.qt.io/blog/qt-offering-changes-2020 Qt5 upstream (Qt Company) OSS support ended on 2020-12-08. Since then, bugs are only fixed if reproduced in Qt6 first, then backported. Since then, public availability of commercial 5.15 LTS releases is delayed by 1 year, including repository access for cherry-picking - this is important, see below, and affects Gentoo first and foremost. The last official LTS release will be this April/May: https://www.qt.io/blog/qt-5.15-extended-support-for-subscription-license-holders https://wiki.qt.io/Qt_5.15_Release#Release_Plan Public availability of this release will be *1 year later*. Some may think now, fine, updates (3 in total) until 2026! However, if a dependency/toolchain upgrade down the stack breaks Qt5 between now and March/April, to be then fixed in their final release, you will be waiting until April/May 2026 for that to be available. If it breaks later than April 2025, you will be waiting forever. In either case, you rely on downstream volunteer patchwork. KDE Qt5PatchCollection ultimately relies on Qt company's upstream commits as well, so don't expect any original work from there to get things fixed. In any case, there is no clear EOL date for these patches, but they *will* be drying up as there is no main KDE consumer left, I certainly know that my contributions come to an end. https://community.kde.org/ Qt5PatchCollection#For_how_long_will_this_be_maintained? Gentoo Qt Policy page: https://wiki.gentoo.org/index.php?title=Project:Qt/ Policies#Handling_different_versions_of_Qt Gentoo Qt migration notes: https://wiki.gentoo.org/wiki/Project:Qt/Qt6_migration_notes signature.asc Description: This is a digitally signed message part.
