tinderbox, bug reports and a freshly-broken mplayer

tinderbox, bug reports and a freshly-broken mplayer

[Robert P. J. Day]

  in order to keep the peace, i'm more than willing to file actual OE
bug reports for breakage i discover when building.  specifically, i'm
almost always trying to build beagleboard-demo-image on my up-to-date
fedora system, which seems to be a relatively unpopular working system
for most people here (except for philip b.), so i'm getting used to
running into breakage that no one else is seeing -- it's just a fact
of life.

  ignoring gnome-games for now, after a recent "git pull" on the OE
dev branch, the "mplayer" package now no longer builds.  from the git
log, i can see:

=====

commit 33c882b663a1dd229d0ebcb187648838d0164795
Author: Koen Kooi <koen@openembedded.org>
Date:   Sun Jan 17 14:52:44 2010 +0100

    mplayer: bump SRCREV for some more ARM fixes

diff --git a/recipes/mplayer/mplayer_svn.bb
b/recipes/mplayer/mplayer_svn.bb
index 58a4bc7..d3fc2f7 100644
--- a/recipes/mplayer/mplayer_svn.bb
+++ b/recipes/mplayer/mplayer_svn.bb
@@ -15,7 +15,7 @@ SRC_URI =
"svn://svn.mplayerhq.hu/mplayer;module=trunk \
           file://fix-addrinfo.patch;patch=1;maxrev=30302 \
 "

-SRCREV = "30247"
+SRCREV = "30345"
 SRC_URI_append_armv7a = " \
                file://omapfb.patch;patch=1 \
           file://vo_omapfb.c \

=====

  if i "git reset" to the commit just before that, it builds fine;
ergo, that seems to be the commit that broke it.  a wild guess is that
the "maxrev" parameters are the cause, given that at least one now
falls below the requested svn revision, causing an essential patch to
no longer be applied, but that's just a guess until i look more
closely.

  the tail end of the log file:

fmt-conversion.c
fmt-conversion.c:28: error: 'PIX_FMT_RGB32' undeclared here (not in a function)
fmt-conversion.c:30: error: 'PIX_FMT_RGB565' undeclared here (not in a function)
fmt-conversion.c:31: error: 'PIX_FMT_RGB555' undeclared here (not in a function)
fmt-conversion.c:40: error: 'PIX_FMT_BGR32' undeclared here (not in a function)
fmt-conversion.c:42: error: 'PIX_FMT_BGR565' undeclared here (not in a function)
fmt-conversion.c:43: error: 'PIX_FMT_BGR555' undeclared here (not in a function)
make: *** [fmt-conversion.o] Error 1
FATAL: oe_runmake failed


  so ... i can file this over at http://bugs.openembedded.net/ if
that's the way to go.  but others were talking about this tinderbox
thing, which i've never used.  a quick glance suggests it's a more
formal, automated way of doing regular builds.  would that be
appropriate for me, if it's understood i'm always building on the same
distro?  feel free to point me at a quick intro, or i'll just file a
regular bug if that's the way to go.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: tinderbox, bug reports and a freshly-broken mplayer

[John Willis]

Robert,

>   in order to keep the peace, i'm more than willing to file actual OE
> bug reports for breakage i discover when building.  specifically, i'm
> almost always trying to build beagleboard-demo-image on my up-to-date
> fedora system, which seems to be a relatively unpopular working system
> for most people here (except for philip b.), so i'm getting used to
> running into breakage that no one else is seeing -- it's just a fact
> of life.
> 
>   ignoring gnome-games for now, after a recent "git pull" on the OE
> dev branch, the "mplayer" package now no longer builds.  from the git
> log, i can see:

<snip>

On the gnome-games front, I have been messing with gnome-games packages for
something else (unrelated to the BB-demo image). I can mail you a few BB's
to try if you want but none of it is working 100% yet (newer versions of
gnome-games introduce requirements for OpenGL/Clutter etc. and that opens a
whole world of pain).

