The last required package for KaOS has moved to Qt 5, hplip 3.16.5 is now PyQt5/python3 based.

This means Qt 4 can be removed from the repos.

Of course this means all that still depend on Qt 4 and have no port (or no active development anymore) will have to leave the repos too.

Question to all of you, time to remove all these not really maintained packages anymore? Wait another 6 months and keep all these obsolete and complete unmaintained Qt 4 itself (no security fixes from upstream either)?

Packages this involves are the last kdelibs 4 depending: amarok juk k3b k9copy kaffeine

Straight Qt 4 apps: converseen fcitx fcitx-mozc luckybackup freecad clibgrap qucs qgis unetbootin

And from KCP:belle

cgal

nulloy

open365-client

pcloud-drive

psi-plus

qweechat-git

symphytum

whatpulse

yagf

The official support for Qt4 ended December 2015. So from a maintainers point of view, it should be removed.

I would miss K3b the most, as there is currently no alternative known to me. Still, I'm in favor for removing kdelibs4 and Qt4. The future Live ISOs could/should be Qt5-only (no Qt4 and no GTK installed by default). After an announcement of the coming Qt4-removal and a grace period, it should be removed completely from the stable repositories of KaOS. I know it sounds quite harsh, but without it there would be no move forward.

An it is not like the mentioned software will vanish completely. If there is a Qt5-port in the future (still, if it's not ported till now...) I'm sure there could be a way to add it again into the repositories if users request it. And if in spite of this nothing can be done, adding Qt4 to KCP is still an option... though not the best one.

The only software I use is whatpulse every day. I don't lnow if they have a Qt5 port. I am go ask that on they site.

k3b has kf5 branch ->

If you follow KaOS some, you would know k3b kf5 based was in the repos for about one year. It never worked for burning or opening audio CDs, so 3 months ago there was no other option but go back and provide a kdelibs 4 based version. It is still always build on latest commits, but those are very rare now.

Same for Amarok, the kf5 port is always build after the latest commits (none since November last year), unusable.

I don't have CDRom :) I don't use it, i saw in the your list of Qt4 apps.

I would miss K3b the most, as there is currently no alternative known to me. Still, I'm in favor for removing kdelibs4 and Qt4.

I agree with Adurol. Seems, that there is no actively developed and reliable gui for dvd/cd/bd burning with Linux at the moment.

And in general, concerning kdelibs4 and Qt4: What has to be done anyway, should imho be done quickly.

Fine with me if Quassel client starts working again

The only software I use is whatpulse every day. I don't lnow if they have a Qt5 port. I am go ask that on they site.

Seems they are just leaving Linux out....

Both the Windows and OSx client have been ported to Qt5 years ago, examples:

Does that mean I can't use whatpulse anymore?

Does that mean I can't use whatpulse anymore?

This means Qt 4 will leave the repos. What happens to your install is up to you.

QGis is no longer on the removal list, a Qt 5 version has entered the build repo (not fully functional yet). It is build from the latest git master checkout, seems upstream not fully done with the PyQt4 to PyQt5 move since they only ship a PyQt4 API, thus PyQt bindings are disabled for now in this build.

a month later
demm stickied the discussion .
12 days later

What is going to be done about Konqueror?
I would not bother you but somebody, somewhere has to pick up the ball for Konqueror and maybe you know how that is going to happen.

KDE without Konqueror is just AYA DE.
Dolphin as the so-called default file manager(FM) has never fit the bill. ...and besides it is just a FM, not nearly as useful as Konqueror.

[...]
BTW, in VirtualBox (5.20 on Win 81) the KaOS VM Konqueror is broken - sidebars will not display with any items. While I am certain Konqueror must have been broken in the past I cannot recall anytime in the last 15 years that I experienced it on hardware or VM. ...maybe in the KDE 1.x and early 2.x days ( cuz I did not use the memory hogging KDE during that 'phase' of insanity, 😉 )?
...anyway just saying that KDE's Konqueror previous(current) maintainer has been looking for somebody to take the reins for a couple of years now and if nobody can / will do it, am wasting time with (K)DE/plasma 5 and :. KaOS, no matter how GREAT( really! :applause: ) the KaOS dev's work is for it.

Konqueror has been kf5 based in KaOS for almost 2 years already (part of frameworks branch build of kde-baseapps), so the Qt 4 removal has zero effect on it.

Thank you. 🙂
I interpreted "(or no active development anymore)" independently of "depend on QT4" and was concerned KaOS might remove it.

Am still concerned about the lack of development and that display issue but I'll soon try KaOS w/ "real" graphics hardware/driver and maybe display bug will go away.
Don't know W2D about lack of Konqueror development. Did somebody take over active development and maintenance? I never saw(or could find) an answer to request at https://blogs.kde.org/2014/08/16/konqueror-looking-maintainer ...

  • demm replied to this.

    neognomic
    Everything is listed in the first post what is effected by Qt 4 removal. Konqueror is not there 🙂
    Also, KaOS has had the policy for well over 2 years to move everything possible to Qt 5, meaning many will use git builds if the "stable" release is still Qt 4 based.
    kde-baseapps is such an example, virtually no maintenance or fixes in the "stable" Qt 4 based master branch, lots of activity in the frameworks branch, including quite a lot of commits for konqueror. Not clear if that one actually has a maintainer though.