kdesig has been working furiously this week to bring plasma-5.9.3 to fedora.
First, plasma-5.9.3 was imported into fedora rawhide. Then, based on that work, we did an initial set of f25 builds in copr: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-5-unstable/
For testing and feedback. If all goes well, we will seriously consider bringing plasma-5.9.x to official fedora updates (and will be an upgrade path from using the plasma-5-unstable copr).
One blocker: a new kf5-kirigami2 dependency needs review, https://bugzilla.redhat.com/show_bug.cgi?id=kf5-kirigami2
(If more issues come up, I'll create a formal plasma-5.9 tracker bug)
Enjoy, and let us know what breaks.
-- Rex
On Thursday, 2 March 2017 16:43:29 GMT Rex Dieter wrote:
kdesig has been working furiously this week to bring plasma-5.9.3 to fedora.
First, plasma-5.9.3 was imported into fedora rawhide. Then, based on that work, we did an initial set of f25 builds in copr: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-5-unstable/
For testing and feedback. If all goes well, we will seriously consider bringing plasma-5.9.x to official fedora updates (and will be an upgrade path from using the plasma-5-unstable copr).
First off, thanks for 5.9.3
I have been using this on my main box since it was available in copr and have yet to run into any issues.. I'll do some more intense testing over the weekend.
Colin
On Friday, 3 March 2017 21.24.22 WET Colin J Thomson wrote:
First off, thanks for 5.9.3
+1
I have been using this on my main box since it was available in copr and have yet to run into any issues..
I have been running it since Thursday morning (UTC) when it was available initially in my updates.
I noticed the sddm theme, that should be fixed in 5.9.3-2 but other than that nothing as relevant that need to report.
I'll do some more intense testing over the weekend.
Colin
Thank you. :-)
On 03/03/17 00:43, Rex Dieter wrote:
kdesig has been working furiously this week to bring plasma-5.9.3 to fedora.
First, plasma-5.9.3 was imported into fedora rawhide. Then, based on that work, we did an initial set of f25 builds in copr: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-5-unstable/
For testing and feedback. If all goes well, we will seriously consider bringing plasma-5.9.x to official fedora updates (and will be an upgrade path from using the plasma-5-unstable copr).
One blocker: a new kf5-kirigami2 dependency needs review, https://bugzilla.redhat.com/show_bug.cgi?id=kf5-kirigami2
(If more issues come up, I'll create a formal plasma-5.9 tracker bug)
Enjoy, and let us know what breaks.
I have 2 systems which I've updated. So far I see one difference that I can't figure....
In "system-settings" I'm using Classic Tree View and I have 6 categories with the last one being "System Administration". On the other system there are only 5 categories. No "System Administration".
What controls if that is visible?
Ed Greshko wrote:
I have 2 systems which I've updated. So far I see one difference that I can't figure....
In "system-settings" I'm using Classic Tree View and I have 6 categories with the last one being "System Administration". On the other system there are only 5 categories. No "System Administration".
What controls if that is visible?
Any menu category is only shown if you actually have applications in it. (If you see an empty category, that is because there are entries in it, but they are hidden from view (NoDisplay=true).) The System Administration category takes all the packages that have both the System and Settings categories (which would otherwise be duplicated into both System and Settings). If you have no such application, the category is not shown.
I hope this helps, Kevin Kofler
On 03/04/17 19:13, Kevin Kofler wrote:
Ed Greshko wrote:
I have 2 systems which I've updated. So far I see one difference that I can't figure....
In "system-settings" I'm using Classic Tree View and I have 6 categories with the last one being "System Administration". On the other system there are only 5 categories. No "System Administration".
What controls if that is visible?
Any menu category is only shown if you actually have applications in it. (If you see an empty category, that is because there are entries in it, but they are hidden from view (NoDisplay=true).) The System Administration category takes all the packages that have both the System and Settings categories (which would otherwise be duplicated into both System and Settings). If you have no such application, the category is not shown.
I have to admit that I don't understand what you're telling me.....
On the one system there is a category called "System Administration" and when I expand it there is "Software Management" and "Systemd" choices. This doesn't exist on the other system.
So, what do I have to install on the other system?
FWIW, (on the other system) if I go to the KDE menu on the panel and go to "Applications-->Administration" there is an entry for "Software Management" which if I start it will be the same as in "System Settings".
systemsettings5 is what I'm running and what differs on the 2 systems if that wasn't clear.
good https://drive.google.com/open?id=0B2H9v1dYNcvpY09BX1luUVQ3TFE not good https://drive.google.com/open?id=0B2H9v1dYNcvpTHNMTWlKb2E1SEE
Ed Greshko ha scritto:
On 03/04/17 19:13, Kevin Kofler wrote:
Ed Greshko wrote:
I have 2 systems which I've updated. So far I see one difference that I can't figure....
In "system-settings" I'm using Classic Tree View and I have 6 categories with the last one being "System Administration". On the other system there are only 5 categories. No "System Administration".
What controls if that is visible?
Any menu category is only shown if you actually have applications in it. (If you see an empty category, that is because there are entries in it, but they are hidden from view (NoDisplay=true).) The System Administration category takes all the packages that have both the System and Settings categories (which would otherwise be duplicated into both System and Settings). If you have no such application, the category is not shown.
I have to admit that I don't understand what you're telling me.....
On the one system there is a category called "System Administration" and when I expand it there is "Software Management" and "Systemd" choices. This doesn't exist on the other system.
So, what do I have to install on the other system?
The systemd KCM (aka kcm_systemd) and probably apper or something else:
The systemd-kcm ships this additional category: https://cgit.kde.org/systemd-kcm.git/tree/other/settings-system-administrati...
On 03/04/17 20:23, Luigi Toscano wrote:
The systemd KCM (aka kcm_systemd) and probably apper or something else:
The systemd-kcm ships this additional category: https://cgit.kde.org/systemd-kcm.git/tree/other/settings-system-administrati...
Thanks!
That is what I was missing!
Added the repo and attempted to manually upgrade through Software Upgrade in System Tray but received the following error: "Packages are not compatible Multiple packages exist that are not compatible with each other. This is usually due to mixing packages from different software origins." Shall I disable other (official) repos to make this work?
P Breviglieri wrote:
Added the repo and attempted to manually upgrade through Software Upgrade in System Tray but received the following error: "Packages are not compatible Multiple packages exist that are not compatible with each other. This is usually due to mixing packages from different software origins." Shall I disable other (official) repos to make this work?
That should not be necessary.
Does 'dnf update' work? If not, can you post the output from running 'dnf update --best' ?
note: the repo referenced in this thread does not support multilib, so if you purposely have related i686 pkgs on a x86_64 system, you won't be able to use it (not without extra work).
-- Rex
The message I mentioned showed up after adding the repo ("dnf copr enable @kdesig/plasma-5-unstable") and clicking on Software Updates / Check for Updates in System Tray. In response, 56 packages (5.9.3 related) were reported as available for upgrade, so I thought a "dnf update" was not necessary.
I repeated the process removing the repo with Apper, re-adding it through CLI followed by "dnf update". It did work - packages were downloaded and upgraded as expected!
Thanks Rex for making this available in copr and helping me with the upgrade process! I will report anything I may find.
On Thu, Mar 2, 2017 at 10:13 PM, Rex Dieter wrote:
kdesig has been working furiously this week to bring plasma-5.9.3 to fedora.
First, plasma-5.9.3 was imported into fedora rawhide. Then, based on that work, we did an initial set of f25 builds in copr: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-5-unstable/
Enjoy, and let us know what breaks.
Many thanks, I have been running Plasma 5.9.3 for some time without noticing any breakage.
-- Rex
On 07/03/17 22:20, Rajeesh K V wrote:
On Thu, Mar 2, 2017 at 10:13 PM, Rex Dieter wrote:
kdesig has been working furiously this week to bring plasma-5.9.3 to fedora. First, plasma-5.9.3 was imported into fedora rawhide. Then, based on that work, we did an initial set of f25 builds in copr: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-5-unstable/ <https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-5-unstable/> Enjoy, and let us know what breaks.Many thanks, I have been running Plasma 5.9.3 for some time without noticing any breakage.
+1
On Thursday, March 2, 2017 11:43:29 AM EST Rex Dieter wrote:
kdesig has been working furiously this week to bring plasma-5.9.3 to fedora.
First, plasma-5.9.3 was imported into fedora rawhide. Then, based on that work, we did an initial set of f25 builds in copr: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-5-unstable/
For testing and feedback. If all goes well, we will seriously consider bringing plasma-5.9.x to official fedora updates (and will be an upgrade path from using the plasma-5-unstable copr).
One blocker: a new kf5-kirigami2 dependency needs review, https://bugzilla.redhat.com/show_bug.cgi?id=kf5-kirigami2
(If more issues come up, I'll create a formal plasma-5.9 tracker bug)
Enjoy, and let us know what breaks.
Uh, oh.
I spoke too soon.
After updating, I initially found no problems, but my whole system "froze" several times later. I think it was related to powerdevil, but I collected no information. I had to do a hard reset, powering down to recover. Examining my journal, after rebooting, the log messages just stopped at the point of failure and nothing was recorded after that. I repeated the failure maybe three times, but each time the system was completely unresponsive. The lack of any fan noise indicates that the system was simply disabled for any interrupts, but not executing or looping.
I also observed a slightly annoying problem in kmail. Using IMAP with gmail, deleting a message from my inbox resulted in the same message being fetched again. Apparently deleting the message was not signaled to the IMAP server.
Anyway, I disabled the copr repository and did a dnf distro-sync to downgrade back to plasma 5.8.6.
If you can think of anything I could have done to diagnose the problem, let me know and I'll give it another go.
Sorry.
One week has passed and nothing to report! 5.9.3 running flawlessly. Thanks for making this available!
I just found that wayland support is buggly, could I report this?
Or, I just wait waylan support to be avaliable?
On Mon, Mar 13, 2017 at 11:21 PM, P Breviglieri pbrevig@fedoraproject.org wrote:
One week has passed and nothing to report! 5.9.3 running flawlessly. Thanks for making this available! _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org
Hi, I met a bug.
I installed plasma-workspace-5.9.3-2.fc25.x86_64 from the copr, and in Xorg.
But I found in sometime, cpu load will be 100%, I often found one cpu is 100%.
PS: just before, I found wireshark is not-responding and one cpu is 100%, so I kill wireshark, All cpu is immediately 100%.
On Sun, Mar 19, 2017 at 10:40 PM, RobberPhex robberphex@gmail.com wrote:
Hi, I met a bug.
I installed plasma-workspace-5.9.3-2.fc25.x86_64 from the copr, and in Xorg.
But I found in sometime, cpu load will be 100%, I often found one cpu is 100%.
PS: just before, I found wireshark is not-responding and one cpu is 100%, so I kill wireshark, All cpu is immediately 100%.
You may be experiencing https://bugzilla.redhat.com/show_bug.cgi?id=1432619 Check to see if you have any zombies. You can do this easily using "top" from the command line.
If so, you can identify the zombies using:
ps axo stat,ppid,pid,comm | grep -w defunct
You will then get an output similar to this:
Z 2501 18728 xdg-user-dir <defunct>
The number following the Z is the parent process.
Then do:
ps -e | grep nnnn (in this case 2501)
The parent process will be either plasmashell or krunner
Then, restart either plasmashell or krunner by using krunner (alt-F2):
killall plasmashell; plasmashell or killall krunner; krunner
That should eliminate the zombie processes and put the cpu utilization back to normal.
cc: to the bug above for further updates
Rex, as I understand it, this is related to baloo... is there a simple way to turn it off until this can get fixed? Something is triggering it on my machine, but I haven't been able to figure out exactly what... it just seems to spin out of control from time to time.
OK, I believe I figured out how to turn off Baloo - and I haven't had any zombies for a few days, so it appears to be working:
Under system settings, search, File Search: unclick - enable file search Under system settings, search, Plasma Search: unclick - Desktop Search; unclick - Plasma Desktop Shell
On Mon, Mar 20, 2017 at 12:55 PM, Gerald B. Cox gbcox@bzb.us wrote:
Rex, as I understand it, this is related to baloo... is there a simple way to turn it off until this can get fixed? Something is triggering it on my machine, but I haven't been able to figure out exactly what... it just seems to spin out of control from time to time.
On Thu, Mar 2, 2017 at 8:43 AM, Rex Dieter rdieter@math.unl.edu wrote:
For testing and feedback. If all goes well, we will seriously consider bringing plasma-5.9.x to official fedora updates (and will be an upgrade path from using the plasma-5-unstable copr).
One blocker: a new kf5-kirigami2 dependency needs review, https://bugzilla.redhat.com/show_bug.cgi?id=kf5-kirigami2
(If more issues come up, I'll create a formal plasma-5.9 tracker bug)
Enjoy, and let us know what breaks.
I just upgraded a few days ago and have been noticing that plasmashell has been using alot of cpu...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2501 gbcox 20 0 0.256t 256412 120092 S 298.3 0.8 671:44.07 plasmashell
Then I noticed three zombie processes: ps axo stat,ppid,pid,comm | grep -w defunct Z 2501 18728 xdg-user-dir <defunct> Z 2501 18778 xdg-user-dir <defunct> Z 2501 18829 xdg-user-dir <defunct>
The parent is plasmashell...
If I kill and restart plasmashell, that takes care of the zombies and cpu goes back to normal.
Anyone else see this?
Thanks!
On Wed, Mar 15, 2017 at 3:00 AM, José Abílio Matos jamatos@fc.up.pt wrote:
On Wednesday, 15 March 2017 01.29.45 WET Gerald B. Cox wrote:
Anyone else see this?
I do not see that here.
Thanks for the feedback. If anyone notices anything, please advise. It's happened 4 times so far. I've now setup for a backtrace so when it happens again I can get some info.
Other than that, everything seems to be working fine.
On Wed, Mar 15, 2017 at 9:42 AM, Gerald B. Cox gbcox@bzb.us wrote:
It's happened 4 times so far. I've now setup for a backtrace so when it happens again I can get some info.
Just happened again about 30 minutes after a reboot. I got a backtrace and opened a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1432619
Happens here too, two cores at 100% for plasmashell
Mustafa
On Wed, Mar 15, 2017 at 10:40 PM, Gerald B. Cox gbcox@bzb.us wrote:
On Wed, Mar 15, 2017 at 9:42 AM, Gerald B. Cox gbcox@bzb.us wrote:
It's happened 4 times so far. I've now setup for a backtrace so when it happens again I can get some info.
Just happened again about 30 minutes after a reboot. I got a backtrace and opened a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1432619
kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org
Good to know. Thanks! Hopefully the backtrace will help narrow it down.
On Wed, Mar 15, 2017 at 2:34 PM, Mustafa Muhammad mustafa1024m@gmail.com wrote:
Happens here too, two cores at 100% for plasmashell
Mustafa
On Wed, Mar 15, 2017 at 10:40 PM, Gerald B. Cox gbcox@bzb.us wrote:
On Wed, Mar 15, 2017 at 9:42 AM, Gerald B. Cox gbcox@bzb.us wrote:
It's happened 4 times so far. I've now setup for a backtrace so when it happens again I can get some info.
Just happened again about 30 minutes after a reboot. I got a backtrace
and
opened a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1432619
kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org
kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org
Gerald B. Cox wrote:
On Wed, Mar 15, 2017 at 9:42 AM, Gerald B. Cox gbcox@bzb.us wrote:
It's happened 4 times so far. I've now setup for a backtrace so when it happens again I can get some info.
Just happened again about 30 minutes after a reboot. I got a backtrace and opened a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1432619
Thanks! that backtrace does appear to be helpful, highlights calls to xdg- user-dir from the baloosearch krunner plugin.
Turns out we ship a default baloofilerc file containing:
folders[$e]=$(xdg-user-dir DESKTOP),$(xdg-user-dir DOCUMENTS),$(xdg-user-dir PICTURES),$(xdg-user-dir VIDEOS),$(xdg-user-dir MUSIC)
shortly after implementing that, I came up with a patch for baloo as well, https://src.fedoraproject.org/cgit/rpms/kf5-baloo.git/tree/baloo-5.14.0-balo...
which should be sufficient by itself. So, if calling-out to xdg-user-dir is problematic, we can probably rely solely on the patch instead (which is probably safer).
I added a comment in the upstream bug, https://bugs.kde.org/show_bug.cgi?id=377671 saying the same
-- Rex
On Thu, Mar 16, 2017 at 6:31 AM, Rex Dieter rdieter@math.unl.edu wrote:
which should be sufficient by itself. So, if calling-out to xdg-user-dir is problematic, we can probably rely solely on the patch instead (which is probably safer).
I added a comment in the upstream bug, https://bugs.kde.org/show_bug.cgi?id=377671 saying the same
Thanks Rex!
On Thu, Mar 16, 2017 at 10:33 AM, Gerald B. Cox gbcox@bzb.us wrote:
I added a comment in the upstream bug, https://bugs.kde.org/show_bug.cgi?id=377671 saying the same
Just happened again... this time with krunner as the parent: ps axo stat,ppid,pid,comm | grep -w defunct Z 2314 16967 xdg-user-dir <defunct> Z 2314 17105 xdg-user-dir <defunct>
ps -e | grep 2314 2314 ? 00:02:43 krunner
Believe it's the same type of thing... I'll update both tickets. I got another backtrace.
-
Colin J Thomson -
Ed Greshko -
Garry Williams -
Gerald B. Cox -
José Abílio Matos -
Kevin Kofler -
Luigi Toscano -
Mustafa Muhammad -
P Breviglieri -
Rajeesh K V -
Rex Dieter -
RobberPhex -
Robert Lu
-
Steven Haigh