>   if i "git reset" to the commit just before that, it builds fine;
> ergo, that seems to be the commit that broke it.  a wild guess is that
> the "maxrev" parameters are the cause, given that at least one now
> falls below the requested svn revision, causing an essential patch to
> no longer be applied, but that's just a guess until i look more
> closely.

<snip>

If you have a hunch on the patch then give it a go, or drop down the SRCREV
for a few days until someone else can get around to fixing the issue, I
suspect this bug will be seen widely (in fact I reproduced it on my setup
with a fresh pull of mplayer_svn.bb on a Ubuntu build host yesterday). Your
hunch seems good but I have no time to personally look at this now.

>   so ... i can file this over at http://bugs.openembedded.net/ if
> that's the way to go.  but others were talking about this tinderbox
> thing, which i've never used.  a quick glance suggests it's a more
> formal, automated way of doing regular builds.  would that be
> appropriate for me, if it's understood i'm always building on the same
> distro?  feel free to point me at a quick intro, or i'll just file a
> regular bug if that's the way to go.

Let's be honest, you're never going to go too far wrong raising a bug report
;).

As for TinderBox, I did include some links in an earlier mail 

"I think Phil (or someone else) suggest you consider contributing your build
logs to OESTATS/TinderBox
(http://wiki.openembedded.net/index.php/How_do_I_send_automatic_success_and_
failure_reports) at least with that setup you leave a reference the failing
logs in bug reports/mails so people can have a look into all the gory
details :)." 

It only takes a few minor changes to your local.conf and all your build logs
and build status are automatically uploaded to the server. This makes
diagnosing build issues/collective debugging etc. that little bit easier as
anyone can go to http://tinderbox.openembedded.org/builders/<your_nick> and
see what your builds and failures and dig into the logs. If you worried
about personal info. being uploaded then check into oestats-client.bbclass
to see what is happening under the hood.

To prove a point this is a link to the failed mplayer build I did yesterday
(http://tinderbox.openembedded.org/packages/431300/).

Regards,

John

Re: tinderbox, bug reports and a freshly-broken mplayer

[Robert P. J. Day]

On Tue, 19 Jan 2010, John Willis wrote:

> rpjday wrote:

> >   ignoring gnome-games for now, after a recent "git pull" on the
> > OE dev branch, the "mplayer" package now no longer builds.  from
> > the git log, i can see:
>
> <snip>
>
> On the gnome-games front, I have been messing with gnome-games
> packages for something else (unrelated to the BB-demo image). I can
> mail you a few BB's to try if you want but none of it is working
> 100% yet (newer versions of gnome-games introduce requirements for
> OpenGL/Clutter etc. and that opens a whole world of pain).

  i'm going to ignore that package for the foreseeable future -- it
contains nothing I'm interested in and, yes, it does indeed bring a
whole world of pain.  movin' on ...

  regarding the current breakage of mplayer which seems to be the
result of this commit:

commit 33c882b663a1dd229d0ebcb187648838d0164795
Author: Koen Kooi <koen@openembedded.org>
Date:   Sun Jan 17 14:52:44 2010 +0100

    mplayer: bump SRCREV for some more ARM fixes

diff --git a/recipes/mplayer/mplayer_svn.bb
b/recipes/mplayer/mplayer_svn.bb
index 58a4bc7..d3fc2f7 100644
--- a/recipes/mplayer/mplayer_svn.bb
+++ b/recipes/mplayer/mplayer_svn.bb
@@ -15,7 +15,7 @@ SRC_URI =
"svn://svn.mplayerhq.hu/mplayer;module=trunk \
           file://fix-addrinfo.patch;patch=1;maxrev=30302 \
 "

-SRCREV = "30247"
+SRCREV = "30345"
 SRC_URI_append_armv7a = " \
                file://omapfb.patch;patch=1 \
           file://vo_omapfb.c \


> >   if i "git reset" to the commit just before that, it builds fine;
> > ergo, that seems to be the commit that broke it.  a wild guess is
> > that the "maxrev" parameters are the cause, given that at least
> > one now falls below the requested svn revision, causing an
> > essential patch to no longer be applied, but that's just a guess
> > until i look more closely.
>
> <snip>
>
> If you have a hunch on the patch then give it a go, or drop down the
> SRCREV for a few days until someone else can get around to fixing
> the issue, I suspect this bug will be seen widely (in fact I
> reproduced it on my setup with a fresh pull of mplayer_svn.bb on a
> Ubuntu build host yesterday). Your hunch seems good but I have no
> time to personally look at this now.

  neither do i, other commitments for the day.  nice to see that
you've already seen that as well.  makes me believe i am not alone.
:-)


