[arch-dev-public] Dropping KDE4 libs
I think it's time to drop the KDE4 libraries. They were EOL months ago and most stuff that isn't yet ported to KF5 is dead upstream. This would allow dropping a number of qt4 libraries and reduce the qt4 reverse dependencies (qt4 has been EOL for 3 years now). Affected packages are: - recorditnow (there are many alternatives available) - ligthdm-kde-greeter (dead upstream, no signs of KF5 porting) - krecipes (dead upstream, no signs of KF5 porting) - kdiff3 (has been ported to KF5 for a while, just needs a release. Could be updated to a snapshot) - pidgin-kwallet (uses kwallet dbus API, so should work with the KF5 version without any modification) - libreoffice-still (would lose the KDE4 VCL, which is quite buggy anyway. LO-fresh has a new VCL that uses KF5 file dialog) - amarok: it has a WIP KF5 port, but it's not quite ready and development is stalled. IMO we should let it rest in peace - I can keep a KF5 snapshot in kde-unstable for a while but it doesn't look like it's going anywhere any time soon at the current development pace. There are a few alternatives in the repos. Comments?
Le 17/08/2018 à 20:53, Antonio Rojas via arch-dev-public a écrit :
I think it's time to drop the KDE4 libraries. They were EOL months ago and most stuff that isn't yet ported to KF5 is dead upstream. This would allow dropping a number of qt4 libraries and reduce the qt4 reverse dependencies (qt4 has been EOL for 3 years now). Affected packages are: - recorditnow (there are many alternatives available) - ligthdm-kde-greeter (dead upstream, no signs of KF5 porting) - krecipes (dead upstream, no signs of KF5 porting) - kdiff3 (has been ported to KF5 for a while, just needs a release. Could be updated to a snapshot) - pidgin-kwallet (uses kwallet dbus API, so should work with the KF5 version without any modification) - libreoffice-still (would lose the KDE4 VCL, which is quite buggy anyway. LO-fresh has a new VCL that uses KF5 file dialog) - amarok: it has a WIP KF5 port, but it's not quite ready and development is stalled. IMO we should let it rest in peace - I can keep a KF5 snapshot in kde-unstable for a while but it doesn't look like it's going anywhere any time soon at the current development pace. There are a few alternatives in the repos.
Comments?
Well, I think all of those can go away. Amarok has seen so few activity over the past years that I would also consider it dead. Plus it’s quite an huge app, so porting is a lot of work, which will never happen at the current pace for sure. And KDE has been developing a new music player to replace it as the default KDE experience music player. ;) Bruno
And gone. After the KDE4 and PyQt4 removal, 'pactree -sru qt4 | wc -l' went down from 78 to 44. The full list is below: if any of your packages is in there, please check whether it can be dropped, ported to use Qt5 or some other toolkit. We should aim at dropping Qt4 as soon as possible, it has been EOL for 3 years already. $ pactree -sru qt4 | sort ams appmenu-qt4 chinese-calendar clementine fbreader fcitx-qt4 freemat gambas3-gb-qt4 gambas3-gb-qt4-ext gebabbel gnuradio-companion hydrogen ibus-qt keepassx keepassx2 launchy libdbusmenu-qt4 libechonest liblastfm-qt4 liblightdm-qt4 libmygpo-qt4 licq lmms mixxx mumble murmur openssh-askpass projectm-jack projectm-pulseaudio projectm-qt qjson qmpdclient qt4 qt-assistant-compat qtcurve-qt4 qtiplot qwt5 qwtplot3d scribus sni-qt tipp10 tuxcards v4l2ucp x2goclient
Le 24/08/2018 à 11:10, Antonio Rojas via arch-dev-public a écrit :
fcitx-qt4 ibus-qt
The first one will be useless once Qt4 apps are gone, the second one can be rebuild without Qt4 support when that happens too.
keepassx keepassx2
I think both should be dropped as replaced by keepassxc. Upstream is quite dead (well keepassx is even the old 0.4.x branch, so definitively dead), if you really want to keep keepassx2 then the master branch has Qt5 support.
scribus
The develop branch (1.5.x), available as scribus-devel in the AUR (and maintained by myself), is Qt5. It has been in development for the past 3 years already, and still no ETA AFAIK… I’ve been using it instead of scribus from repo for the past 2 years with no issue, but my use case is limited w.r.t. all the possibilities this software offers. Last time I asked about even packaging the -devel version in [community], fellow TUs were not fond of the idea. So about replacing the repo version with it… Bruno
[2018-08-24 11:51:30 +0200] Bruno Pagani via arch-dev-public:
scribus
The develop branch (1.5.x), available as scribus-devel in the AUR (and maintained by myself), is Qt5. It has been in development for the past 3 years already, and still no ETA AFAIK… I’ve been using it instead of scribus from repo for the past 2 years with no issue, but my use case is limited w.r.t. all the possibilities this software offers. Last time I asked about even packaging the -devel version in [community], fellow TUs were not fond of the idea. So about replacing the repo version with it…
Great idea. I have no objection and can get to it as soon as I'm back from holidays. Or if you're happy to maintain scribus in [community] yourself please do push a suitably-tested development snapshot and I'll transfer ownership of the package to you. Cheers. -- Gaetan
Le 24/08/2018 à 18:38, Gaetan Bisson via arch-dev-public a écrit :
scribus The develop branch (1.5.x), available as scribus-devel in the AUR (and maintained by myself), is Qt5. It has been in development for the past 3 years already, and still no ETA AFAIK… I’ve been using it instead of scribus from repo for the past 2 years with no issue, but my use case is limited w.r.t. all the possibilities this software offers. Last time I asked about even packaging the -devel version in [community], fellow TUs were not fond of the idea. So about replacing the repo version with it… Great idea. I have no objection and can get to it as soon as I'm back from holidays. Or if you're happy to maintain scribus in [community] yourself please do push a suitably-tested development snapshot and I'll
[2018-08-24 11:51:30 +0200] Bruno Pagani via arch-dev-public: transfer ownership of the package to you.
Cheers.
I have a ready PKGBUILD (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=scribus-devel) that I can push (after changing the pkgname) if scribus is moved to [community]. And we can co-maintain it there, co-maintaining is the new sexy. ;) I can build into [community-testing] first so that people can check they don’t have issue with it (I don’t, but once again I only work on a small project, so I did not test everything). Regards, Bruno
[2018-08-24 18:45:33 +0200] Bruno Pagani:
I have a ready PKGBUILD (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=scribus-devel) that I can push (after changing the pkgname) if scribus is moved to [community]. And we can co-maintain it there, co-maintaining is the new sexy. ;)
It's already in [community]. :)
I can build into [community-testing] first so that people can check they don’t have issue with it (I don’t, but once again I only work on a small project, so I did not test everything).
Sounds good to me! Feel free to go ahead with your proposed changes. Cheers. -- Gaetan
Le 25/08/2018 à 01:31, Gaetan Bisson a écrit :
[2018-08-24 18:45:33 +0200] Bruno Pagani:
I have a ready PKGBUILD (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=scribus-devel) that I can push (after changing the pkgname) if scribus is moved to [community]. And we can co-maintain it there, co-maintaining is the new sexy. ;) It's already in [community]. :)
I can build into [community-testing] first so that people can check they don’t have issue with it (I don’t, but once again I only work on a small project, so I did not test everything). Sounds good to me! Feel free to go ahead with your proposed changes.
Cheers.
Just a small heads up, scribus 1.5.4 has been in testing for the past 10 days. ;) Not sure if we want to wait for signoffs or anything before moving. Regards, Bruno
[2018-09-04 14:46:15 +0200] Bruno Pagani:
Le 25/08/2018 à 01:31, Gaetan Bisson a écrit :
[2018-08-24 18:45:33 +0200] Bruno Pagani:
I have a ready PKGBUILD (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=scribus-devel) that I can push (after changing the pkgname) if scribus is moved to [community]. And we can co-maintain it there, co-maintaining is the new sexy. ;) It's already in [community]. :)
I can build into [community-testing] first so that people can check they don’t have issue with it (I don’t, but once again I only work on a small project, so I did not test everything). Sounds good to me! Feel free to go ahead with your proposed changes.
Cheers.
Just a small heads up, scribus 1.5.4 has been in testing for the past 10 days. ;) Not sure if we want to wait for signoffs or anything before moving.
I don't believe many people sign off on packages not headed to [core]. Definitely feel free to move scribus to [community]. Cheers. -- Gaetan
On Tue, Sep 04, 2018 at 07:04:56AM -1000, Gaetan Bisson via arch-dev-public
I don't believe many people sign off on packages not headed to [core]. Definitely feel free to move scribus to [community].
So far I've told our tester that they don't have to because we don't really look at them. Maybe we should reconsider or, if we only want them to test some specific packages, we should probably ask them either here or in #archlinux-testing on IRC. I could also set up a mailing list for this if we want that. Florian
On 2018-08-24 11:10:36 (+0200), Antonio Rojas via arch-dev-public wrote:
ams Will contact upstream (but project looks pretty dead, if in doubt I wouldn't wait on it)
hydrogen 1.0.0beta1 is the first Qt5-capable version. If they're too slow, I'll ship that.
lmms This should already be Qt5 capable. Rebuild incoming.
mixxx I hope this is portable! It's the only cross-platform tool for DJing.
On 8/24/18 6:00 AM, David Runge wrote:
lmms This should already be Qt5 capable. Rebuild incoming.
https://bugs.archlinux.org/task/47723 Available in the beta only, AFAIK.
mixxx I hope this is portable! It's the only cross-platform tool for DJing.
Also builds with qt5 on master (so should be there in 2.2 release). -- Eli Schwartz Bug Wrangler and Trusted User
On Fri, Aug 24, 2018 at 11:10:36AM +0200, Antonio Rojas via arch-dev-public
And gone. After the KDE4 and PyQt4 removal, 'pactree -sru qt4 | wc -l' went down from 78 to 44. The full list is below: if any of your packages is in there, please check whether it can be dropped, ported to use Qt5 or some other toolkit. We should aim at dropping Qt4 as soon as possible, it has been EOL for 3 years already.
Please make a TODO list in archweb, otherwise manually checking what is done and what isn't is error prone. Florian
El viernes, 24 de agosto de 2018 16:16:40 (CEST) Florian Pritz escribió:
Please make a TODO list in archweb, otherwise manually checking what is done and what isn't is error prone.
I'm not very fond of adding todo lists for things that are not completely under devs/TU's control (some packages have not been ported upstream yet). It will just sit there unfinished for months and we will eventually forget about it. Once we decide it's time to drop qt4, we can open a todo list with a deadline after which packages that are still not ported will be dropped.
On Fri, Aug 24, 2018 at 07:15:31PM +0200, Antonio Rojas via arch-dev-public
I'm not very fond of adding todo lists for things that are not completely under devs/TU's control (some packages have not been ported upstream yet). It will just sit there unfinished for months and we will eventually forget about it. Once we decide it's time to drop qt4, we can open a todo list with a deadline after which packages that are still not ported will be dropped.
I'm not quite sure how doing it on the mailing list is any better then. You could also just ask people in the description of the TODO to mark a package as done right away, if there is no option to disable qt4, instead of keeping it open. That way the list shows which packages someone has looked at and either fixed or decided that they can't be fixed yet. I'm generally a fan of mailing lists, but working on a list of things on a mailing list doesn't feel efficient. If I want to join in after others have worked on it, I first have to read your mail and then tick off each package that someone else has already fixed or said that it can't be fixed. I'd rather have something that directly shows me the current state. Florian
participants (6)
-
Antonio Rojas
-
Bruno Pagani
-
David Runge
-
Eli Schwartz
-
Florian Pritz
-
Gaetan Bisson