Please post: 

- The command line you used for the failing builds
- The build and root logs for the failing builds

It would also be helpful if you'd run the failing mock command, adding the --trace option and post that output as well.

Created attachment 484210 [details]
build log

The command line for both builds is the same:
mock rebuild /mnt/rhel/6.0/os/source/disc1/SRPMS/binutils-2.20.51.0.2-5.11.el6.src.rpm

Created attachment 484211 [details]
root log

Created attachment 484212 [details]
mock trace

I can confirm the bug, I'm seeing it here as well.

The problem is that the unit test don't pass, the failures say "assembly failed".

Trying to search for the cause, I've found a thread on the LFS mailing-list where people said the problem might come from not having pts properly mounted.

I've tried the following:
$ mock shell -r 'fedora-rawhide-x86_64'
[... snip ...]
mock-chroot> mount
mock_chroot_proc on /proc type proc (rw,relatime)
mock_chroot_sysfs on /sys type sysfs (rw,relatime,seclabel)
/dev/mapper/vg_bochecha-lv_root on /var/cache/yum type ext4 (rw,relatime,seclabel,barrier=1,data=ordered)
/dev/mapper/vg_bochecha-lv_root on /tmp/ccache type ext4 (rw,relatime,seclabel,barrier=1,data=ordered)
mock_chroot_devpts on /dev/pts type devpts (rw,relatime,seclabel,gid=5,mode=620,ptmxmode=666)
mock_chroot_shmfs on /dev/shm type tmpfs (rw,relatime,rootcontext=unconfined_u:object_r:mock_var_lib_t:s0,seclabel)
mock-chroot>

$ mock shell -r 'epel-6-x86_64'
[... snip ...]
mock-chroot> mount
mock-chroot>

Nothing is mounted in the EL6 chroot. Could that be the cause of the problem?

