Bug 1830261 - After upgrade to Fedora 32, CPU Frequency Monitor fails to run
Summary: After upgrade to Fedora 32, CPU Frequency Monitor fails to run
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xfce4-cpufreq-plugin
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1830549
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-01 11:45 UTC by Jan Pazdziora (Red Hat)
Modified: 2020-05-05 05:35 UTC (History)
5 users (show)

Fixed In Version: xfce4-cpufreq-plugin-1.2.1-6.fc32
Clone Of:
Environment:
Last Closed: 2020-05-05 05:35:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Xfce 16798 0 None None None 2020-05-03 09:21:36 UTC

Description Jan Pazdziora (Red Hat) 2020-05-01 11:45:54 UTC
Description of problem:

After upgrade to Fedora 32, upon login, I get error window saying

  Plugin "CPU Frequency Monitor" unexpectedly left the panel, do you want to restart it?

and re-executing does not help.

Version-Release number of selected component (if applicable):

xfce4-cpufreq-plugin-1.2.1-5.fc32.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. Add CPU Frequence Monitor to XFCE panel on Fedora 32.

Actual results:

Error window saying Plugin "CPU Frequency Monitor" unexpectedly left the panel, do you want to restart it?

Expected results:

It shows up in the panel and starts showing the frequency.

Additional info:

In ~/.xsession-errors, there is

(process:1872): xfce4-panel-wrapper-CRITICAL **: 13:38:58.691: Wrapper cpufreq-21: Failed to open plugin module "/usr/lib64/xfce4/panel/plugins/libcpufreq.so": /usr/lib64/xfce4/panel/plugins/libcpufreq.so: undefined symbol: cpuFreq.

Comment 1 Raphael Groner 2020-05-01 17:40:27 UTC
Reproducible for me.
xfce4-cpufreq-plugin-1.2.1-5.fc32.x86_64

Comment 2 Artem S. Tashkinov 2020-05-02 17:06:40 UTC
Confirming.

Luckily this command restores it (don't forget to exclude the package from automatic updates afterwards):

rpm -Uvh --force xfce4-cpufreq-plugin-1.2.1-3.fc31.x86_64.rpm

Mukundan Ragavan applied a patch which probably breaks it:

sed -i 's/CpuFreqPlugin \*cpuFreq/extern CpuFreqPlugin \*cpuFreq/' panel-plugin/xfce4-cpufreq-plugin.h

Comment 3 Mukundan Ragavan 2020-05-02 17:31:45 UTC
Hmmm ... That was needed for compiling with gcc-10. It compiled properly but clearly does not work. Let me take a look.

Comment 4 Mukundan Ragavan 2020-05-02 17:50:52 UTC
Of course, any help/patches are appreciated.

Comment 5 Mukundan Ragavan 2020-05-02 17:54:24 UTC
(In reply to Artem S. Tashkinov from comment #2)
> Mukundan Ragavan applied a patch which probably breaks it:
> 
By the way, stop claiming I am "missing in action" like you did in bz#1830549. I am never going to be able to reply to bug reports as soon as you would like. I am only volunteering my free time. You opening new reports is only going to add to the noise in my email.

Comment 6 Artem S. Tashkinov 2020-05-02 18:02:07 UTC
(In reply to Mukundan Ragavan from comment #5)

Speaking of having no time: the patch which broke the package was added three months ago. During this time you've never bothered to check whether the package works. As a maintainer you could do that, no? At least once, no? Won't spam bugzilla any longer as it obviously doesn't help anyone.

Comment 7 Raphael Groner 2020-05-02 18:15:46 UTC
Someone should fix the proposed patch and send to upstream.

Please keep being nice to each other, thanks. We mostly work on packages in our free spare time and don't get paid for neither is it our daily buiness/job.

Comment 8 Raphael Groner 2020-05-02 18:17:24 UTC
That said, Xfce is generally not blocking criteria for any Fedora release.

Comment 9 Mukundan Ragavan 2020-05-02 19:41:52 UTC
(In reply to Raphael Groner from comment #7)
> Someone should fix the proposed patch and send to upstream.
> 


I am not sure if this is really a good patch. I don't use this specific plugin at all and have not had the time to check it unfortunately.

That said, sensors-plugin also was FTBFS with gcc-10 and fix for that was considerably more complicated and gcc-10 support may not be on the top of the list for upstream since we are the only ones using it (even Arch I believe is on gcc-9 I think). See sensors plugin bug report - https://bugzilla.xfce.org/show_bug.cgi?id=16436


I will try and see if I can fix it. If not I will write to devel@ again.

Comment 10 Jonathan Wakely 2020-05-03 08:11:02 UTC
It looks like the problem is due to this change in GCC:

"GCC now defaults to -fno-common. As a result, global variable accesses are more efficient on various targets. In C, global variables with multiple tentative definitions now result in linker errors. With -fcommon such definitions are silently merged during linking."

Your change to the spec file changes the variable from multiple definitions to *no* definitions (just declarations).

You need to declare it in the header, and define it in exactly one file, as explained at https://gcc.gnu.org/gcc-10/porting_to.html#common

Comment 11 Jonathan Wakely 2020-05-03 08:30:09 UTC
I've pushed a fix to rawhide and f32.

rawhide build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44053828

f32 build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44053843

Comment 12 Fedora Update System 2020-05-03 08:36:44 UTC
FEDORA-2020-15a978c272 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-15a978c272

Comment 13 Jonathan Wakely 2020-05-03 08:37:23 UTC
Please test the update and add karma. If it works somebody should submit the patch upstream to XFCE.

Comment 14 Raphael Groner 2020-05-03 09:12:00 UTC
(In reply to Jonathan Wakely from comment #13)
> Please test the update and add karma. If it works somebody should submit the
> patch upstream to XFCE.

Thanks for the analysis. Though, I'd prefer a patch sent to upstream, or isn't needed because of special gcc10 flags in Fedora as downstream?

Comment 15 Raphael Groner 2020-05-03 09:13:08 UTC
(In reply to Jonathan Wakely from comment #10)
> It looks like the problem is due to this change in GCC:> You need to declare it in the header, and define it in exactly one file, as
> explained at https://gcc.gnu.org/gcc-10/porting_to.html#common

The new header should be sent to upstream as a patch.

Comment 16 Raphael Groner 2020-05-03 09:21:36 UTC
(In reply to Raphael Groner from comment #15)
> The new header should be sent to upstream as a patch.

Done.

Comment 17 Mukundan Ragavan 2020-05-03 15:03:31 UTC
(In reply to Jonathan Wakely from comment #10)
> It looks like the problem is due to this change in GCC:
> 
> "GCC now defaults to -fno-common. As a result, global variable accesses are
> more efficient on various targets. In C, global variables with multiple
> tentative definitions now result in linker errors. With -fcommon such
> definitions are silently merged during linking."
> 
> Your change to the spec file changes the variable from multiple definitions
> to *no* definitions (just declarations).
> 

Thanks for the fix Jonathan.

Comment 18 Fedora Update System 2020-05-04 07:05:28 UTC
FEDORA-2020-15a978c272 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-15a978c272`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-15a978c272

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 19 Fedora Update System 2020-05-05 05:35:44 UTC
FEDORA-2020-15a978c272 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.