Dear Otavio, In message <CAP9ODKpExT9=xne0zdh-s0amfh0rgqmctuuoq0g3mzjhm2v...@mail.gmail.com> you wrote: > > > It worked when Marek submitted it, right? So something else was > > changed? > > If you read the looks it didn't. The problem is that Marek didn't > build X11 and he didn't figure it out.
Yes, but then: we are not interestedn in supporting X11 on this platform. All users we are aware of prefer to use QtE when they need a GUI. So simply don't build X11. > Subscribe the list and review the patches. It is a little too late to > complain about a commit log already merged. Thanks, but actually I am not interested in out-of-tree code. > Even if I did a mistake in the branch name (which I am sure it worked > at that time) I don't make money selling M28EVK or M53EVK, you do. So > who should be keeping an eye if boards are working in the BSP? I am not aware of any of our customers who ever tried the fsl-extre stuff. We have to provide support to our customers, and supporting out-of-tree code is insane from a commercial point of view. This is why we only support them with mainline code. But you sidetrack again: in community work, it is an established rule that he who breakes working code is normally also responsible to fix it. Here it is a trivial build error, where no knowledge about the actual hardware nor any actual testing on the board is needed, so I really cannot see why you make such a fuss. > I pushed to fix already so DENX boards are building. If you don't see > value in having the boards in the BSP those can be dropped from the > BSP. I would prefer if you, Marek or someone else could keep an eye on > those and do regular tests so we catch problems. You are suposed to test your commits so that they do not break the build. > I personally told Marek about the X11 issue more than a week ago. It > ended I fixing it ... please stop and think if it is right. I think it is. - We are not much interested in X11 for this platform. None of our customers and known users uses it. Why should we invest efforts in testing or fixing unused features? - It appears the breakage comes from out-of-tree code. All the Yocto defined images build and run fine in a plain Yocto environment. This applies fully to Yocto 1.5.1 (see for example our ELDK v5.5 which is based on this), and it applies mostly to Yocto 1.6_M2 (we still have build issues there, but these are related to the Xenomai integration an not to using a mainline kernel [without referencing a branch name, btw.] or X11 or gstreamer or such]. Especially with a commercial background in we need code that can be maintained over a long period of time - at least 5...10 years, maybe more. This simply doesn't work with out-of-tree code, so we have no interest in fixing out-of-tree code, or problems caused by it. > By the way, this is my last e-mail in this thread. Agreed. There have not been really new arguments, so we can stop here. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected] If you're out of tree, you don't exist. - David Woodhouse in <[email protected]> _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
