Bug 183711

Can you reproduce this on a 'by-hand' rpmbuild run, or only in mock?  I can't
see how this can happen, looking at
/usr/share/sgml/docbook/utils-*/backends/txt.  The error message comes from elinks.

Nope... only happens in mock ... strange thing is: diff from fc4 to fc5
docbook-utils does not show that much difference ... so I have no clue...

You can find out what commands docbook2txt executes by changing this:

docbook2txt ...

to this:

echo 'set -x'  >/tmp/txt
cat /usr/share/sgml/docbook/utils-*/backends/txt >>/tmp/txt
jw -f docbook -b /tmp/txt ...

As pointed on in bug 179852, elinks is executed as the html to text
backend. What would be interesting is "ls -la" of the current directory
after the build fails and before exiting from rpmbuild with error
condition. To see whether the html files have been created from sgml
successfully as one of the earlier steps done by docbook2txt.

Andreas, Tim, the debug build job I just submitted for kicks succeeded
and built the noarch package fine this time, because I used a wrapper
script around docbook2txt. Full strace included:

http://buildsys.fedoraproject.org/logs/fedora-4-extras/5772-wine-docs-0.9.9-1.fc4/noarch/build.log
http://buildsys.fedoraproject.org/logs/fedora-4-extras/5772-wine-docs-0.9.9-1.fc4/noarch/

[...]
[pid 27154] access("/dev/stdin", F_OK)  = -1 ENOENT (No such file or directory)
[pid 27154] access("/dev/stdin", F_OK)  = -1 ENOENT (No such file or directory)
[pid 27154] access("/dev/stdin", F_OK)  = -1 ENOENT (No such file or directory)
[pid 27154] gettimeofday({1141385884, 709338}, NULL) = 0
[pid 27154] stat64("/dev/stdin", 0xffcc90e8) = -1 ENOENT (No such file or direct
ory)
[pid 27154] open("/dev/stdin", O_RDONLY|O_NOCTTY|O_LARGEFILE) = -1 ENOENT (No su
ch file or directory)
[pid 27154] open("/dev/stdin.gz", O_RDONLY|O_NOCTTY|O_LARGEFILE) = -1 ENOENT (No
 such file or directory)
[pid 27154] open("/dev/stdin", O_RDONLY|O_NOCTTY|O_LARGEFILE) = -1 ENOENT (No su
ch file or directory)
[pid 27154] open("/dev/stdin", O_RDONLY|O_NOCTTY|O_LARGEFILE) = -1 ENOENT (No su
ch file or directory)
[pid 27154] open("/dev/stdin", O_RDONLY|O_NOCTTY|O_LARGEFILE) = -1 ENOENT (No su
ch file or directory)
[pid 27154] write(2, "ELinks: ", 8ELinks: )     = 8
[pid 27154] write(2, "No such file or directory", 25No such file or directory) =
 25
[pid 27154] write(2, "\n", 1
)           = 1
[...]

Hm... interessting...

Thank you Michael for your support even after or lets say especially after my
comments on #179852! Thanks.

Comparing with FC-3, it doesn't look for /dev/stdin:
http://buildsys.fedoraproject.org/logs/fedora-3-extras/5775-wine-docs-0.9.9-0.1.fc3/noarch/build.log

'links -dump' shouldn't require /dev/stdin,

# strace elinks -dump
file:///usr/share/doc/elinks-0.10.3/manual-0.82-en/index.html 2>&1 | grep -c stdin
0

 rpm -q elinks
elinks-0.10.3-3.1

and if I remove /dev/stdin it still works fine.

Well, I did my test on i386, but I don't think that something like this could be
arch specific.

See bug 179852 for the background. At present, we don't know why exactly
FC4 elinks fails in the way it does. It occurs in the Fedora Extras
buildsystem chroot, not with local builds. It is not arch-specific.
And IMO, elinks is not the primary culprit either.

Communication dead for more than one year, reported against FC4, works in FC5 ,
FC3... works with local build, I think I could close it as WONTFIX.