Bugzilla Bug 161362

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 [edit].

> 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 an attachment (id=106402) [edit]
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 an attachment (id=106418) [edit]
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.