updating qgo failed twice for me in the install phase, with error messages like this: /usr/bin/install: cannot create regular file `/var/tmp/portage/games-board/qgo-1.5.2-r1/image//usr/share/games/qGo/sounds/enter.wav': File exists make[3]: *** [install-data-local] Error 1 make[3]: *** Waiting for unfinished jobs.... emerging with MAKEOPTS=-j1 works well, so it's likely a parallel build issue.
emerge --info please. Also if you are using ~arch portage, try w/ stable one. Thanks.
(In reply to comment #1) > emerge --info please. Same as in attachment #105426 [details]. > Also if you are using ~arch portage, Yes, 1.5.2-r1 is ~x86. > try w/ stable one. Thanks. Built latest stable (qgo-1.5.1) in a loop with -j10; failed at second iteration: /usr/bin/install: cannot create regular file `/var/tmp/portage/games-board/qgo-1.5.1/image//usr/share/mimelnk/text/sgf.desktop': File exists make[2]: *** [install-data-local] Error 1 make[2]: *** Waiting for unfinished jobs....
(In reply to comment #2) > Built latest stable (qgo-1.5.1) in a loop with -j10; failed at second > iteration: I meant stable portage, not stable qgo :) Why? See Bug 159355
(In reply to comment #3) > I meant stable portage, not stable qgo :) OK, I read hastily. Just had a failed build on a (mostly) stable x86 system, including sys-apps/portage-2.1.1-r2, again with -j10. It was the first loop iteration, so it seems rather easy to reproduce. /bin/install: cannot change permissions of `/var/tmp/portage/qgo-1.5.1/image//usr/share/qGo/sounds/connect.wav': No such file or directory make[3]: *** [install-data-local] Error 1 make[3]: *** Waiting for unfinished jobs.... In case others want to try this, here is my ebuild loop: for ((i=1; i<=20; ++i)); do MAKEOPTS=-j10 ebuild /usr/portage/games-board/qgo/qgo-1.5.1.ebuild \ clean install && continue echo "build $i failed" break done
Thanks.
Created attachment 106402 [details] tar.bz2 of logs from three failed builds with "File exists" errors I just had a closer look at some logs of failed builds (on my ~x86 system) and found a pattern there. Take the following example: /usr/bin/install -c -p -m 644 ./sgf.desktop /var/tmp/portage/games-board/qgo-1.5.1/image//usr/share/mimelnk/text/ /usr/bin/install -c -p -m 644 sgf.desktop /var/tmp/portage/games-board/qgo-1.5.1/image//usr/share/mimelnk/text//sgf.desktop /usr/bin/install -c -p -m 644 qgo.desktop /var/tmp/portage/games-board/qgo-1.5.1/image//usr/share/applnk/Games//qgo.desktop /usr/bin/install: cannot create regular file `/var/tmp/portage/games-board/qgo-1.5.1/image//usr/share/mimelnk/text/sgf.desktop': File exists make[2]: *** [install-data-local] Error 1 The file is installed once as "install ./$FILE $DIR/" and once as "install $FILE $DIR//$FILE" This pattern holds true for all the "File exists" errors I have here. I tarred and attached the complete logs in case you want to have a closer look.
I reran my loop on the stable x86 system. It failed at iteration 6 this time, at exactly the same point as in comment 4, again with a "No such file or directory" instead of a "File exists". So maybe there is a difference depending on portage version after all, or anyting else different in x86, but maybe it's just luck. A few more lines of context: /bin/install -c -p -m 644 ./connect.wav /var/tmp/portage/qgo-1.5.1/image//usr/share/qGo/sounds/ /bin/install -c -p -m 644 connect.wav /var/tmp/portage/qgo-1.5.1/image//usr/share/qGo/sounds/connect.wav /bin/install: cannot change permissions of `/var/tmp/portage/qgo-1.5.1/image//usr/share/qGo/sounds/connect.wav': No such file or directory make[3]: *** [install-data-local] Error 1 So again there are two related install invocations immediately following one another. How interference between the two can lead to the stated error message I cannot begin to imagine, but I still assume that to be the cause.
Created attachment 106418 [details] MAKEOPTS="-j10 -d" build of qgo-1.5.2-r1 (bz2-compressed) In trying to work out what make was actually doing, I added -d to the MAKEOPTS in my ebuild loop. However I'm overwhelmed by the information right now, and have little idea what half of this means, at least at first glance. I post it here so that more eyes can have a look. As this is almost 2M uncompressed, I had to compress it, so you have to download it to have a look.
I have looked at the log from comment #8 and I think I understand a bit more now about what is really going on. Have a look at src/sounds/Makefile from the work dir of an already compiled qgo 1.4.2-r1 build. There seem to be two targets that install the same files, install-data-local (which mentiones each of them seperately) and install-SoundsDATA (which is a shell loop over Sounds_DATA). I am a bit surprised that things work out when not doing the parallel build. Perhaps install only complains when the target file is touched while it is working on that very same file, so only when install calls overlap? Or maybe it's because the shell loop does no error checking, whereas make itself does. Makefile.in looks a lot like Makefile. Makefile.am includes install-data-local, included in a section that is marked "kdevelop will overwrite this part!!!". Anyone knows what that is about? Should we perhaps have the ebuild use kdevelop, or simulate that overwriting by kdevelop, or some such? Makefile.am doesn't directly mention install-SoundsDATA, but I guess that is inferred by automake from Sounds_DATA. Although I have the feeling I'm getting closer to the source of this problem, I don't know enough about install, automake, kdevelop and whatnot to know how best to address this. One fairly simple solution might be to change Makefile resp. Makefile.in so that install-data-am depends either on install-SoundsDATA or on install-data-local but not both. Similar for other subdirs with duplicate install targets. That'll need some test runs, though, which I don't have the time for right now. Maybe next week, unless someone else does this.
I put a fix in portage on qgo-1-5-3. Thanks
(In reply to comment #10) > I put a fix in portage on qgo-1-5-3. Thanks It's back in games-board/qgo-1.5.4, this time with templates/Makefile.in, resulting in errors for the target install-MimelinkDATA for me. A short find&grep tells me that's the only Makefile.in where a install-data-am still depends on install-data-local, so probably extending your patch to cover that file as well solves the issue. In the long run I guess it would be nice to have the issue resolved somewhere upstream. Do you know who would be responsible? The qgo devs? Kdevelop as comment #9 might suggest? Some autotools issue? As I haven't seen this happen in any other build, I'd assume qgo, but maybe you know more.
Should be fixed in CVS. reopen if it fails some other way.
