[oe] [PATCH 2/2] omap4430-panda: fix u-boot

[Frans Meulenbroeks]

[Added TSC to the email, as I would like to request a decision on how
to handle this]

> Frans, given these two choices:
>
> 1) Recipe that builds and has tested output (but depends on distro source
> mirrors).
>
> 2) Recipe that builds (even without source mirrors), BUT the output is not
> tested.
>
> We should use choice #1, since the OUTPUT is tested. If someone who can test
> the output wants to bump the SRCREV, that is fine. Bumping SRCREVs just to
> get recipes to build and not testing the output only leads to frustrated
> users who think the output works.
>
> I'd point out that no one on the panda list (or this list) has mentioned
> they noticed the recipe doesn't build, so I am not sure you are addressing
> an actual problem.
>
> Philip
>

Philip, thanks for your reply.

I'd like to point out that the fact that the recipe does not build has
been reported to this very list late oct 2010.
At that point Steve Sakoman (the owner of the git from which the
recipe pulls) suggested to use u-boot 2010.09.
I did not get to fixing the recipe until yesterday. As u-boot 2010.12
is already out I figured that this would be a better choice.
I am also on the u-boot list and I know the changes from Steve are
pulled into u-boot master.
(and wrt to availability: I am quite confident that in a few years
time this version can still be retrieved).

The problem that this recipe does not build is already known for more
than 2 months but the machine maintainer apparently is not interested
in fixing his recipe.
As such I feel the maintainer is doing a bad job.

There are several ways to fix the problem.
To coin a few:
- move to a SRCREV that seems to me more stable (e.g. because it is a
merge with upstream). I agree that there is still a chance of getting
a breakage in the future
- putting the tarball for the version that we have now at e.g.
downloads.openembedded.org or so and adapt the recipe (we have done
this for other recipes as well)
- move to upstream. The panda changes from Steve have been merged by
Wolfgang. I am not aware of any reason not to do so.

While each alternative has its pro's and con's none of them is
complicated, and any of them could have been done easily.
As the problem is already reported last october, I feel the maintainer
is not doing a good job, and actually makes things worse by abusing
his powers to block others who want to fix it.
Apparently spending a few minutes to resolve the issue is too much
work, but there is of course always time to bitch and moan toward
others who do want to keep OE a system that supports multiple machines
and multiple distros.

I'd like to ask the TSC to come up with a decision on how we should
fix this recipe. I have already indicated a few solutions above. Yet
another alternative (which is not too desirable) is to create another
machine that chooses a proper recipe for u-boot.

Frans

PS: the fact that there are no other reports of this is probably
because not many people rebuild u-boot. Most of my boards still use
the u-boot that was on the board when I got it. I guess this also
holds for other people.