Take a look at the wine-docs builds here: http://buildsys.fedoraproject.org/build-status/indiv.psp?email=andreas.bierfert@lowlatency.de fc{3,4,5} have the same spec and fc3 and devel build fine, fc4 build(s) die(s) with: ELinks: No such file or directory make[1]: *** [winedev-guide.txt] Error 9 make[1]: Leaving directory `/builddir/build/BUILD/wine-docs-0.9.7/en' make: *** [en] Error 2 If I try an fc4 build locally with rpmbuild it works just fine and mock builds on i386 and x86_64 work fine as well. As other wine-docs builds (not 0.9.7) did not work on fc4 and hammer* I don't think it has to do with the builder-arch (for 0.9.7 being ppc). I don't have any clues as to what could be the reason for this...
> ELinks: No such file or directory Have you investigated with regard to this error message? ELinks is the real name of the lynx-like WWW browser "elinks".
altough this would not explain why it only pops up on fc4 I tried a BR: elinks which does not solve anything...
No, what I mean is that "ELinks: No such file or directory" is an error message printed by "elinks" which in turn is used as html2txt conversion backend by docbook-utils (sgml->html->txt): $ rpm -q --whatrequires elinks docbook-utils-0.6.14-4 So, BR elinks doesn't add anything. But it is run at build-time and prints "ELinks: No such file or directory" on conditions like this: $ links -dump missing.html ELinks: No such file or directory What tells you that the build system is the culprit and nothing in the docbook2txt tool-chain? OpenJade maybe?
(In reply to comment #3) > No, what I mean is that "ELinks: No such file or directory" is an > error message printed by "elinks" which in turn is used as html2txt > conversion backend by docbook-utils (sgml->html->txt): snip > What tells you that the build system is the culprit and nothing > in the docbook2txt tool-chain? OpenJade maybe? Ok I don't know weather it is a bug in the buildsystem or a bug triggered by the buildsystem but: All with the same spec: FC4,devel rpmbuild: works FC4,mock,i386,x86_64: works FC3,devel,buildsys: works FC4,buildsys: fails So the culprit for me is clearly somewhere regarding the buildsystem as it does not give the same result as FC4 builds locally and with mock. So if there is an error in the docbook2txt or OpenJade it is triggered by the buildsystem and not on other builds and thus a 'bug' which of course can be filed against that component once found but that at least from what I guess does require access to the buildsys and hence this bug imho should clearly be filed against the buildsys as is.
Seth, shouldn't mock set up /dev/std{in,out,err} and not just /dev/fd? [...] [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 [...]
Comments, please.
*ping*
Adding those /dev/std{err,in,out} seems like a good idea afaics. Hmmm, ensc, what's you opinion on this?
What exactly is necessary to get somebody from the FE buildsys staff to comment on this? This report is open since February 3rd, without a single comment from the assignee. Hello?
I do not have time to do this right now - post to buildsys list and ask for people with mock check in access: dcbw, clark williams, a couple of others, I think to check in a fix and push an update. I'm tapped out right now.
I'm not subscribed to that list, and Cc from within bugzilla doesn't work, please don't create additional hurdles inside the Fedora Project. I call upon the FE buildsys maintainers to please process this bugzilla ticket. wine-docs package for FC-4 continues to fail in the FE buildsys with an strace pointing to missing /dev/std{in,out,err} device links in the mock chroot: [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 It has not been examined why elinks searches for these devices or why it doesn't appear to do the same for FC-3 and FC-5. Anyway, wine-docs for FC-4 can't be built due to this issue with the build system.
I call upon the norse gods to grant me more time in any given week. look. it doesn't work.
I sent a message to fedora-buildsys-list.
Michael, Do you have a plague set up somewhere to get your trace or did you instrument the wine-docs spec and push it through the buildsys? Clark Williams just sent this patch to buildsys-list to see if it can be tested before committing. Index: mock.py =================================================================== RCS file: /cvs/fedora/mock/mock.py,v retrieving revision 1.37 diff -u -r1.37 mock.py - --- mock.py 15 Mar 2006 22:14:38 -0000 1.37 +++ mock.py 21 Mar 2006 19:12:40 -0000 @@ -555,6 +555,14 @@ if not os.path.exists(devpath): os.symlink('../proc/self/fd', devpath) + fd = 0 + for item in ('stdin', 'stdout', 'stderr'): + devpath = os.path.join(self.rootdir, 'dev', item) + if not os.path.exists(devpath): + fdpath = os.path.join('../proc/self/fd', str(fd)) + os.symlink(fdpath, devpath) + fd += 1 + for item in [os.path.join(self.rootdir, 'etc', 'mtab'), os.path.join(self.rootdir, 'etc', 'fstab'), os.path.join(self.rootdir, 'var', 'log', 'yum.log')]:
If I had a plague system, I could examine this myself. But I don't. And according to comment 4, this is not reproducible in FC-4 plain mock. Hence this problem report. And yes, the strace is from a modified wine-docs spec.
Committed to mock CVS HEAD (r1.38)
Pushing fix as mock-0.4-7
Well, I just tested this out under plague, and the build still fails. It does have a different error message from Elinks: ELinks: Unknown file type Does something special need to happen to those files?
In a mock chroot, does /proc/self/fd/0 a symlink to /dev/pts/3 or something like that? There seem to be multiple levels of symlinkage going on here...
It appears that there is nothing in /proc at all... $ pwd /var/lib/mock/fedora-4-x86_64-core/root/proc $ ls -l total 0 The following symlinks show up in /dev but they are pointing to the /proc/self/fd stuff which doesn't exist: fd, stderr, stdin, stdout
The full build log with strace output is this: http://buildsys.fedoraproject.org/logs/fedora-4-extras/5772-wine-docs-0.9.9-1.fc4/noarch/build.log Basically, what happens is that elinks successfully converts a html file to txt, but then "goes nuts", i.e. starts looking for /dev/stdin and fails. The wine-docs-0.9.10-0.1.fc4 package spec file now is hacked to work around the buildsys problem, so elinks' fatal exit code is ignored. This enables us to build wine-docs for FC-4, strace included, too: http://buildsys.fedoraproject.org/build-status/job.psp?uid=6636
> The following symlinks show up in /dev but they are pointing to the > /proc/self/fd stuff which doesn't exist: > fd, stderr, stdin, stdout Pardon? Is /proc not mounted inside the chroot at all? [...] FC-4 buildsys is still lacking /dev/stdin: http://buildsys.fedoraproject.org/logs/fedora-4-extras/7170-wine-docs-0.9.11-0.1.fc4/noarch/build.log The ugly hack in the wine-docs package is still enabled in order to get a successful build for FC-4. What would happen inside the strace if the buildsys created /dev/stdin?
When will the latest mock be installed in the FE buildsys in order to see progress here? $ rpm -q mock mock-0.4-8.fc4 ==> Cannot reproduce any build problems due to /dev/stdin ==> It's the mock version which creates /dev{/stdin,/stdout,/stderr} ==> In the chroot, I see correct symlinks and /proc is mounted, too: + ls -la /dev /proc /dev: total 8 drwxr-sr-x 3 mockbuild 102 4096 Apr 8 07:19 . drwxr-sr-x 21 mockbuild 102 4096 Apr 8 06:52 .. lrwxrwxrwx 1 mockbuild 102 15 Apr 8 06:39 fd -> ../proc/self/fd crw-rw-rw- 1 root 102 1, 7 Apr 8 06:39 full prw------- 1 root root 0 Apr 27 2005 initctl crw-rw-rw- 1 root 102 1, 3 Apr 8 06:39 null crw-rw-rw- 1 root 102 5, 2 Apr 8 06:39 ptmx drwxr-xr-x 2 root root 0 Apr 8 04:05 pts crw-r--r-- 1 root 102 1, 9 Apr 8 06:39 random lrwxrwxrwx 1 mockbuild 102 17 Apr 8 07:19 stderr -> ../proc/self/fd/2 lrwxrwxrwx 1 mockbuild 102 17 Apr 8 07:19 stdin -> ../proc/self/fd/0 lrwxrwxrwx 1 mockbuild 102 17 Apr 8 07:19 stdout -> ../proc/self/fd/1 crw-rw-rw- 1 root 102 5, 0 Apr 8 06:39 tty crw-r--r-- 1 root 102 1, 9 Apr 8 06:39 urandom crw-rw-rw- 1 root 102 1, 5 Apr 8 06:39 zero /proc: total 786378 dr-xr-xr-x 124 root root 0 May 23 2005 . drwxr-sr-x 21 mockbuild 102 4096 Apr 8 06:52 .. dr-xr-xr-x 5 root root 0 Apr 8 07:19 1 dr-xr-xr-x 5 root root 0 Apr 8 07:19 10 [-snip-] dr-xr-xr-x 5 mockbuild mockbuild 0 Apr 8 07:19 21932 [-snip-] lrwxrwxrwx 1 root root 64 Apr 8 07:19 self -> 21932 [-snip-] $ rpm -q mock mock-0.4-6.fc4 ==> Cannot reproduce any problems with /dev/stdin either just to ==> confirm Andreas' observations from on 2006-02-04 -- the strace'd ==> elinks does NOT look for /dev/stdin here -- so whatever ==> happens in the Fedora Extras FC-4 buildsys is not reproducible ==> with a local mock build on FC-4
okay - if I'm reading this correctly we need: a new version of mock on the builders in order to verify if the patch that's been applied fixes the problem for building inside plague.
I setup a plague server on an FC5 x86_64 system to try and duplicate the build failure for wine-docs. I used the plague*-0.4.4.1-1.fc5 packages with mock-0.4.8.fc5 (with the /dev/std{in,out,err} changes) and the build completed successfully. Before I try and track down an availble FC4 system and do this again, I'd like to see the results of pushing the mock-0.4.8* for fc4 out to the build system.
Please see comment 4. The same wine-docs package has never before failed for FC-5 (still called "devel" at the time this ticket was new). FC-4 buildsys is the one place where it fails.
Sorry, I completely missed the devel == FC5 connection. Back to the drawing board
I duplicated the failure last week on a plague system running FC5. mock-0.4-8.fc5 plague-0.4.4.1-1.fc5 plague-builder-0.4.4.1-1.fc5 I can cut the mock invocation line out of the debug output and run it directly with no failure, but the plague build dies with the mysterious elinks message "ELinks: Unknown file type". Looking at the elinks source (src/encoding/encoding.c), the only place this message can be generated is if elinks was told to operate on a non-regular file and the file isn't stdin as a pipe and an option to allow special files isn't set: } else if (!S_ISREG(stt.st_mode) && !is_stdin_pipe(&stt, filename) && !get_opt_bool("protocol.file.allow_special_files")) { state = S_FILE_TYPE; } I'd like to figure out on what file elinks is operating on and why that file is different in a buildsystem chroot, but I'm not sure how best to do that. I also haven't tracked down whether somehow the option is different in a mock and a plague chroot. Suggestions welcome.
elinks is used as the html2txt backend by docbook2txt ( /usr/share/sgml/docbook/utils-0.6.14/backends/txt ) like the following: links -dump /tmp/something.html > something.txt
The output in the build log shows that the failure is in trying to generate the winedev-guide.txt file. The winedev-guide.sgml source has been successfully turned into HTML, PDF and Postscript by this point, so it's not a problem with the form of the source (unless the source has been whacked somehow). It happens on the first invocation of docbook2txt (which runs the elinks command internally). The only think I can think of do it is put a printf in the elinks source (to print out the name of the file it thinks is bad), regenerate the SRPM, put that SRPM into a local repository and then restart the build. Any other ideas?
Still happens on the upgraded builders: http://buildsys.fedoraproject.org/build-status/job.psp?uid=13494
Still the same with 0.9.18: http://buildsys.fedoraproject.org/build-status/job.psp?uid=13672
At the moment, fc4 builds of wine-docs are stalling with the strace hack. http://buildsys.fedoraproject.org/build-status/job.psp?uid=24250 ran for 6 days. Dennis Gilmore and I have killed it as it was hung up with strace waiting for docbook2txt. Seeing as builds for FC4 and below are going to be disabled on January 1 is there much point to continuing to try and track down this problem?