Description of problem: procps-ng-3.3.3-2.20120807git.fc19 fails during the self checks: ERROR: tcl error sourcing ./kill.test/kill.exp. ERROR: couldn't execute "/builddir/build/BUILD/procps-ng-3.3.3-20120807git/kill": no such file or directory ... ERROR: tcl error sourcing ./pgrep.test/pgrep.exp. ERROR: not a tty ... ERROR: tcl error sourcing ./pkill.test/pkill.exp. ERROR: not a tty ... ERROR: tcl error sourcing ./ps.test/ps_output.exp. ERROR: not a tty Version-Release number of selected component (if applicable): procps-ng-3.3.3-2.20120807git.fc19 How reproducible: Steps to Reproduce: 1. ppc-koji build --scratch f19 procps-ng-3.3.3-2.20120807git.fc19.src.rpm 2. 3. Actual results: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=691471
Hello Karsten. Could you please collect the log files located in the testsuite directory and attach them? Thanks in advance. Regards, Jaromir.
Created attachment 612137 [details] testsuite logs of the latest build
Created attachment 612138 [details] latest build log
any updates here ? If you need access to a ppc64 machine, please ping me on on IRC.
Hello. The tests PASS when building with 'fedpkg local'. There might be problems with koji/mock and the 'tty' command output as it says "ERROR: not a tty". J.
According to the latest tests, the tty command seems to fail in the koji/mock environment. I'm gonna switch the component to coreutils. But the problem still might be elsewhere.
Hi Jardo, I think this is one of the issues caused by the mock/koji environment and tty is probably innocent here. I don't know what do you want to fix in coreutils's tty. As is written in tty description - "Displays "not a tty" if stdin is not a terminal. Displays nothing if -s option is given. Exit status 0 if stdin is a tty, 1 if not, 2 if usage error, 3 if write error." - in this case tty fails, as in mock stdin is probably not a terminal. I think more probably, your testsuite has to be fixed to handle this situation (and skip the test if tty is not available). As I don't see any issue with tty command, moving back to procps-ng.
Hi Ondro. As this happens on the ppc only, we should search for differences in koji/mock environments for the particular architectures. I see skipping the tests as the last option. Thanks for your time. J.
koji doesnt do anything with ttys. mock is probably the first place to start looking.
Hello Clark. The component has been changed few times and we're still unsure what the root cause is. I tried to build the package in mock for ppc and it worked well. I also tried koji/x86 and that seems to work too. Only the combination of koji and mock for ppc somehow doesn't work. Please, try to do some investigation and let us know. Thanks. Regards, Jaromir.
just trying to summarize some of our IRC conversation: 1. the environment created by mock for both ppc and x86 is the same (stdin == /dev/null, stdout and stderr are both pipes back to mock). 2. the tests seem to fail on both systems but x86 ignores it while ppc does not. So, since stdout is a pipe, it is no surprise that the dejagnu tests fail in a mock controlled chroot. Both Jaromír and I are clueless as to why the build succeeds on x86.
According to the results of the following x86 scratch build, there's a problem with the failure evaluation. The results are random. http://koji.fedoraproject.org/koji/taskinfo?taskID=5060778 In this case the i686 build passed and the x86_64 build failed.
I've just done some troubleshooting here ... It seems the non-zero exit_status has nothing to do with the tty issue and the tcl sourcing issue. When the tests say "ERROR", it surprisingly leads to a zero exitcode (why not, if the issue is caused by problems in the testsuite design/unsatisfied test prerequisities). But when the tests say "FAIL", the exitcode is non-zero. The randomly appearing FAIL is produced by the "slabtop" test, but noone noticed that until now. --- FAIL: slabtop sorted by active objects (sorting 2799872 > 999999) FAIL: slabtop sorted by object count (sorting 2850018 > 999999) --- The conclusion: The problem lies either in the slabtop test or in the slabtop tool. Changing the component back to procps-ng.
The problem is very probably in the slabtop test: It seems the last_value set to 999999 in the expect_table_dsc procedure (unix.exp) is insufficient. The number of objects is really getting so high: ---- Active / Total Objects (% used) : 1948833 / 2129553 (91,5%) Active / Total Slabs (% used) : 38330 / 38330 (100,0%) Active / Total Caches (% used) : 88 / 117 (75,2%) Active / Total Size (% used) : 341209,66K / 368020,18K (92,7%) Minimum / Average / Maximum Object : 0,01K / 0,17K / 15,45K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 462969 370598 80% 0,10K 11871 39 47484K buffer_head 286720 284505 99% 0,03K 2240 128 8960K kmalloc-32 218624 218624 100% 0,01K 427 512 1708K kmalloc-8 218512 218377 99% 0,07K 3902 56 15608K selinux_inode_security 198357 198357 100% 0,85K 5361 37 171552K ext4_inode_cache 187614 162393 86% 0,19K 4467 42 35736K dentry 126650 126650 100% 0,02K 745 170 2980K fsnotify_event_holder 86592 78087 90% 0,06K 1353 64 5412K kmalloc-64 68864 68864 100% 0,02K 269 256 1076K kmalloc-16 34178 33682 98% 0,17K 743 46 5944K vm_area_struct 39032 32105 82% 0,55K 1394 28 22304K radix_tree_node 26172 25934 99% 0,11K 727 36 2908K sysfs_dir_cache 16224 15338 94% 0,25K 507 32 4056K kmalloc-256 14208 13396 94% 0,06K 222 64 888K anon_vma 13311 12380 93% 0,54K 459 29 7344K inode_cache 9095 9095 100% 0,05K 107 85 428K shared_policy_node 10416 9050 86% 0,09K 248 42 992K kmalloc-96 25350 6162 24% 0,13K 845 30 3380K ext4_allocation_context ... ... ---
Fixed in 3.3.7 (rawhide/f19). Test are disabled in the latest f18 package release. Closing.