creating /var/tmp/portage/dev-python/mysqlclient-1.3.10/work/mysqlclient-1.3.10-python2_7/temp.linux-x86_64-2.7 x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -Wall -fPIC -Dversion_info=(1,3,10,'final',0) -D__version__=1.3.10 -I/usr/include/mysql -I/usr/include/mysql/.. -I/usr/include/python2.7 -c _mysql.c -o /var/tmp/portage/dev-python/mysqlclient-1.3.10/work/mysqlclient-1.3.10-python2_7/temp.linux-x86_64-2.7/_mysql.o _mysql.c:29:23: fatal error: my_config.h: No such file or directory #include "my_config.h" ^ compilation terminated. ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 13.0-desktop-gnome_abi32+64_20170828-210916 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.4.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback) Available Ruby profiles: [1] ruby22 (with Rubygems) * java-config: The following VMs are available for generation-2: emerge -qpv dev-python/mysqlclient [ebuild N ] dev-python/mysqlclient-1.3.10 USE="-doc" PYTHON_TARGETS="python2_7 python3_4 -pypy -python3_5 -python3_6"
Created attachment 491412 [details] emerge-info.txt
Created attachment 491414 [details] dev-python:mysqlclient-1.3.10:20170901-000236.log
Created attachment 491416 [details] emerge-history.txt
Created attachment 491418 [details] environment
Created attachment 491420 [details] etc.portage.tbz2
Created attachment 491422 [details] temp.tbz2
I was able to reproduce this. I think it'd be best to just stablize 1.3.12 as that one builds properly. Can you verify 1.3.12 works for you too?
(In reply to Matthew Thode ( prometheanfire ) from comment #7) at least at unstable it compiles fine, at stable I do get a blocker with !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-libs/openssl:0 (dev-libs/openssl-1.0.2l:0/0::gentoo, ebuild scheduled for merge) pulled in by dev-libs/openssl:0=[static-libs?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (net-misc/curl-7.55.1:0/0::gentoo, ebuild scheduled for merge) >=dev-libs/openssl-1.0.1h-r2:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (net-nds/openldap-2.4.44:0/0::gentoo, ebuild scheduled for merge) >=dev-libs/openssl-1.0.0:0=[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?,static-libs?] required by (dev-db/mariadb-10.1.26:0/18::gentoo, ebuild scheduled for merge) >=dev-libs/openssl-1.0.1h-r2:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (net-libs/libssh2-1.7.0:0/0::gentoo, ebuild scheduled for merge) dev-libs/openssl:0=[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (app-arch/libarchive-3.3.1:0/13::gentoo, ebuild scheduled for merge) (dev-libs/openssl-1.0.2l:0/0::gentoo, installed) pulled in by >=dev-libs/openssl-1.0.1:0/0=[bindist] required by (net-misc/openssh-7.5_p1-r1:0/0::gentoo, installed) ^^^^^^^ >=dev-libs/openssl-1.0.1:0=[bindist=] required by (net-misc/openssh-7.5_p1-r1:0/0::gentoo, installed) ^^^^^^^^ It might be possible to solve this slot collision by applying all of the following changes: - dev-libs/openssl-1.0.2l (Change USE: +bindist)
That paste meant for this bug? The diff between the two versions is just the keywords
(In reply to Matthew Thode ( prometheanfire ) from comment #9) Yeah, but in the mean while 2000 more packages were installed, which makes it much harder for portage to find an upgrade path. The good news, I added all blocking packages as separate packages to the task list, let them being emerged and now I can confirm, that 1.3.12 builds here w/o problems. FWIW maybe I should increase --backtrack=200 to something higher value to give portage a higher chance to find a DAC next time ?
--complete-graph=y is better than --backtrack=999
Any news here please?
Could you try installing virtual/libmysqlclient and see if that provides the header (it should).
I don't use this, but it's a blocker to mariadb 10.2 stabilization, so i was curious.
The latest stable dev-python/mysqlclient-1.3.13 seems to build fine, closing for now. Thanks.
