You are not logged in.
Hi all,
After combing through the various threads concerning KDE4 and Kf5 apps creeping in, I've been attempting to make Kf5 apps look integrated with the remainder of KDE4.
I've come to the conclusion that this simply will never work right.
For the time being, I want to roll back the packages from their Kf5 versions to their KDE4 versions.
What would be the least troublesome method to do this?
Use the Arch Rollback Machine to install the old KDE4 4.14 3 packages and freeze them
Attempt to create PKGBUILDs of the affected apps, and go from there
Ideally I think the second method is the way to go, but would be a harder undertaking. I don't have an ABS repository of how the packages were originally built (so I could modify those), would anyone know how to locate those?
Has anyone attempted to freeze the KDE4 version of the affected apps?
So far I believe it's just Kate, Kwrite, and Konsole, with Konsole already having an AUR package for the KDE4 version. Kate and Kwrite seem to be built a little more complex than console is, so I'd love to see the ABS PKGBUILDS of the 4.14.3 versions of those apps.
Last edited by SilentSam (2015-04-05 22:51:03)
Offline
It's not recomended, because that you haven't got any bugfix etc., but it's your choice:
1. Install downgrade i.e. from AUR.
2. Execute downgrade with name of package
3. Of course you should now what version of package was build on KDE4 - look at kde.org for necessary informations. Look at infos about KDE Applications 14.12. Every applications prior then 14.12 was build against of KDE4.
Offline
It's not recomended, because that you haven't got any bugfix etc., but it's your choice:
1. Install downgrade i.e. from AUR.
2. Execute downgrade with name of package
3. Of course you should now what version of package was build on KDE4 - look at kde.org for necessary informations. Look at infos about KDE Applications 14.12. Every applications prior then 14.12 was build against of KDE4.
Yeah, that's the crux of the issue is that the KDE4 versions are not located in AUR (exception is konsole), which is why I would either have to use ARM to revert to an older package version, or to build my own PKGBUILDs (which if anyone has a PKGBUILD from ABS for the 4.14.3 version of the apps, I would love to see that to base my own off of).
The Kf5 updated versions of the apps are pretty easy to identify, they've had the kde*- identifier stripped from them.
e.g:
gwenview 14.12.2-1
kate 14.12.2-2
kwrite 14.12.2-2These are Kf5 versions
kdebase-dolphin 14.12.2-1 This is not, since kdebase- precedes dolphin in the package name.
Last edited by SilentSam (2015-03-05 21:14:46)
Offline
Gwenview:
downgrade kdegraphics-gwenviewKate:
downgrade kdesdk-kateKwrite:
downgrade kdebase-kwriteetc.
Take a look at: http://seblu.net/a/archive/packages/
Offline
Thanks pb, I'll try the downgrade route and see how that works out for me. First I'll have to take a snapshot of my current install in case anything goes horribly wrong.
I'll post results of this.
I take it there's no way to grab the old Arch Build System's PKGBUILDs then?
Offline
It's not recomended, because that you haven't got any bugfix etc., but it's your choice
I guess it has to be said to keep the Arch community healthy (of course the hope is that sometime in the future we'll have bug-free software), but today the choice is between upgrading from a set of known and mostly unobtrusive bugs in KDE4 to obtrusive or even in some cases work-blocking bugs in the KF5 applications with guaranteed feature loss. Thous this argument is somewhat bogus.
Offline
I take it there's no way to grab the old Arch Build System's PKGBUILDs then?
To build old versions of the packages take a look in the history of the ABS repositories. You can get access via tools like asp-git and the web interface (search for the package and click "Source Files" or "View Changes")
pb wrote:It's not recomended, because that you haven't got any bugfix etc., but it's your choice
I guess it has to be said to keep the Arch community healthy (of course the hope is that sometime in the future we'll have bug-free software), but today the choice is between upgrading from a set of known and mostly unobtrusive bugs in KDE4 to obtrusive or even in some cases work-blocking bugs in the KF5 applications with guaranteed feature loss. Thous this argument is somewhat bogus.
Well, consider that the packagers have only a limited amount of time they can invest in packaging for Arch. They made the decision to go with KF5 to get the most cutting edge experience, dropping KDE4 in the process and making it unsupported (because old versions of software are not supported). I understand that KDE4 may be preferable to KF5, but unless someone happens to be running the same setup and found the solution, chances are that you are on your own in maintaining the software. That is why it is not recommended to downgrade unless absolutely necessary.
Offline
SilentSam wrote:I take it there's no way to grab the old Arch Build System's PKGBUILDs then?
To build old versions of the packages take a look in the history of the ABS repositories. You can get access via tools like asp-git and the web interface (search for the package and click "Source Files" or "View Changes")
I did a brief search on this... I was wondering if the history of the PKGBUILD was kept through the package rename (ie: kdesdk-kate was renamed to kate). I'll definitely pursue this more in the coming days, as I'd prefer to build from a PKGBUILD than downgrading.
Offline
Of course, you can build those packages with old PKGBUILDs. The old name of packages, you can find in "replaces=" in current PKGBUILD. The list of applications build against of KF5 you find there: https://www.kde.org/announcements/fulll … 4.12.0.php or https://www.kde.org/announcements/annou … 4.12.0.php
But,... you ask about "easiest method". Seblu ARM is a repository, where we have daily snapshot of Arch's repositories. That was January 23rd, 2015 when we have KDE 4.13.4 last time. Then just install neccessary apps from Seblu repository: http://seblu.net/a/arm/2015/01/23/extra/os/ with pacman -U or, maybe even better, add this to pacman.conf above [extra], install neccessary apps, block theirs upgrade in IgnorePkg in pacman.conf, and remove seblu repos from pacman.conf (or just # it).
See: http://seblu.net/a/arm/ about Seblu's ARM.
Offline
SilentSam wrote:I take it there's no way to grab the old Arch Build System's PKGBUILDs then?
To build old versions of the packages take a look in the history of the ABS repositories. You can get access via tools like asp-git and the web interface (search for the package and click "Source Files" or "View Changes")
JKAbrams wrote:pb wrote:It's not recomended, because that you haven't got any bugfix etc., but it's your choice
I guess it has to be said to keep the Arch community healthy (of course the hope is that sometime in the future we'll have bug-free software), but today the choice is between upgrading from a set of known and mostly unobtrusive bugs in KDE4 to obtrusive or even in some cases work-blocking bugs in the KF5 applications with guaranteed feature loss. Thous this argument is somewhat bogus.
Well, consider that the packagers have only a limited amount of time they can invest in packaging for Arch. They made the decision to go with KF5 to get the most cutting edge experience, dropping KDE4 in the process and making it unsupported (because old versions of software are not supported). I understand that KDE4 may be preferable to KF5, but unless someone happens to be running the same setup and found the solution, chances are that you are on your own in maintaining the software. That is why it is not recommended to downgrade unless absolutely necessary.
Yes, your right, and I agree, thats what I meant with "health of the community" in an abstract sense. And I should probably have said beta instead of testing because I did not mean the testing repo specifically.
I just wonder, with hindsight was it the right decision? What can we learn for KF6? Is this the road we have to travel with every upgrade with KDE on Arch or can we do better?
Offline
What can we learn for KF6? Is this the road we have to travel with every upgrade with KDE on Arch or can we do better?
KF6 will be more or less in 2017. According to my knowledge it won't be a such "revolution" as between Qt3 and Qt4. Qt5 is closer to Qt4 then Qt4 to Qt3. A lot of code is almost the same as Qt4, then other changes in current KDE environment is responsible for aur current problems. But... I've used Plasma 5 since December 2014 and - personally - don't notice many bugs. Of course, many applications (mailny from KDE) haven't ported to KF5/Qt5 yet (I use modificed GIT version of many of them). One of the main problem is that we need to know this new DE.
Offline
I just wonder, with hindsight was it the right decision? What can we learn for KF6? Is this the road we have to travel with every upgrade with KDE on Arch or can we do better?
Here is my opinion of the situation:
After combing through the various threads concerning KDE4 and Kf5 apps creeping in, I've been attempting to make Kf5 apps look integrated with the remainder of KDE4.
I've come to the conclusion that this simply will never work right.
The issue that the original poster was having is that the new applications don't look the way he wants them to look. In my opinion, not only is this a very small issue, but is an issue that somebody somewhere somehow has already resolved.
today the choice is between upgrading from a set of known and mostly unobtrusive bugs in KDE4 to obtrusive or even in some cases work-blocking bugs in the KF5 applications with guaranteed feature loss.
Arch Linux targets and accommodates competent GNU/Linux users. This is the type of user who will:
Wait to perform a software update until there is time to fix any issues that may occur. This means not doing an update when business or school work is a priority.
Review the list of packages that are to be updated and understand the implications of the changes. This can be done by reading release notes, change logs, wiki pages, the forums, the mailing list, and so on.
Reporting bugs when they are found. Either on the Arch Linux bug tracker, upstream bug tracker, or, if further help is needed, on the Arch Linux forums.
If this is unacceptable, then Arch Linux provides simple ways to downgrade packages, install older packages through the AUR, or skip upgrading them in the first place.
Because of this, I think moving the new KDE packages to the official repositories was the right decision.
Offline
JKAbrams wrote:today the choice is between upgrading from a set of known and mostly unobtrusive bugs in KDE4 to obtrusive or even in some cases work-blocking bugs in the KF5 applications with guaranteed feature loss.
Arch Linux targets and accommodates competent GNU/Linux users. This is the type of user who will:
Wait to perform a software update until there is time to fix any issues that may occur. This means not doing an update when business or school work is a priority.
Review the list of packages that are to be updated and understand the implications of the changes. This can be done by reading release notes, change logs, wiki pages, the forums, the mailing list, and so on.
Reporting bugs when they are found. Either on the Arch Linux bug tracker, upstream bug tracker, or, if further help is needed, on the Arch Linux forums.
If this is unacceptable, then Arch Linux provides simple ways to downgrade packages, install older packages through the AUR, or skip upgrading them in the first place.
Because of this, I think moving the new KDE packages to the official repositories was the right decision.
Yeah, I do all these. Number 2 is, however, not really possible in a general case as Arch users are the first to install new KDE software there is really not much information yet on how it works.
And really I have to ask, are there any Arch user that does this consistently for all applications before running pacman -Syu?
Today was a small update with 22 upgraded packages, but that would mean reading 22 changelogs, reading the latest bugs on 22 different bug trackers and making educated guesses about what issues will affect me, then searching forums for new problems not yet reported as bugs, and finally reading the minutia of the mailing lists of these 22 projects that is mostly only understandable to the people that are writing the software. This would be a full time job and include reading up on basically all the progress that's happening in all of the applications that I have installed. Certainly a good thing to do, and I do it for a handful of pet projects, but I'd be amazed if more than a few Arch users really does this for all packages. And even then you can still get surprises. Based on experience users tend to rely on the great work the maintainers and upstream coders, yet knowing that mistakes do happen.
What I do, and what I imagine most users do is look at the list of applications being upgraded, see if there is something that has caused problems in the past or where there is a major update of some package and perhaps read a little about some of these and read the startpage of archlinux.org then just do the upgrade and fix any problems that the pacman reports like .pacnew/.pacsave files or suggestions for commands to run, hope for the best and fix any issues that may arise when they are found, which by the way is often not at the time of the upgrade, but might be days or even weeks away, when I actually need to use the applications that got upgraded. I don't imagine many users does a complete comprehensive test of all features in upgraded applications to verify that they still work correctly. If I'm worried I might do a simple start of the applications to see that it still starts.
I try to report all bugs whenever I encounter an unreported issue. Reporting quality bug reports takes a lot of time and producing KDE crash logs is hard on Arch as it's needed (as far as I understand) to recompile the whole of KDE with debugging symbols enabled (which I have yet to figure out how do the right way on a production machine), this has kept me from reporting a bug in Ktorrent where it crashes consistently after being on for 2-20 hours running.
Last edited by JKAbrams (2015-03-08 21:19:16)
Offline
Just wanted to finalize what ended up being the quickest method to resolve this...
I discovered which of the main KDE applications were Kf5 based due to the dropping of the kde*- tags in front of the package names:
pacman -Q | grep 14.12
gwenview 14.12.2-1
kate 14.12.2-2
konsole 14.12.2-1
kwrite 14.12.2-2
...They ended up being konsole, gwenview, kate, and kwrite. The remainder of the standalone packages were artwork related and fine to remain.
I had to remove the kde-meta packages since they would have dependencies not met after downgrading:
pacman -R kde-meta-kdebase kde-meta-kdegraphics kde-meta-kdeutils(All packages I'm running pacman -U against were pulled from ARM: http://seblu.net/a/arm/packages/k/ simply using wget)
Replaced kwrite:
pacman -R kwrite
pacman -U kdebase-kwrite-4.14.3-1-x86_64.pkg.tar.xzkonsole and kate were dependencies for a few other KDE pieces, so I swapped them out ignoring dependency checks:
pacman -Rdd kate katepart4 konsole konsolepart4 I then installed the rollback packages:
pacman -U kdebase-katepart-4.14.3-1-x86_64.pkg.tar.xz
pacman -U kdesdk-kate-4.14.3-1-x86_64.pkg.tar.xz
pacman -U kdebase-konsole-4.14.3-1-x86_64.pkg.tar.xzGwenview swapped out and downgraded without fuss:
pacman -U kdegraphics-gwenview-4.14.3-1-x86_64.pkg.tar.xz
pacman -Sy kipi-pluginsAt this point, I placed a hold on the packages I downgraded in pacman.conf
IgnorePkg = kdegraphics-gwenview kdebase-katepart kdebase-kwrite kdesdk-kate kdebase-konsoleThen was the qt5 cleanup... I still need qt5-base due to kdepim-runtime requiring libsignon-qt4 instead of signon-qt4, but that's another project for another day... Everything else I followed dependencies systematically using pacman -Qi, tracing through to parent packages and attempting to run pacman -Rs against them. Below is the pacman timeline of the result:
pacman -Rs ktexteditor
pacman -Rs baloo-frameworks
pacman -Sy baloo4
pacman -Rs kded
pacman -Rs knotifyocnfig
pacman -Rs knewstuff
pacman -Sy kactivities4 (swaps out kactivities-frameworks)
pacman -Rs kdeclarative
pacman -Rs kconfigwidgets
pacman -Rs kcmutils
pacman -Rs phonon-qt5-vlc
pacman -Rs kpty
pacman -Rs kitemviews
pacman -Rs kde-telepathy-meta (not sure if this one was actually needed, or just me hating kde-telepathy)
pacman -Rs threadweaver
pacman -Rs qtcurve-qt5
pacman -Rs smplayer (smplayer now depends on qt5, there's a qt4 build in AUR to replace it)
pacman -U smplayer-qt4/smplayer-qt4-14.9.0.6690-1-x86_64.pkg.tar.xzRan a pacman -Syu and no new qt5 or Kf5 apps were pulled in...
The end effect has been achieved. I've performed this method on 2 of my Arch systems. One is attached to my plasma TV, and qt5 apps were blanking my screen for several seconds. This downgrade completely fixed that issue, and now all applications have a properly integrated appearance.
Last edited by SilentSam (2015-04-05 22:55:01)
Offline