Bug 179852 - FC4 buildsys fails - FC4 mock succeeds - wine-docs package
FC4 buildsys fails - FC4 mock succeeds - wine-docs package
Status: CLOSED CANTFIX
Product: Fedora Infrastructure
Classification: Retired
Component: extras buildsys (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Seth Vidal
Jeremy Katz
:
Depends On:
Blocks: 195818
  Show dependency treegraph
 
Reported: 2006-02-03 08:43 EST by Andreas Bierfert
Modified: 2007-07-02 07:33 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-02 07:33:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andreas Bierfert 2006-02-03 08:43:28 EST
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...
Comment 1 Michael Schwendt 2006-02-03 10:39:59 EST
> 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".
Comment 2 Andreas Bierfert 2006-02-03 18:51:30 EST
altough this would not explain why it only pops up on fc4 I tried a BR: elinks
which does not solve anything...
Comment 3 Michael Schwendt 2006-02-03 21:06:26 EST
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?
Comment 4 Andreas Bierfert 2006-02-04 04:21:28 EST
(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.
Comment 5 Michael Schwendt 2006-03-03 07:47:47 EST
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
[...]
Comment 6 Michael Schwendt 2006-03-09 08:45:54 EST
Comments, please.
Comment 7 Michael Schwendt 2006-03-16 06:39:14 EST
*ping*
Comment 8 Thorsten Leemhuis (ignored mailbox) 2006-03-16 06:52:32 EST
Adding those /dev/std{err,in,out} seems like a good idea afaics.

Hmmm, ensc, what's you opinion on this? 
Comment 9 Michael Schwendt 2006-03-21 10:48:39 EST
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?
Comment 10 Seth Vidal 2006-03-21 11:14:06 EST
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.
Comment 11 Michael Schwendt 2006-03-21 13:04:08 EST
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.
Comment 12 Seth Vidal 2006-03-21 13:13:34 EST
I call upon the norse gods to grant me more time in any given week.

look. it doesn't work.

Comment 13 Toshio Kuratomi 2006-03-21 13:25:59 EST
I sent a message to fedora-buildsys-list.
Comment 14 Toshio Kuratomi 2006-03-21 14:21:36 EST
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')]:
Comment 15 Michael Schwendt 2006-03-21 15:19:19 EST
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.
Comment 16 Dan Williams 2006-03-21 16:45:28 EST
Committed to mock CVS HEAD (r1.38)
Comment 17 Dan Williams 2006-03-21 16:52:20 EST
Pushing fix as mock-0.4-7
Comment 18 Jeff Sheltren 2006-03-21 16:57:00 EST
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?
Comment 19 Dan Williams 2006-03-21 17:28:56 EST
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...
Comment 20 Jeff Sheltren 2006-03-21 18:02:20 EST
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
Comment 21 Michael Schwendt 2006-03-21 19:23:39 EST
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
Comment 22 Michael Schwendt 2006-04-03 10:48:44 EDT
> 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?
Comment 23 Michael Schwendt 2006-04-08 07:21:29 EDT
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

Comment 24 Seth Vidal 2006-04-11 04:07:53 EDT
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.
Comment 25 Clark Williams 2006-04-13 13:54:21 EDT
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.
Comment 26 Michael Schwendt 2006-04-13 14:44:51 EDT
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.
Comment 27 Clark Williams 2006-04-13 17:28:21 EDT
Sorry, I completely missed the devel == FC5 connection. Back to the drawing board
Comment 28 Clark Williams 2006-04-24 14:12:53 EDT
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.
Comment 29 Michael Schwendt 2006-04-24 15:02:10 EDT
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

Comment 30 Clark Williams 2006-05-01 16:08:29 EDT
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?

Comment 31 Michael Schwendt 2006-08-01 06:41:20 EDT
Still happens on the upgraded builders:
http://buildsys.fedoraproject.org/build-status/job.psp?uid=13494
Comment 32 Andreas Bierfert 2006-08-03 08:29:36 EDT
Still the same with 0.9.18:
http://buildsys.fedoraproject.org/build-status/job.psp?uid=13672
Comment 33 Toshio Kuratomi 2006-12-26 19:05:32 EST
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?

Note You need to log in before you can comment on or make changes to this bug.