https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: net-p2p/p2pool-3.6.2 overwrites CFLAGS/CXXFLAGS or adds uncommon ones. Discovered on: amd64 (internal ref: guru_ci) NOTE: This QA check is tinderbox-only, there is the list of the flags that should be dropped out, if you think it is a false positive please let me know.
Created attachment 870252 [details] build.log build log and emerge --info
guru_ci has reproduced this issue with version 3.7 - Updating summary.
guru_ci has reproduced this issue with version 3.8 - Updating summary.
guru_ci has reproduced this issue with version 3.9 - Updating summary.
guru_ci has reproduced this issue with version 3.10 - Updating summary.
Affected ebuild dropped in https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=81913da0f3a3d6a18dd6ea329ed6cc1f75c406fa
When you push a commit that resolves a bug (fixes it, makes it obsolete, etc.) please don't mark it as such before the change has been merged into the master branch. AFAIK, tinderboxes don't scan the dev branch so your bug might get reopened. Also, you can use one of the commit tags outlined here https://www.gentoo.org/glep/glep-0066.html#commit-messages to close bugs automatically once they get merged into master. Closing bugs with resolution OBSOLETE or PKGREMOVED is possible with the following syntax: `Closes: https://bugs.gentoo.org/NNNNNN (obsolete)` `Closes: https://bugs.gentoo.org/NNNNNN (pkgremoved)`
> Closing bugs with resolution OBSOLETE or PKGREMOVED is possible with the > following syntax: > `Closes: https://bugs.gentoo.org/NNNNNN (obsolete)` > `Closes: https://bugs.gentoo.org/NNNNNN (pkgremoved)` Oh wow, I didn't know you could do that. Thanks. Also. This was a misfile under obsolete when it should have been pkgremoved. Also, I am not even sure if this is resolved for the 4.0 version of p2pool. These issues pertain to p2pool/feather adding security flags. I remember emailing Agostino about this, and he essentially told me that I should patch out the hardening CFLAGS. So for a while I was patching out these, but I eventually gave up because this extra work of altering the cmakefiles every time they change it pretty much amounts to decreasing the security of the program. I'll write a patch for p2pool 4.0 if this issue comes up again. Is there a way to suggest that a package use certain build flags in the same way that a package can have certain USE flags on by default? Or to warn users if they have the upstream security flags turned off in the postinst? It seems like a bad idea to have the security flags disabled in the default behavior of these ebuilds considering that, as cryptocurrency software, they necessarily are open to the network (allowing for infiltration/exfiltration of data) and exfiltration of data amounts to exfiltration of money.
PKGREMOVED is only for removing a package altogether. I see there still are versions of net-p2p/p2pool in the tree, so not PKGREMOVED.
