Bug 1471065
| Summary: | pcp-3.12.0-2.fc27 FTBFS: File not found: /builddir/build/BUILDROOT/pcp-3.12.0-2.fc27.x86_64/var/lib/pcp/pmdas/mysql | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Petr Pisar <ppisar> |
| Component: | pcp | Assignee: | Nathan Scott <nathans> |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | awilliam, brolley, fche, lberk, mgoodwin, nathans, pcp, ppisar, scox |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://koji.fedoraproject.org/koji/buildinfo?buildID=918186 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-07-17 13:55:24 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: | |||
| Bug Blocks: | 1467297 | ||
The build fails because the PCP autoconf/configure script fails to find MySQL support - from the build.log:
"checking if the mysql PMDA should be included... no"
That's in spite of the spec file dependency:
BuildRequires: perl(DBI) perl(DBD::mysql)
Which has always sufficed until now. The configure script uses:
dnl rpm build for mysql PMDA needs Perl DBI and DBD::mysql
if $pcp_perl_prog -e "use DBI" >/dev/null 2>&1
then
if $pcp_perl_prog -e "use DBD::mysql" >/dev/null 2>&1
then
pmda_mysql=true
fi
fi
Does that look incorrect now in any way to you, Petr? (do we need to be using a "mariadb" DBD module now perhaps?) Thanks!
I see. I thought it checked for C MySQL library. But it was an intermittent error when mariadb-libs changed MySQL library SONAME, but perl-DBD-MySQL has not yet been rebuilt. perl-DBD-MySQL is built against mariadb. Therfore I think this bug can be closed. I was only surprised that the build failed in the install section. Good configure script should have had --enable-mysql option and if the option were passed in the spec file, it would die in the build section instead. But as I can see pcp's configure.ac script does not support enabling/disabling features explicitly. Note, I tried sending a build of pcp to Rawhide but it failed only on s390x with a different error: === root === PCP_CONF=../../../src/include/pcp.conf PCP_ALT_CPP=../../../src/pmcpp/pmcpp.static ../../../src/newhelp/newhelp.static -n root_root -v 2 -o help < help newhelp.static: pmLoadASCIINameSpace(root_root, 1): Invalid argument so we still can't actually get it rebuilt against the new mariadb, it appears. https://koji.fedoraproject.org/koji/taskinfo?taskID=20586839 I did not try rebuilding the package because koschei reported some unsatisfied dependencies. But I doubt the s390x failure must be casued by the new mariadb. That can be caused by anything. Unfortunately pcp maintainer has never enabled pcp in koschei and koschei excludes s390x for some time because of resources. There were some other issues reported with s390x rebuilds around the same time, so it may have nothing to do with the package at all; I'll check in again tomorrow. I've been digging into the build failure a bit, and the s390x failure appears to be when running the pmcpp command during the build ... beyond that its still a bit of a mystery at this stage. Never seen an issue like this before FWLIW - we've build PCP on s390x for many years, so I'm wondering if some glibc or toolchain issue is either at fault, or exposing some latent underlying PCP build problem. I can certainly confirm this failure has nothing to do with mariadb/mysql though. cheers. (In reply to Nathan Scott from comment #6) > I've been digging into the build failure a bit, and the s390x failure > appears to be when running the pmcpp command during the build ... beyond > that its still a bit of a mystery at this stage. > Yeah - it looks like binaries that have just been built, are failing with simple things like fopen(3) ... I'd punt this issue will be toolchain related, specific to s390x, and will probably be resolved pretty quickly (appears to be quite a catastrophic failure) - waiting a few hours may well be the best option, Adam. Root cause doesn't seem to be an issue with the PCP build itself AFAICT anyway. cheers. |
pcp-3.12.0-2.fc27 fails to build in F27: Processing files: pcp-pmda-mysql-3.12.0-2.fc27.x86_64 RPM build errors: error: File not found: /builddir/build/BUILDROOT/pcp-3.12.0-2.fc27.x86_64/var/lib/pcp/pmdas/mysql File listed twice: /var/lib/pcp/config/pmie File listed twice: /etc/pcp/pmmgr/pmmgr.options File listed twice: /etc/pcp/pmwebd/pmwebd.options File listed twice: /var/lib/pcp/pmdas/perfevent/perfevent.conf File not found: /builddir/build/BUILDROOT/pcp-3.12.0-2.fc27.x86_64/var/lib/pcp/pmdas/mysql Child return code was: 1 EXCEPTION: [Error()] I think this is caused by mariadb-10.2 that changes API (see bug #1467297) and pcp silently skips MySQL support instead of reporting error.