Possible to access Koji build directory?

[Jim Meyering]

Jan Kratochvil wrote:
> On Fri, 16 Mar 2012 11:16:51 +0100, Jim Meyering wrote:
>> That works very well.  However, the base64 output in my first log was
>> corrupt, due to some asynchronous output (stderr about job completion)
>> that was emitted in the middle of the big base64 block.
>> Adding the "sync; sleep 10" part below should avoid that in the future:
>
> FYI using automatic killer of leftover processes as some of them never finished
> and blocked builds, in other cases they kept running busy on build boxes etc.
>
> # Cleanup any leftover testsuite processes as it may stuck mock(1) builds.
> #
> http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-orphanripper.c;hb=master
> Source2: gdb-orphanripper.c
> gcc -o ./orphanripper %{SOURCE2} -Wall -lutil -ggdb2
> ./orphanripper make %{?_smp_mflags} -k $CHECK || :

Hi Jan,

Nice program.  Thanks for sharing.
However, I would suggest that any "make check"-spawned process that
does not terminate is a test script bug that should be fixed upstream,
e.g., by prefixing the command with "timeout $n_seconds" for some
reasonable number of seconds.

Even though some systems lack timeout (introduced in coreutils-7.0 2008-10-05)
I still use it (e.g., in grep) along with an invocation of this function:

  require_timeout_()
  {
    ( timeout 10s true ) > /dev/null 2>&1 \
      || skip_ your system lacks the timeout program
    timeout 10s false; test $? = 1 \
      || skip_ your system has a non-GNU timeout program
  }

Then, the test is simply skipped on a system without "timeout".

Of course, if upstream cannot be bothered to correct the tests,
it's sure good to have your orphanripper program.  Just don't
let it serve as an excuse to write sloppy tests.