This also seems to prevent from building 1.3 which I need to fix voicemail notification.
Marco Chen a écrit: >>> It's not a good way to patch gecko code> I agree with Shawn. > And for my experience, I had tried to propose the "patch" mechanism and > reviewer strongly rejected it. > The reason is that "all patch should be reviewed well then commit into > repository" > Then I kept this principle when I reviewed other devices manifest. > > If this is a case we allowed then I can't say no for following requests from > partner. > Do we allow it? > > ----- 原始郵件 ----- > 寄件者: "Shawn Huang" <[email protected]> > 收件者: [email protected] > 寄件備份: 2014 3 月 8 星期六 上午 12:37:43 > 主旨: Re: [b2g] Master hamachi build failure> On Saturday, March 1, 2014 > 12:19:06 AM UTC+8, Shawn Huang wrote:>> On Friday, February 28, 2014 11:09:48 > PM UTC+8, Sotaro Ikeda wrote: >> >> I don't know why. Since hamachi is ICS based and still uses bluez as the >> bluetooth stack. This patch is not necessary for hamachi, now only JB/KK >> uses bluedroid as the bt stack. I think you can delete the patch locally. It >> looks like caf has their own modification for bluetooth HAL header files, >> and since we followed AOSP bluetooth HAL (at least I think we shall follow >> aosp HAL), caf tries to patch our gecko code to match their HAL headers. >> Auto patch failed because recently change file path in bug 972732.> It's not >> a good way to patch gecko code, especially HAL headers changed and patches >> are under device/qcom/b2g_common/patch/all/gecko. How do we handle this kind >> of HAL changes? Can anyone please enlighten me? How do we choose to support >> AOSP HAL or CAF HAL? _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
