[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. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
