Can rpmbuild produce a 'build logs' rpm also?

[David Howells]

Can rpmbuild be taught to produce a 'build logs' rpm (or tarball or something)
that isn't automatically added to the installation set by koji/bodhi and that
can get generated even in the event of a build failure?

I have seen two examples of where this could be useful:

 (1) gcc-5 dumps a whole chunk of tar'd, bzip'd and uuencoded testing logs to
     stdout because it has nowhere else to put them.

 (2) I'm seeing a config failure building cross-gcc on ARM that doesn't occur
     on x86_64 or i686 - but it happens in koji where I can't get at the
     config.log to see what happened.

David

[Richard W.M. Jones]

On Fri, Feb 06, 2015 at 10:41:51AM +0000, David Howells wrote:
>  Can rpmbuild be taught to produce a 'build logs' rpm (or
> tarball or something)
>  that isn't automatically added to the installation set by koji/bodhi and that
>  can get generated even in the event of a build failure?
>  
>  I have seen two examples of where this could be useful:
>  
>   (1) gcc-5 dumps a whole chunk of tar'd, bzip'd and uuencoded testing logs to
>       stdout because it has nowhere else to put them.
>  
>   (2) I'm seeing a config failure building cross-gcc on ARM that doesn't occur
>       on x86_64 or i686 - but it happens in koji where I can't get at the
>       config.log to see what happened. 
I don't think an RPM would help.  However it would be nice if Koji
allowed you to pull files from the build tree, especially after a
failure.

In the past I have done this:

  %{configure} || { cat config.log ; exit 1 }

I also did some hairy uuencoding to dump out binaries that I wanted to
capture.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[David Howells]

Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:

>  I don't think an RPM would help.  However it would be nice if
> Koji
>  allowed you to pull files from the build tree, especially after a
>  failure. 
Even if it just grabbed every file ending in .log from the build tree, that
might be useful.

David

[Miroslav Suchý]

On 02/06/2015 11:41 AM, David Howells wrote:
>  Can rpmbuild be taught to produce a 'build logs' rpm (or
> tarball or something)
>  that isn't automatically added to the installation set by koji/bodhi and that
>  can get generated even in the event of a build failure? 
rpmbuild is very low level tool. I doubt it have sense there.

Mock is able to do that using chroot_scan plugin
  http://fedoraproject.org/wiki/Projects/Mock/Plugin/ChrootScan

So this is merely about Koji/Copr to use some standard location. And the
"standard" is key here.
Because there is no standard there. I suggest you to create some draft of such standard
and talk to Fedora Packaging
Committee.

-- 
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys

[David Howells]

Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:

>  > Can rpmbuild be taught to produce a 'build logs' rpm (or
> tarball or
>  > something) that isn't automatically added to the installation set by
>  > koji/bodhi and that can get generated even in the event of a build
>  > failure?
>  
>  rpmbuild is very low level tool. I doubt it have sense there. 
Possibly, but some support from the specfile might be necessary - if only to
specify where to find the logs.

>  So this is merely about Koji/Copr to use some standard location. And
> the
>  "standard" is key here. 
What do you mean by 'standard location'?  Do you mean the locations of the
log/logs to be captured or the place where the captured logs are held?

David

[Miroslav Suchý]

On 02/16/2015 02:12 PM, David Howells wrote:
>   Do you mean the locations of the
>  log/logs to be captured 
This one.

-- 
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys

[David Howells]

I have raised a bz related to this:

	https://bugzilla.redhat.com/show_bug.cgi?id=1190763

David