(In reply to comment #5)
> I can confirm the bug, I'm seeing it here as well.
> 
> The problem is that the unit test don't pass, the failures say "assembly
> failed".
> 
> Trying to search for the cause, I've found a thread on the LFS mailing-list
> where people said the problem might come from not having pts properly mounted.
> 
> I've tried the following:
> $ mock shell -r 'fedora-rawhide-x86_64'
> [... snip ...]
> mock-chroot> mount
> mock_chroot_proc on /proc type proc (rw,relatime)
> mock_chroot_sysfs on /sys type sysfs (rw,relatime,seclabel)
> /dev/mapper/vg_bochecha-lv_root on /var/cache/yum type ext4
> (rw,relatime,seclabel,barrier=1,data=ordered)
> /dev/mapper/vg_bochecha-lv_root on /tmp/ccache type ext4
> (rw,relatime,seclabel,barrier=1,data=ordered)
> mock_chroot_devpts on /dev/pts type devpts
> (rw,relatime,seclabel,gid=5,mode=620,ptmxmode=666)
> mock_chroot_shmfs on /dev/shm type tmpfs
> (rw,relatime,rootcontext=unconfined_u:object_r:mock_var_lib_t:s0,seclabel)
> mock-chroot>
> 
> $ mock shell -r 'epel-6-x86_64'
> [... snip ...]
> mock-chroot> mount
> mock-chroot>
> 
> Nothing is mounted in the EL6 chroot. Could that be the cause of the problem?

mount is not always reliable inside the chroot. What are the contents of /proc/mounts?

(In reply to comment #6)
> (In reply to comment #5)
> > Nothing is mounted in the EL6 chroot. Could that be the cause of the problem?
> 
> mount is not always reliable inside the chroot. What are the contents of
> /proc/mounts?

The exact same thing as in F15 (I diffed the files, no difference at all) :
$ cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/mapper/vg_bochecha-lv_root / ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
none /selinux selinuxfs rw,relatime 0 0
udev /dev devtmpfs rw,seclabel,relatime,size=2014984k,nr_inodes=503746,mode=755 0 0
udev /dev devtmpfs rw,seclabel,relatime,size=2014984k,nr_inodes=503746,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,gid=5,mode=620,ptmxmode=666 0 0
tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0
/proc /proc proc rw,relatime 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
/sys /sys sysfs rw,seclabel,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/sda1 /boot ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
/dev/mapper/vg_bochecha-lv_home /home ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
gvfs-fuse-daemon /home/mbridon/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0
mock_chroot_proc /proc proc rw,relatime 0 0
mock_chroot_sysfs /sys sysfs rw,seclabel,relatime 0 0
/dev/mapper/vg_bochecha-lv_root /var/cache/yum ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
/dev/mapper/vg_bochecha-lv_root /tmp/ccache ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
mock_chroot_devpts /dev/pts devpts rw,seclabel,relatime,gid=5,mode=620,ptmxmode=666 0 0
mock_chroot_shmfs /dev/shm tmpfs rw,rootcontext=unconfined_u:object_r:mock_var_lib_t:s0,seclabel,relatime 0 0

This not involves this current mock version but also:
mock-1.0.16-1.el5.noarch from EPEL Testing also.

Arch tis i686: The build host does not matter; => EL5 it always seems to fail the exception being Non-Root Build under EL6.

/logs/#93-binutils-2.20.51.0.2-5.11.el6.src.rpm.log:5301:RPM build errors:

...
M5)E5;\8QX:S-8I=5AL3OGV03Z61="6"EB>Q]_2.[N[B.X>OHJSSEE%'@ZF8I
BXF/BR"IC%#3"QB3R5=:D_?@JU+9;T__Q=R13A0D$I7RJD```
`
end
+ rm -f binutils-i686-redhat-linux.tar.bz2 binutils-i686-redhat-linux-binutils.sum binutils-i686-redhat-linux-gas.sum binutils-i686-redhat-linux-ld.sum binutils-i686-redhat-linux-binutils.log binutils-i686-redhat-linux-gas.log binutils-i686-redhat-linux-ld.log
+ test 2 -eq 0
error: Bad exit status from /var/tmp/rpm-tmp.4PDsmu (%build)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.4PDsmu (%build)
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps builddir/build/SPECS/binutils.spec']
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.4/site-packages/mock/util.py", line 327, in do
    raise mock.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode)
Error: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps builddir/build/SPECS/binutils.spec']
LEAVE do --> EXCEPTION RAISED
...

This is generated under an El5 Build Host setup for building EL6.  Even if the Build Host is EL6 it still happens.

Addition to comment # 8

 mock -r $CONF binutils-2.20.51.0.2-5.11.el6.src.rpm --resultdir=$DIR --without testsuite

Builds the srpm in mock-1.0.16-1.el5.noarch but does not fix the failing test problem. SELinux Disabled - Kernel NEVR does not matter either. As is this is a non RH Kernel.

mock-chroot> uname -a
Linux HOSTNAME 2.6.33.7-rt29.55.el5 #1 SMP PREEMPT RT Tue Mar 15 18:45:52 EDT 2011 i686 i686 i386 GNU/Linux

mock-chroot> cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,relatime,errors=continue,user_xattr,acl,data=writeback 0 0
/dev /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
/proc /proc proc rw,relatime 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0
/sys /sys sysfs rw,relatime 0 0
/dev/sdb1 /home ext3 rw,relatime,errors=continue,user_xattr,acl,data=writeback 0 0
/dev/sda1 /boot ext3 rw,relatime,errors=continue,user_xattr,acl,data=writeback 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
HOHST_LOCATION_SCRUBBED nfs rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,port=65535,timeo=14,retrans=2,sec=sys,mountport=65535,mountproto=,addr=x.x.x.x 0 0
/etc/auto.misc /misc autofs rw,relatime,fd=7,pgrp=4881,timeout=300,minproto=5,maxproto=5,indirect 0 0
-hosts /net autofs rw,relatime,fd=13,pgrp=4881,timeout=300,minproto=5,maxproto=5,indirect 0 0
mock_chroot_proc /proc proc rw,relatime 0 0
mock_chroot_sysfs /sys sysfs rw,relatime 0 0
mock_chroot_devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=666 0 0
mock_chroot_shmfs /dev/shm tmpfs rw,relatime 0 0

Created attachment 487638 [details]
Strace of all Mock Children

Trace output of why this fails.  The Mock Chroot Subsystem (Linux Subsystem) can not pass calls to tty from User to Kernel space. This is the Mock in EPEL testing but effects also the version originally reported on.

This is a Strace on all child processes.

strace -o strace-mock.log -ff -p 30273

Created attachment 487643 [details]
binutils build completes "--with testsuite" logs

(In reply to comment #11)
> Created attachment 487643 [details]
> binutils build completes "--with testsuite" logs

John, am I correct that the only way you've been able to get binutils to build with the current mock is to turn off the test suite?

Created attachment 487648 [details]
Example Patch Case

If you plunder through all the strace logs you can clearly see why it fails "tty" there is not one in the root to pass calls around. IE can't open tty...  Patch may need more "security" added. It's just a working case and security needs to examined which has not been done... ""newinstance""?

(In reply to comment #12)
> (In reply to comment #11)
> > Created attachment 487643 [details]
> > binutils build completes "--with testsuite" logs
> 
> John, am I correct that the only way you've been able to get binutils to build
> with the current mock is to turn off the test suite?

See the rest of my replies..

(In reply to comment #14)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Created attachment 487643 [details]
> > > binutils build completes "--with testsuite" logs
> > 
> > John, am I correct that the only way you've been able to get binutils to build
> > with the current mock is to turn off the test suite?
> 
> See the rest of my replies..

Clark, 

Yes but,

Let me rephrase that to keep out confusion. If someone was to download mock as is from EPEL it would not build in it.

It will infact build with the example patch I attached as can be seen the tests past with it. Now having said that I have not tried it on 2.6.18 kernel which is production under EL5.  Fedora I have not tried either but my guess is it will work under fedora also (the patch)? As is the error is /seems the same.

An "strace" attached to a fedora machine to mock would be nice to see.

Does this help better now?

Created attachment 488047 [details]
Mock patch for 2.6.18 el5 and kernel-rt 2.6.33.7 el5

 # make the device node for el4 and el5
-        if mock.util.cmpKernelEVR(kver, '2.6.18') <= 0:
+        if mock.util.cmpKernelEVR(kver, '2.6.19') <= 0:

It has to be 2.6.19 at least to create the node under el5.

The 2.6.33 just needed to re-enable the comented out sections.

Nothing however was tested under Fedora. Only an EL5 build host.

Created attachment 488048 [details]
Build logs for binutils under an EL5 build host

Clark, any news on this?

I can confirm that the patch provided by John in attachment 487648 [details] allows me to build binutils. In fact, only uncommenting the lines 424 to 430 in backend.py is sufficient.

Note: I am building the EL6 binutils in an EL6 chroot on a Fedora 14 host system, with mock-1.1.9-1.

This also fixes several other build issues for me, all of EL6 packages:
- automake
- gcc
- libssh2 (this one builds real fast if you want to reproduce the issue)

However, digging through the mock git logs, it seems like these lines were commented out in commit 9afe90fec2118689e20af652d3756c93b9d06bdc to fix this issue:
    https://bugzilla.redhat.com/show_bug.cgi?id=613392

So blindly uncommenting them is obviously not the good solution in that case, we can't fix build for some packages but not for others. :-/

Clark & (In reply to comment #18)

While that patch may work it is not the end all of getting mock to rip through every package because that patch or umcommenting those lines *WILL* actually cause other package builds to flat out fail also.

The host build arch does not matter here. What really matters is the getting the chroot communicating correctly with the host subsystem versus the hosts running kernel version because it differs greatly. With out this packages with "%check" and "make check" just flat out die in the wait channel.  There are several packages that need to run in Interactive Mode and at this state it want happen.

I apologize for being radio-silent for the last week (power was out for 5 days). 

John, I've been looking at this on and off for some time trying to figure out the right thing to do with /dev/tty and /dev/ptmx and have yet to come up with a satisfactory answer. 

Setting up the chroot with special files just like on stock hosts doesn't seem to work. Setting up /dev/tty and /dev/ptmx as symlinks to /dev/ptx/ptmx worked in some cases but not all. 

I did a build of a failing package,  attached with gdb to the hung process and found that it seemed to be blocked while calling tcsetattr(3). Didn't get any further information than that, due to not having the appropriate debug files. 

What I'd like to do now, is take a chroot that was generated by mock (with special device files for /dev/tty and /dev/ptmx) and see if I can duplicate the hang using just the chroot(1) command. If I cannot, then there's something we're doing in mock that confuses the termios(3) system. 

Have you (or anyone else) done that?

According to tcsetattr() it can only fail or pass.

The tcgetattr() function shall fail if:

[EBADF]
    The fildes argument is not a valid file descriptor.
[ENOTTY]
    The file associated with fildes is not a terminal.

It's getting back a return od "1" and failing.

What I wonder is are chroot components are getting the correct file contexts set inside of it? Thus when the file attrs are wrong will cause a fail (the compare it made failed).

From having a look at the differing subsystem in kernel versions they differ widely and are touchy.

You said you you played around with it, have you tried an attempt of forcing a return 0? On "0" as you prolly know would continue on. What all have you tried?

If you have any mock test srpms I would be glad to spin them around.

>I did a build of a failing package,  attached with gdb to the hung process and
>found that it seemed to be blocked while calling tcsetattr(3).

What was the calling process (what parent,whos child)?  What I am getting at is something else maybe blocking the calls. 

Is there a devel list for mock?

the mailing list is the buildsys list. Here's a link to an email I sent last month:

http://lists.fedoraproject.org/pipermail/buildsys/2011-April/003636.html

So far no one has replied, probably because tty issues are so radioactive no one wants to touch it and risk exposure :)

Anyway, that email describes what I have done so far.

All, 

I've been poring over my Advance Programming in the UNIX Environment, looking at the process hierarchy and controlling terminals. I think that the problem stems from us possibly still having a controlling tty inside the chroot. I made the following change to util.py:

diff --git a/py/mock/util.py b/py/mock/util.py
index 222ae0a..a9a2414 100644
--- a/py/mock/util.py
+++ b/py/mock/util.py
@@ -335,7 +335,7 @@ class ChildPreExec(object):
         self.gid = gid
 
     def __call__(self, *args, **kargs):
-        os.setpgrp()
+        os.setsid()
         condPersonality(self.personality)
         condChroot(self.chrootPath)
         condDropPrivs(self.uid, self.gid)


This change ensures that we have no controlling terminal inside the chroot environment, so any attempt to read from stdin or manipulate the tty in any way should fail (not hang, like we've seen before). With this bash, Conn and perl-ReadTermKey will now build. 

I attempted to build the binutils listed above in my F14 x86_64 config but had assembly failures. I was hoping that I could get you guys to try making the above change and see if it gets you past the build failure for binutils? The quickest-and-dirtiest way would be just to edit:

    /usr/lib/python<pyver>/site-packages/mock/util.py

and make the change.

(In reply to comment #23)


>      def __call__(self, *args, **kargs):
> -        os.setpgrp()
> +        os.setsid()
>          condPersonality(self.personality)
>          condChroot(self.chrootPath)
>          condDropPrivs(self.uid, self.gid)

Build Host is EL5 building for target platorm el6; mock-1.0.16-1; adding in the above code change allows binutils and bash to build. That also has the comments taken out like the example patch attached to the bz above.


> should fail (not hang, like we've seen before). With this bash, Conn and
> perl-ReadTermKey will now build. 

Build Host is EL6 building for EL6;mock-1.1.8-1; all code is box stock except for os.setsid(). Just a preliminary bash does not seem to be able to build. It hanges, having to do a reboot to rid the mock trash left behind.  Will test it more during this week. Binutils will build.

Fedora Build Hosts I can not speak for (I have none). Maybe someone else can check those.

Seems looking at strace the return is -1 as a Fail to Read but it hangs EL6 build host. So what works for one does not for the other. Each Platform is totally different thus requirs different needs.

John,

Please grab my git 'work' branch and give that a try on RHEL6. If that still hangs we'll keep this bug going and continue the /dev/tty saga...

(In reply to comment #25)
> John,
> 
> Please grab my git 'work' branch and give that a try on RHEL6. If that still
> hangs we'll keep this bug going and continue the /dev/tty saga...

Ok I did a check out of the work branch:

git clone git://git.fedorahosted.org/git/mock.git work

The spec file needed a small fix; the "@" for major minor etc.. 
The work branch did not have the "build" directory in it. So I then did a:
 
git clone git://git.fedorahosted.org/git/mock.git mock

Made binary and srpm, (i can give a link to it if needed).

mock-1.1.9-1.el6.noarch.rpm

Mock has another small error.  It says:
INFO: mock.py version 1.1.8 starting
But it really is 1.1.9-1 (well the spec file is at that NVR), no problem to iron out and does not effect build.

Builds:
bash-4.1.2-3.el6.src.rpm

Fails To Build: but not a hang this time around.
binutils-2.20.51.0.2-5.11.el6.src.rpm fail

I have not looked to see if you had the comments, commented or un commented (i'm guessing commented out)?  I'll take a looksee at them on Monday.

The version number thing is a consequence of building/running from the development tree; before you build the rpm, run 'sh autogen.sh && ./configure' to make sure version numbers are up to date.

I think that the new session is what we want to do. It makes no sense for mock to maintain a controlling terminal inside the chroot, since that's supposed to be a non-interactive environment (except for --shell, which actually calls /usr/sbin/chroot to run a shell). 

You might want to try a later/earlier binutils to see if it's actually a package problem.

So, I've been trying the work branch on this.

--- Side comment -------------------------------------------------------------
When using the HEAD of this branch, I can't build **anything** if I have removed completely the contents of /var/{lib,cache}/mock/

I get a traceback about mock not having permissions to create the /var/cache/mock/$config/ccache/ folder.

I needed to revert commit 7fde070a13151370dd664ac686383bb1360c675a to make mock able to build anything.

Do you want a separate bugzilla entry for this?
--- End of side comment ------------------------------------------------------

I built the work branch of mock on my Fedora 14 host, and I'm trying to build some packages in an EL6 chroot.

I tried rebuilding libssh2-1.2.2-7.el6, and it failed with the exact same issue during the unit tests:
    Failed requesting pty

Same with the automake build:
    ERROR: The system has no more ptys.  Ask your system administrator to create more.

Also, gcc still fails most of its unit tests (the build is not blocked by the test failures as there seem to always be a few of them, however **much** more tests fail in mock because of this bug).

And of course, the binutils build fails with the same errors as mentioned in the initial comment.

On the other hand, building bash worked without hanging, so at least bug 613392 (initial fix for this had triggered this issue) is still fixed in this branch.

(In reply to comment #27)
> You might want to try a later/earlier binutils to see if it's actually a
> package problem.

I tried building with mock ('work' branch) the F15 versions of the binutils, automake and libssh2 packages, and the results are mixed:
- newer binutils builds fine
- newer libssh2 still fails to build with message "Failed requesting pty"
- newer automake still fails to build with message "The system has no more ptys.  Ask your system administrator to create more."

I'll try to see if the newer binutils succeeds because it doesn't do any more those same tests that failed before, or because you fixed the issues it had.

(In reply to comment #28)
> --- Side comment -------------------------------------------------------------
> When using the HEAD of this branch, I can't build **anything** if I have
> removed completely the contents of /var/{lib,cache}/mock/
> 
> I get a traceback about mock not having permissions to create the
> /var/cache/mock/$config/ccache/ folder.
> 
> I needed to revert commit 7fde070a13151370dd664ac686383bb1360c675a to make mock
> able to build anything.
> 
> Do you want a separate bugzilla entry for this?
> --- End of side comment ------------------------------------------------------

Remi gave me the URL of bug 700983 related to this, I made a comment with a patch there.

I've just built mock 1.1.11 which removes the 'newinstance' mount modifier from the mount of the devpts filesystem inside the chroot. I believe this may clear up some of our pty/tty problems. 

Please test when it makes it to testing.

I just tested mock 1.1.11 on the packages that were having issues with pty in previous mock versions.

The problematic packages were:
- automake
- binutils
- gcc
- libssh2
- perl-IO-Tty
- perl-POE

Of those, I still have to test gcc, but it takes such a long time to build that I thought I would give the results for the others in the meantime.

All of the above packages (except gcc, wait and see) build successfully in EL6 chroots created with mock 1.1.11. :)

(In reply to comment #30)
> I've just built mock 1.1.11 which removes the 'newinstance' mount modifier from
> the mount of the devpts filesystem inside the chroot. 

This makes it bind to the hosts running kernel? and not a good idea? Comments?

Well, for one there's only one kernel running (the hosts). For another, looking a the code that implement's 'newinstance' in the kernel, it looks like it's really meant for a private instance of devpts, but when you're in the chroot you need a public instance. That's what tipped me over to getting rid of it (that and the fact that it makes pty's work again :)).

And for what is worth, gcc build finished, and it looks **much** saner with mock 1.1.11:

$ grep -E '^# of unexpected failures' gcc-build-mock1111.log | awk '{s+=$NF}END{print s}'
196
$ grep -E '^# of unexpected successes' gcc-build-mock1111.log | awk '{s+=$NF}END{print s}'
140

Whereas with mock 1.1.10:
$ grep -E '^# of unexpected successes' gcc-build-mock1110.log | awk '{s+=$NF}END{print s}'
700
$ grep -E '^# of unexpected failures' gcc-build-mock1110.log | awk '{s+=$NF}END{print s}'
553786

(from a quick look, the rest of the test failures are not related to pty and are probably the reason why the %check section of the spec file is not blocking)

So unless John raises a valid issue, I'd say this new mock is a clear winner!

Well, I think we'll have to go with this one for now anyway. 

Using the 'newinstance' mount option to devpts may be something desirable but we need to actually make it work before putting it back into production.

(In reply to comment #35)
> Well, I think we'll have to go with this one for now anyway. 
> 
> Using the 'newinstance' mount option to devpts may be something desirable but
> we need to actually make it work before putting it back into production.

Clark, I aggree it does need to actually work correctly before turning it loose again. So if your fine with that then we can consider this a fix.

So can this be pushed to EPEL?

(In reply to comment #36)
> So can this be pushed to EPEL?

I've pushed the latest to epel5 and epel6, would you confirm that it fixes your problem?

(In reply to comment #37)

> I've pushed the latest to epel5 and epel6, would you confirm that it fixes your
> problem?

Well it seems you took out the 'fixing' method? Now what?

+        if mock.util.cmpKernelEVR(kver, '2.6.29') >= 0:
+            mountopt += ',newinstance'

Give me to the weekend and I'll give the 1.1.12 a go.

Any results with 1.1.14?

Mock 1.1.15 epel testing no .14

Builds:
bash-4.1.2-3.el6.src.rpm
binutils-2.20.51.0.2-5.11.el6.src.rpm

Failure:
gcc-4.4.4-13.el6.src.rpm

Running the gcc build again. Will run the perl packages later on tonight. Any specific package targets?

(In reply to comment #40)
> Mock 1.1.15 epel testing no .14
> 
> Builds:
> bash-4.1.2-3.el6.src.rpm
> binutils-2.20.51.0.2-5.11.el6.src.rpm
> 
> Failure:
> gcc-4.4.4-13.el6.src.rpm
> 
> Running the gcc build again. Will run the perl packages later on tonight. Any
> specific package targets?

Any luck getting gcc to build?

(In reply to comment #41)
> (In reply to comment #40)
> > Mock 1.1.15 epel testing no .14
> > 
> > Builds:
> > bash-4.1.2-3.el6.src.rpm
> > binutils-2.20.51.0.2-5.11.el6.src.rpm
> > 
> > Failure:
> > gcc-4.4.4-13.el6.src.rpm
> > 
> > Running the gcc build again. Will run the perl packages later on tonight. Any
> > specific package targets?
> 
> Any luck getting gcc to build?

It built with '+ make -j1'.  Would not build as parallel make jobs for some reason.  It would error with 'waiting for unfinished jobs'.  Kinda odd when other builds would not have that problem.

very odd. What distro were you hosted on?

(In reply to comment #43)
> very odd. What distro were you hosted on?

Interesting question you have there. It's not CentOS or SL but hang in there I have going another build of it going on rhel.

The distro was on a single P4, 768 MB ram running make -j2 and I really contribute the problem to lack of system resources and not distro $flavor. The same distro (el6) hosted as a KVM VM i686 host with 6 cores allocated and 4GB ram with make -j6 has no problems.

(In reply to comment #44)
> (In reply to comment #43)
> > very odd. What distro were you hosted on?
> 
> Interesting question you have there. It's not CentOS or SL but hang in there I
> have going another build of it going on rhel.

Ok so just to clear this up for el6 hosts. RHEL 6.0 it also builds (make -j2) like the kvm host i stated above.  So sum that up as a lack of system resources.

If you want I can do up the perl packages (6Server & 6Workstation).

Unless anyone objects, I'm going to call this one done.

[*@* RPMS]$ ls|grep perl|wc -l
210
[*@* RPMS]$ rpm -q mock
mock-1.1.15-1.el6.noarch && 5 perl failures with that version.
--------------------

mock-1.1.10-1.el6.rpm is the best mock to date from back in early June that was in testing.

curl even failed to build in 1.1.15.

RUN: Test server pid 14699 signalled to die
* kill pid for ftps => 14702
RUN: Test server pid 14702 signalled to die
TESTDONE: 532 tests out of 533 reported OK: 99%
TESTFAIL: These test cases failed: 507 
TESTDONE: 544 tests were considered during 1774 seconds.
TESTINFO: 11 tests were skipped due to these restraints:
TESTINFO: "rlimit problem: fds needed 1050 > system limit 1024" 1 times (518)

Note the descriptor problem.  That don't happen with the prior and that's on the same builder.  That is a RHEL Machine x86_64 and a dedicated builder only.  It does not run koji...mock perl and python with minimal services.


ulimit -n 2048
kernel-2.6.32-71.el6.x86_64

nss also failed the testing suite also where it did not on *.10

Ok, I'll look into it. Please list the full version (maybe a koji link?) of SRPMs that fail to build so I can pull them and debug the mock issues.

(In reply to comment #48)
> Ok, I'll look into it. Please list the full version (maybe a koji link?) of
> SRPMs that fail to build so I can pull them and debug the mock issues.

Ok lets give it a bit more time.  There's goodbit of srpms left in the build queue.  So far there is, of the 'perls':

perl-CGI-Session
perl-Class-MethodMaker
perl-IPC-Run
perl-Term-ProgressBar
perl-Test-MockObject

These would be the original 6.0 versions.
----

Koji: I don't use it but I have logs I can link if you want them at a private url.

I successfully built perl-5.8.8-32.el5_7.5.src.rpm on a RHEL5 box with mock-1.1.17, using epel-5-x86_64 config. 

I'll try a couple on your list.

any thoughts on 1.1.17+?  We're currently at 1.1.25 and I haven't heard any other issues regarding ttys. 

Think I'll close this one and if anyone still wants it open feel free to reopen.