Bug 1830261

Summary: After upgrade to Fedora 32, CPU Frequency Monitor fails to run
Product: [Fedora] Fedora Reporter: Jan Pazdziora (Red Hat) <jpazdziora>
Component: xfce4-cpufreq-pluginAssignee: Kevin Fenzi <kevin>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 32CC: aros, jwakely, kevin, nonamedotc, projects.rg
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: xfce4-cpufreq-plugin-1.2.1-6.fc32 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-05 05:35:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1830549    
Bug Blocks:    

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.