Re: [meta-networking][PATCH 1/1] mdns: move from meta-intel-iot-middleware

[Denys Dmytriyenko <denis@denix.org>]

On Tue, Oct 17, 2017 at 12:05:55PM -0700, Khem Raj wrote:
> On Tue, Oct 17, 2017 at 11:09 AM, Denys Dmytriyenko <denis@denix.org> wrote:
> > On Tue, Oct 17, 2017 at 10:01:13AM -0700, Khem Raj wrote:
> >> On Tue, Oct 17, 2017 at 9:58 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> >> > I agree with Khem, I've merged oprofile even when it fails with musl,
> >> > because that was the main reason for moving it from oe-core to meta-oe, but
> >> > we don't want to burden Khem with more new musl issues when they are
> >> > detected soon enough (my world builds don't use musl, so I depend on Khem to
> >> > provide feedback when he can) .
> >> >
> >> > On Tue, Oct 17, 2017 at 6:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
> >> >>
> >> >> On Mon, Oct 16, 2017 at 10:11 PM, Denys Dmytriyenko <denis@denix.org>
> >> >> wrote:
> >> >> > On Mon, Oct 16, 2017 at 09:19:25PM -0700, Khem Raj wrote:
> >> >> >> On Wed, Oct 4, 2017 at 1:20 PM, Paul Eggleton
> >> >> >> <paul.eggleton@linux.intel.com> wrote:
> >> >> >> > The following improvements have been made over the recipe that was in
> >> >> >> > meta-intel-iot-middleware (a layer which is no longer actively
> >> >> >> > maintained):
> >> >> >> >
> >> >> >> > * Upgrade to latest upstream version (765.50.9)
> >> >> >> > * Fix compilation failures by passing CC and LD
> >> >> >> > * Fix "no GNU hash in the ELF binary" issue
> >> >> >> > * Point S at the correct source subdirectory so that "make clean"
> >> >> >> > works
> >> >> >> > * Fix lack of soname on libdns_sd.so leading to missing RDEPENDS QA
> >> >> >> > error
> >> >> >> > * Add SUMMARY
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> This has been accepted into master but it fails to build with musl
> >> >> >
> >> >> > Is musl a requirement for meta-oe?
> >> >>
> >> >> We have fixed it to a point where we have around 10-12 recipes which
> >> >> don't compile
> >> >> with musl, and it would be better to keep this level as such and
> >> >> especially when we
> >> >> know its failing. its a requirement for oe-core
> >>
> >> I do world builds on master-next with musl on qemumips and rpi3
> >> continuously, with a known set of failures, if a new one shows up
> >> I tend to report.
> >
> > Ok, no problem, it's just demanding someone new, submitting a patch/recipe, to
> > go fix musl, which they probably never heard of, would result in never hearing
> > from them again. :)
> 
> I think, its fair to expect some responsibility from submitters. I do
> not encourage
> shoot and scoot approach. Eventually it feels like dumping ground.
> I myself have fixed plenty of recipes which were added and
> left as it is, orphaned. I had to fix them to work with musl or clang,
> realizing that
> given package has had several releases ever since it was added to OE, but we
> never update the recipe.

I agree with your comments in general - striving for quality should be the 
ultimate goal, just don't forget about balance and compromise... :) It all 
boils down to available resources on both sides, but you already know that.


> We probably should pay attention towards such orphaned
> packages closely.

Maybe some sort of automated notification system for aging recipes? On the 
other hand, the state of the world already provides most of that info, it's 
just too overwhelming...


> > Anyway, I'll look into getting some musl coverage for my submission as well...
> >
> > --
> > Denys
>