| Summary: | dev-db/percona-server-8.0.22.13 fails to compile with gcc-11: error: ‘uintptr_t’ in namespace ‘std’ does not name a type | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
| Component: | Current packages | Assignee: | Gentoo Linux MySQL bugs team <mysql-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 732706 | ||
| Attachments: | build.log | ||
|
Description
Agostino Sarubbo
2021-04-28 14:43:32 UTC
Created attachment 703263 [details]
build.log
build log and emerge --info
Possible context of error(s): Could not find SASL Could not find LDAP -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) /var/tmp/portage/dev-db/percona-server-8.0.22.13/work/mysql/include/my_alloc.h:161:40: error: ‘uintptr_t’ in namespace ‘std’ does not name a type *** This bug has been marked as a duplicate of bug 786393 *** You filed this bug against gcc-11 tracker, i.e. package fails to build against gcc-11. This has been resolved via bug 786393. If you believe there is another bug, update your repository, build again and file new bug with new build.log and explain your finding. But this bug which is about gcc-11 is a duplicate which was resolved. *** This bug has been marked as a duplicate of bug 786393 *** (In reply to Thomas Deutschmann from comment #5) > You filed this bug against gcc-11 tracker, i.e. package fails to build > against gcc-11. This has been resolved via bug 786393. > > If you believe there is another bug, update your repository, build again and > file new bug with new build.log and explain your finding. > > But this bug which is about gcc-11 is a duplicate which was resolved. > > *** This bug has been marked as a duplicate of bug 786393 *** I really don't understand your behavior. Your commit has been done on: CommitDate: 2021-04-28 13:19:20 +0000 This build log reports: https://github.com/gentoo/gentoo/commit/df9692779fe7c9242d92ea9508312e18411a8e38 (Wed Apr 28 13:30:48 UTC 2021) Means that my portage has your commit and percona-server fails in the same way. So in my opinion it still fails with gcc-11 Your automated bug reports are really painful in comparison to other CI/tinderboxes because you drop the failure on the maintainer ("Possible context" is often wrong) and maintainer should figure out why build failed whereas bug reports from toralf for example are at the point.
As maintainer I am thankful for bug reports but I don't want to spend much time on them just to understand why this bug was filed.
Anyway, sorry for being harsh.
Reproduced as described, incoming fix.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ec859df7ec975ea0c31195ea336293675a22d840 commit ec859df7ec975ea0c31195ea336293675a22d840 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2021-04-28 18:24:18 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2021-04-28 18:26:22 +0000 dev-db/percona-server: fix building against GCC 11 Closes: https://bugs.gentoo.org/786462 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> dev-db/percona-server/Manifest | 2 +- dev-db/percona-server/percona-server-8.0.22.13.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (In reply to Thomas Deutschmann from comment #7) > Your automated bug reports are really painful in comparison to other > CI/tinderboxes because you drop the failure on the maintainer ("Possible > context" is often wrong) and maintainer should figure out why build failed > whereas bug reports from toralf for example are at the point. > > As maintainer I am thankful for bug reports but I don't want to spend much > time on them just to understand why this bug was filed. > > Anyway, sorry for being harsh. > > Reproduced as described, incoming fix. Hi, don't worry, no problem :) CI is running for a while and the scope is to catch issues after commit. Said that the first thing to think after see the bug is that the bug exists. The possible context of errors comes for an automatic grep about the common errors, so in this case: "Could not find" " error: " I don't know where your stats about "is often wrong" comes, but you need to do make the stats considering the total amount of the bugs. I understand that maintainer has to figure out what is happening if possible context of error does not help, but afterall the bug comes from a pretty-common system and the developer has the knowledge to understand the issue. The bugs form CI are just a preview of what users will hit in a while. Atm, since the amount of the bugs I do not have the time for doing it manually and I don't know if an automated solution will come at some point. If, anyway, there is a need to be excluded from reports, I support this functionality. Everyone can choose from get 10 automated bugs or 2 full-explained bugs and do not know the existence of the other 8. |