You're receiving this bug because the package in Summary has produced _FORTIFY_SOURCE related warnings indicating the presence of a sure overflow in a static buffer.
Even though this is not always an indication of a security problem it might even be. So please check this out ASAP.
By the way, _FORTIFY_SOURCE is disabled when you disable optimisation, so don't try finding out the cause using -O0.
Your friendly neighborhood tinderboxer
Created attachment 248858 [details]
Created attachment 248865 [details, diff]
Patch to gkrellm-bgchanger-0.1.7 to add src_prepare to fix overflow and some QA issues
This patch addresses several issues with the upstream package:
- CC not set, so the simple name 'cc' was used. This disrupts cross-compilation.
- LDFLAGS misspelled as LFLAGS, so user LDFLAGS were not passed.
- CFLAGS had -O3 appended, overriding user's chosen -O level.
- Improper length passed to fgets, as reported in comment #0.
I contacted the maintainer for this package upstream, and he merged a patch I gave him which was simply produced by applying the ebuild change suggestion from Kevin.
We can expect a new release of gkrellm-bgchanger with the fixes, however the one point that is missing is... how should CC be set in the Makefile?
Since there is no configure, would it be fine to simply set "CC=gcc" or should it go like "if [ -z CC ]; then; CC=gcc; fi" or something else?
(In reply to comment #3)
> We can expect a new release of gkrellm-bgchanger with the fixes, however the
> one point that is missing is... how should CC be set in the Makefile?
I do not have a good answer to this, nor have I seen one proposed anywhere. A configure script can usually work out the proper value for CC based on the --build argument. Absent a configure script, I suggest leaving it as-is (call the compiler as $(CC) and do not set CC) and rely on whoever calls make (in this case, Portage) to set CC to a useful value. Writing a configure script just to support setting CC would be overkill.
Okay, upstream released gkrellm-bgchanger-0.1.10 which has the bugs mentioned on this bug-report fixed.
Renaming our current ebuild works just fine to install it, and it works fine in my system.
Can we add this in portage now so we can start the unmasking process?
Okay, I just put 0.1.10 in the tree and unmasked it.
Thank you for bringing the upstream release to my attention!