> As for TinderBox, I did include some links in an earlier mail
>
> "I think Phil (or someone else) suggest you consider contributing your build
> logs to OESTATS/TinderBox
> (http://wiki.openembedded.net/index.php/How_do_I_send_automatic_success_and_
> failure_reports) at least with that setup you leave a reference the failing
> logs in bug reports/mails so people can have a look into all the gory
> details :)."
>
> It only takes a few minor changes to your local.conf and all your build logs
> and build status are automatically uploaded to the server. This makes
> diagnosing build issues/collective debugging etc. that little bit easier as
> anyone can go to http://tinderbox.openembedded.org/builders/<your_nick> and
> see what your builds and failures and dig into the logs. If you worried
> about personal info. being uploaded then check into oestats-client.bbclass
> to see what is happening under the hood.
>
> To prove a point this is a link to the failed mplayer build I did yesterday
> (http://tinderbox.openembedded.org/packages/431300/).

  thanks, i'll dig into this after today.  for now, i'll just drop the
SRCREV on mplayer to get a working build and watch the logs.

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: tinderbox, bug reports and a freshly-broken mplayer

[John (GMail)]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Robert P. J. Day
> Sent: Tuesday, January 19, 2010 12:17 AM
> To: OpenEmbedded Development mailing list
> Subject: [oe] tinderbox, bug reports and a freshly-broken mplayer
> 
> 
>   in order to keep the peace, i'm more than willing to file actual OE
> bug reports for breakage i discover when building.  specifically, i'm
> almost always trying to build beagleboard-demo-image on my up-to-date
> fedora system, which seems to be a relatively unpopular working system
> for most people here (except for philip b.), so i'm getting used to
> running into breakage that no one else is seeing -- it's just a fact
> of life.
Hi Robert,

I run the same beagleboard-demo-image build on Ubuntu 9.10 almost daily.
Occasionally I also see a package build error and I mostly resolve this by
doing a bitbake -c clean for that package and then a bitbake -c build for
the same package. In most instances, this results in a clean build and then
beagleboard-demo-image builds without error. If this does not work, then I
rename my tmp folder and then rebuild everything. On my machine, it only
takes about an hour to complete. If I get the same build error, then and
only then do I start looking for a fix (review log file, review chat
discussions, etc). Over the last six weeks, the only build that would not
complete was on Dec 13 because mesa-dri was broken.

I hope this helps.
Regards,
John
> 
>   ignoring gnome-games for now, after a recent "git pull" on the OE
> dev branch, the "mplayer" package now no longer builds.  from the git
> log, i can see:
> 
> =====
> 
> commit 33c882b663a1dd229d0ebcb187648838d0164795
> Author: Koen Kooi <koen@openembedded.org>
> Date:   Sun Jan 17 14:52:44 2010 +0100
> 
>     mplayer: bump SRCREV for some more ARM fixes
> 
> diff --git a/recipes/mplayer/mplayer_svn.bb
> b/recipes/mplayer/mplayer_svn.bb
> index 58a4bc7..d3fc2f7 100644
> --- a/recipes/mplayer/mplayer_svn.bb
> +++ b/recipes/mplayer/mplayer_svn.bb
> @@ -15,7 +15,7 @@ SRC_URI =
> "svn://svn.mplayerhq.hu/mplayer;module=trunk \
>            file://fix-addrinfo.patch;patch=1;maxrev=30302 \
>  "
> 
> -SRCREV = "30247"
> +SRCREV = "30345"
>  SRC_URI_append_armv7a = " \
>                 file://omapfb.patch;patch=1 \
>            file://vo_omapfb.c \
> 
> =====
> 
>   if i "git reset" to the commit just before that, it builds fine;
> ergo, that seems to be the commit that broke it.  a wild guess is that
> the "maxrev" parameters are the cause, given that at least one now
> falls below the requested svn revision, causing an essential patch to
> no longer be applied, but that's just a guess until i look more
> closely.
> 
>   the tail end of the log file:
> 
> fmt-conversion.c
> fmt-conversion.c:28: error: 'PIX_FMT_RGB32' undeclared here (not in a
function)
> fmt-conversion.c:30: error: 'PIX_FMT_RGB565' undeclared here (not in a
function)
> fmt-conversion.c:31: error: 'PIX_FMT_RGB555' undeclared here (not in a
function)
> fmt-conversion.c:40: error: 'PIX_FMT_BGR32' undeclared here (not in a
function)
> fmt-conversion.c:42: error: 'PIX_FMT_BGR565' undeclared here (not in a
function)
> fmt-conversion.c:43: error: 'PIX_FMT_BGR555' undeclared here (not in a
function)
> make: *** [fmt-conversion.o] Error 1
> FATAL: oe_runmake failed
> 
> 
>   so ... i can file this over at http://bugs.openembedded.net/ if
> that's the way to go.  but others were talking about this tinderbox
> thing, which i've never used.  a quick glance suggests it's a more
> formal, automated way of doing regular builds.  would that be
> appropriate for me, if it's understood i'm always building on the same
> distro?  feel free to point me at a quick intro, or i'll just file a
> regular bug if that's the way to go.
> 
> rday
> --
> 
> =============================================================
> ===========
> Robert P. J. Day                               Waterloo, Ontario, CANADA
> 
>             Linux Consulting, Training and Kernel Pedantry.
> 
> Web page:                                          http://crashcourse.ca
> Twitter:                                       http://twitter.com/rpjday
> =============================================================
> ===========
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: tinderbox, bug reports and a freshly-broken mplayer

[Denys Dmytriyenko]

On Tue, Jan 19, 2010 at 06:53:19AM -0500, Robert P. J. Day wrote:
> On Tue, 19 Jan 2010, John Willis wrote:
> 
> > As for TinderBox, I did include some links in an earlier mail
> >
> > "I think Phil (or someone else) suggest you consider contributing your build
> > logs to OESTATS/TinderBox
> > (http://wiki.openembedded.net/index.php/How_do_I_send_automatic_success_and_
> > failure_reports) at least with that setup you leave a reference the failing
> > logs in bug reports/mails so people can have a look into all the gory
> > details :)."
> >
> > It only takes a few minor changes to your local.conf and all your build logs
> > and build status are automatically uploaded to the server. This makes
> > diagnosing build issues/collective debugging etc. that little bit easier as
> > anyone can go to http://tinderbox.openembedded.org/builders/<your_nick> and
> > see what your builds and failures and dig into the logs. If you worried
> > about personal info. being uploaded then check into oestats-client.bbclass
> > to see what is happening under the hood.
> >
> > To prove a point this is a link to the failed mplayer build I did yesterday
> > (http://tinderbox.openembedded.org/packages/431300/).
> 
>   thanks, i'll dig into this after today.  for now, i'll just drop the
> SRCREV on mplayer to get a working build and watch the logs.

The above explanation and the linked instructions are very detailed and 
helpful. If you use Angstrom though, oestats/tinderbox is already enabled, so 
you just need to set some vars to use it. Add the following lines to your 
local.conf file:

INHERIT += "oestats-client"
OESTATS_SERVER = "tinderbox.openembedded.org"
OESTATS_BUILDER = "<your_nick>"

-- 
Denys