Originally i was going to post a xanim package bug, but after testing some, the following odd effect appeared (shown by emerging xanim). Emerge behaves differently depending on package is in its own directory or in external portdir directory. Reproducible: Always Steps to Reproduce: 1. See additional information 2. 3. Actual Results: The two emerge attempts behaves differently Expected Results: The two emerge attempts should do the same To see the problem, i will describe two emerge attempts. In first attempt, xanim is emerged from normal repository, in second attempt, it is copied to local repository and emerged from there. If my knowledge is poor about using local portage, sorry for wasting time on this bug report. In first attempt, emerge xanim from normal repository. Not sure if matters, i tested with 2.80.1-r4 version. It does not compile, because: >>> Unpacking source... >>> Unpacking xanim2801.tar.gz to /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work >>> Unpacking xa2.0_cvid_linuxELFg21.o.gz to /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work/xanim2801/mods >>> Unpacking xa1.0_cyuv_linuxELFg21.o.gz to /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work/xanim2801/mods >>> Unpacking xa2.1_iv32_linuxELFg21.o.gz to /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work/xanim2801/mods /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/temp/environment: line 876: epatch: parancs nem található >>> Source unpacked in /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work >>> Compiling source in /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work/xanim2801 ... make CC=i686-pc-linux-gnu-gcc 'OPTIMIZE=-march=athlon-xp -O3 -pipe' LD_FLAGS=-Wl,-O1 'XA_DLL_DEF=-DXA_DLL -DXA_PRINT' XA_DLL_PATH=/usr/lib/xanim/mods XA_IV32_LIB=mods/xa2.0_cvid_linuxELFg21.o XA_CYUV_LIB=mods/xa1.0_cyuv_linuxELFg21.o XA_CVID_LIB=mods/xa2.1_iv32_linuxELFg21.o i686-pc-linux-gnu-gcc -I. -march=athlon-xp -O3 -pipe -DXSHM -DXA_DLL -DXA_PRINT -DXA_DLL_PATH=\"/usr/lib/xanim/mods\" -DXA_ZLIB -DXA_GSM -DXA_LINUX_AUDIO -DXA_PETUNIA -DXA_KPCD -I/usr/include -I/usr/include/X11 -c xanim.c i686-pc-linux-gnu-gcc -I. -march=athlon-xp -O3 -pipe -DXSHM -DXA_DLL -DXA_PRINT -DXA_DLL_PATH=\"/usr/lib/xanim/mods\" -DXA_ZLIB -DXA_GSM -DXA_LINUX_AUDIO -DXA_PETUNIA -DXA_KPCD -I/usr/include -I/usr/include/X11 -c xa_show.c i686-pc-linux-gnu-gcc -I. -march=athlon-xp -O3 -pipe -DXSHM -DXA_DLL -DXA_PRINT -DXA_DLL_PATH=\"/usr/lib/xanim/mods\" -DXA_ZLIB -DXA_GSM -DXA_LINUX_AUDIO -DXA_PETUNIA -DXA_KPCD -I/usr/include -I/usr/include/X11 -c xa_x11.c xa_x11.c: In function ‘xanim_events’: xa_x11.c:1434: error: incompatible type for argument 2 of ‘xanim_expose’ xa_x11.c:1474: error: incompatible type for argument 2 of ‘xanim_expose’ xa_x11.c:1478: error: incompatible type for argument 2 of ‘xanim_step_prev_action’ xa_x11.c:1481: error: incompatible type for argument 2 of ‘xanim_step_next_action’ xa_x11.c:1484: error: incompatible type for argument 2 of ‘xanim_step_prev_int_action’ xa_x11.c:1487: error: incompatible type for argument 2 of ‘xanim_step_next_int_action’ xa_x11.c:1490: error: incompatible type for argument 2 of ‘xanim_faster_action’ xa_x11.c:1493: error: incompatible type for argument 2 of ‘xanim_slower_action’ xa_x11.c:1496: error: incompatible type for argument 2 of ‘xanim_speed_reset_action’ xa_x11.c:1499: error: incompatible type for argument 2 of ‘xanim_dec_audio_5’ xa_x11.c:1502: error: incompatible type for argument 2 of ‘xanim_dec_audio_1’ xa_x11.c:1505: error: incompatible type for argument 2 of ‘xanim_inc_audio_1’ xa_x11.c:1508: error: incompatible type for argument 2 of ‘xanim_inc_audio_5’ xa_x11.c:1511: error: incompatible type for argument 2 of ‘xanim_mute_audio’ xa_x11.c:1514: error: incompatible type for argument 2 of ‘xanim_speaker_tog’ xa_x11.c:1517: error: incompatible type for argument 2 of ‘xanim_headphone_tog’ xa_x11.c:1529: error: incompatible type for argument 2 of ‘xanim_realize_remote’ make: *** [xa_x11.o] Error 1 OK, in this bug report, ignore those messages: "error: incompatible type for argument 2 ...", that is another story (that is why i wanted to post xanim bug first, but had to change my mind). The first oddity is this line: /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/temp/environment: line 876: epatch: parancs nem található "epatch: parancs nem található" message means command not found. Also important line is this: "make CC=i686-pc-linux-gnu-gcc 'OPTIMIZE=-march=athlon-xp -O3 -pipe' LD_FLAGS=-Wl,-O1 'XA_DLL_DEF=-DXA_DLL -DXA_PRINT' XA_DLL_PATH=/usr/lib/xanim/mods XA_IV32_LIB=mods/xa2.0_cvid_linuxELFg21.o XA_CYUV_LIB=mods/xa1.0_cyuv_linuxELFg21.o XA_CVID_LIB=mods/xa2.1_iv32_linuxELFg21.o" Notice the compiling parameter as well: -O3, probably it was determined by the previous line. I copied the ebuild and files/* file to my local repository (to fix things), and issued ebuild manifest pathToLocalEbuild. In second attempt, emerge xanim (ebuild is taken from local repository this time), and we get the following surprising result: >>> Unpacking source... >>> Unpacking xanim2801.tar.gz to /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work >>> Unpacking xa2.0_cvid_linuxELFg21.o.gz to /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work/xanim2801/mods >>> Unpacking xa1.0_cyuv_linuxELFg21.o.gz to /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work/xanim2801/mods >>> Unpacking xa2.1_iv32_linuxELFg21.o.gz to /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work/xanim2801/mods * Applying xanim-2.80.1-gcc41.patch ... [ ok ] >>> Source unpacked in /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work >>> Compiling source in /mnt/storage/---linux.hely---/var/tmp/portage/media-video/xanim-2.80.1-r4/work/xanim2801 ... i686-pc-linux-gnu-gcc -I. -march=athlon-xp -O2 -pipe -DXSHM -DXA_DLL -DXA_PRINT -DXA_DLL_PATH=\"/usr/lib/xanim/mods\" -DXA_ZLIB -DXA_GSM -DXA_LINUX_AUDIO -DXA_PETUNIA -DXA_KPCD -I/usr/include -I/usr/include/X11 -c xanim.c i686-pc-linux-gnu-gcc -I. -march=athlon-xp -O2 -pipe -DXSHM -DXA_DLL -DXA_PRINT -DXA_DLL_PATH=\"/usr/lib/xanim/mods\" -DXA_ZLIB -DXA_GSM -DXA_LINUX_AUDIO -DXA_PETUNIA -DXA_KPCD -I/usr/include -I/usr/include/X11 -c xa_show.c i686-pc-linux-gnu-gcc -I. -march=athlon-xp -O2 -pipe -DXSHM -DXA_DLL -DXA_PRINT -DXA_DLL_PATH=\"/usr/lib/xanim/mods\" -DXA_ZLIB -DXA_GSM -DXA_LINUX_AUDIO -DXA_PETUNIA -DXA_KPCD -I/usr/include -I/usr/include/X11 -c xa_x11.c Notice that "epatch: command not found" message disappeared(!), and patching was done, and the important line (see first attempt) disappeared, and compiling parameter changed from "-O3" to "-O2"! Could anyone explain what is going on? Tell me which files do you need and i will attach those.
(In reply to comment #0) > line 876: epatch: parancs nem található The ebuild was missing 'inherit eutils'. I've just fixed that. Why it's behaving differently is beyond me, so leaving this open for dev-portage@
My first guess is that your overlay overrides some eclasses from the main tree and those eclasses inherit eutils while the ones in the main tree do not.
I know this bug will not be easy to find, and this is not even the toughest. First of all, i do not know much about eclass. It is similar to ebuild, but eclass is for including. That is ebuilds can use eclasses, right? My overlay directory is quite small, it contains app-emulation/winex-transgaming, distfiles (for transgaming), media-video/xanim, and layman (make.conf in layman is empty). The xanim directory contains xanim-2.80.1-r4.ebuild, xanim-2.80.1-r5.ebuild (it is my version for testing), Manifest, metadata.xml (copy of original), files/xanim-2.80.1-gcc41.patch (copy of original), files/xanim-2.80.1-gcc412.patch (my version for testing). Considering the files, i did not override any eclass, so the problem must be elsewhere. Next idea?
If you use at least a recent version of portage-2.1.7.x then the --debug option will make it show a trace of the the eclass inheritance process and that should contain clues about how eutils.eclass got inherited (assuming inheritance of eutils.eclass is how the epatch function entered the ebuild enviroment).
