[OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

Koen Kooi koen at dominion.thruhere.net
Mon Nov 3 17:13:41 UTC 2014


> Op 3 nov. 2014, om 17:08 heeft Burton, Ross <ross.burton at intel.com> het volgende geschreven:
> 
> 
> On 3 November 2014 15:24, Koen Kooi <koen.kooi at linaro.org> wrote:
> It's been over a month and libpng is still broken, so I refuse to classify this new process as 'helpful' or as 'appreciated' at this point.
> 
> Remember that 1.7 was frozen solid for several weeks of that month, so no it wouldn't have been merged in that time period.  It's only just re-opened: master is currently 80 patches ahead of dizzy, 35 in the C-Pull I sent last night, and another 33 in my staging branch right now so it's not like we're taking it easy right now.
> 
> Some context: during September it was obvious that various parties had an interest in aarch64 (Linaro and Wind River).  Patches to fix build failures were being sent sporadically, a qemuarm64 machine was submitted, but there was no kernel for said machine to actually build.   At the time there was no qemuarm64 machine that actually worked, so even merging the "simple" fixes on just faith that they're correct would be reckless considering we were freezing.  This is why I suggested[1] that someone with a vested interest in aarch64 collate all the patches into a single branch and keep it rebased to master so that when master opens, it can be tested on *all* qemu architectures and merged.  It appears that this hasn't happened.  Will Linaro be able to create a branch that incorporates all of the patches and new machine that's been tested as a whole?

Most likely not because we already have meta-aarch64 for the toolchain and kernel support. But aside from that, the past few *years* it wasn't a problem to get aarch64 related patches merged into OE-core, so why is there suddenly such a problem now?

Furthermore, this libpng patch isn't strictly an aarch64 patch, it fixes a previous commit that should have been flagged in review as being wrong for using double qualifiers in a bogus way. So why did the culprit go in and the fix submitted 3 days later not?


More information about the Openembedded-core mailing list