Probably thought of a million times, but was wondering whether it would
be possible, and useful to give diff capabilities within the koji web
interface.

eg: x86_64 build
...
Output build.log (tail)
root.log (tail)
state.log (tail)
could become:
Output build.log (tail) (diff)
root.log (tail) (diff)
state.log (tail) (diff)

hovering over diff would cause a (json) load of options:
- diff -u with other arch:
i686, ppc, ppc64
- diff -u with other version:
list other builds in this release (eg devel): 4.3-1, 4.3-4,
- diff -u with other release:
list other releases of same version that have been built: f12, f13

The diff could be generated to look like a viewvc side by side diff.
Bonus points if the diff ignores things like:
- tmp file names (/var/tmp/rpm-tmp.trZK8P)
- log address: 0x2b9c82662f90
- builder: x86-05.phx2.fedoraproject.org

Previously, I found the build logs rather boring; by saving each
locally, then running meld on them, I immediately see what has changed
between eg F12 and devel.

Any comments (other than 'show me the money/code') ?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Am Mon, 21 Jun 2010 09:32:07 +1000
schrieb David Timms <dtimms@iinet.net.au>:

> Probably thought of a million times, but was wondering whether it
> would be possible, and useful to give diff capabilities within the
> koji web interface.
>
> eg: x86_64 build
> ...
> Output build.log (tail)
> root.log (tail)
> state.log (tail)
> could become:
> Output build.log (tail) (diff)
> root.log (tail) (diff)
> state.log (tail) (diff)
>
> hovering over diff would cause a (json) load of options:
> - diff -u with other arch:
> i686, ppc, ppc64
> - diff -u with other version:
> list other builds in this release (eg devel): 4.3-1, 4.3-4,
> - diff -u with other release:
> list other releases of same version that have been built: f12, f13
>
> The diff could be generated to look like a viewvc side by side diff.
> Bonus points if the diff ignores things like:
> - tmp file names (/var/tmp/rpm-tmp.trZK8P)
> - log address: 0x2b9c82662f90
> - builder: x86-05.phx2.fedoraproject.org
>
> Previously, I found the build logs rather boring; by saving each
> locally, then running meld on them, I immediately see what has
> changed between eg F12 and devel.
>
> Any comments (other than 'show me the money/code') ?

I don't see a benefit of that... When a build fails, it kills all
other current builds of other architectures, so you need to check that
architecture, that fails first and the diff would not contain the error.

Other that that. The diff would show, different which different
packages are installed, e.g. gcc.i386 instead of gcc.x86_64, which
doesn't interest me either...
(And different requires etc.)

What would be the benefit of such a feature?

Thomas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 21/06/10 09:38, Thomas Spura wrote:
>> Any comments (other than 'show me the money/code') ?
>
> I don't see a benefit of that... When a build fails, it kills all
> other current builds of other architectures, so you need to check that
> architecture, that fails first and the diff would not contain the error.
Hi Thomas, good point. But reality might be different:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2260035 -> build.log

The x86_64 build failed, and is says that the i686 was cancelled.

However, the build.log shows that the package and -debuginfo .rpms were
created, ie the build actually succeeded. This seems like a bug in the
koji web interface.

Having the non-failing build be cancelled may not be optimal; I have
definitely found it helpful to compare the build logs of different
archs, when one succeeds (or at least gets further). It helps to see the
diff in log results to understand what is different about the process
between each build.

> Other that that. The diff would show, different which different
> packages are installed, e.g. gcc.i386 instead of gcc.x86_64, which
> doesn't interest me either...
> (And different requires etc.)
That would be more bonus points for the diff to optionally ignore !
A decent visual diff will highlight lines that are different, but also
show the actual characters that differ (I don't know if viewvc can do that).

> What would be the benefit of such a feature?
Resolving build problems more quickly:
- what changed in the build process from arch to arch ...
- what changed in the bp from fedora release to fedora release ...
- what changed in the bp compare to an earlier version-release ...

However, for the less experienced package maintainers: tell me shortest
time for you to determine the cause for the failure in:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2260034 -> build.log

Now, would these screen shots from a visual diff program have reduced
the time for working out both the error, and the cause ?
http://members.iinet.net.au/~timmsy/rakarrack/meld.rakarrack.diff1.png
http://members.iinet.net.au/~timmsy/rakarrack/meld.rakarrack.diff2.png
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On Mon, 2010-06-21 at 22:20 +1000, David Timms wrote:
> On 21/06/10 09:38, Thomas Spura wrote:
> >> Any comments (other than 'show me the money/code') ?
> >
> > I don't see a benefit of that... When a build fails, it kills all
> > other current builds of other architectures, so you need to check that
> > architecture, that fails first and the diff would not contain the error.
> Hi Thomas, good point. But reality might be different:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2260035 -> build.log
>
> The x86_64 build failed, and is says that the i686 was cancelled.
>
> However, the build.log shows that the package and -debuginfo .rpms were
> created, ie the build actually succeeded. This seems like a bug in the
> koji web interface.
>
> Having the non-failing build be cancelled may not be optimal; I have
> definitely found it helpful to compare the build logs of different
> archs, when one succeeds (or at least gets further). It helps to see the
> diff in log results to understand what is different about the process
> between each build.
>
> > Other that that. The diff would show, different which different
> > packages are installed, e.g. gcc.i386 instead of gcc.x86_64, which
> > doesn't interest me either...
> > (And different requires etc.)
> That would be more bonus points for the diff to optionally ignore !
> A decent visual diff will highlight lines that are different, but also
> show the actual characters that differ (I don't know if viewvc can do that).
>
> > What would be the benefit of such a feature?
> Resolving build problems more quickly:
> - what changed in the build process from arch to arch ...
> - what changed in the bp from fedora release to fedora release ...
> - what changed in the bp compare to an earlier version-release ...
>
> However, for the less experienced package maintainers: tell me shortest
> time for you to determine the cause for the failure in:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2260034 -> build.log
>
> Now, would these screen shots from a visual diff program have reduced
> the time for working out both the error, and the cause ?
> http://members.iinet.net.au/~timmsy/rakarrack/meld.rakarrack.diff1.png
> http://members.iinet.net.au/~timmsy/rakarrack/meld.rakarrack.diff2.png

Something like this probably belongs in a consumer app, and not in Koji
directly. You'd find it faster to develop and use something stand alone
that consumed content from koji in order to do the comparisons, and then
you'd have a better way of comparing different builds.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Thomas Spura wrote:
> I don't see a benefit of that... When a build fails, it kills all
> other current builds of other architectures, so you need to check that
> architecture, that fails first and the diff would not contain the error.

Even just comparing successful builds can be useful, e.g. to make sure that
a new version isn't introducing new BRs.

That said, in addition to the noise already mentioned by the OP, the
smp_mflags make such diffs less than helpful, there will be moved lines all
over the make phase.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel