[Buildroot] [PATCH 1/1] kodi: Enable raspberry-pi2 build support

Yann E. MORIN yann.morin.1998 at free.fr
Sun May 8 07:38:00 UTC 2016


Benoît, All,

On 2016-04-27 11:08 +0200, Benoît Mauduit spake thusly:
> On 04/26/2016 10:54 PM, Bernd Kuhls wrote:
> > Am Tue, 26 Apr 2016 22:32:56 +0200 schrieb Thomas Petazzoni:
> > 
> >> Hello,
> >>
> >> On Tue, 26 Apr 2016 22:21:14 +0200, Benoît Mauduit wrote:
> >>> The previous commit [ef37472b20894c99cad758397f3cd6b90f933df1] was
> >>> based on a newer version of Kodi :
> >>> "with-platform=raspberry-pi2" is not yet supported in Kodi "Jarvis" 
> > branch.
> >>>
> >>> Backport 2 patches from Kodi master branch into this one.
> >>>
> >>> Signed-off-by: Benoît Mauduit <bmauduit at beneth.fr>
> >>
> >> Thanks. I do remember seeing a report (on IRC ?) that commit
> >> ef37472b20894c99cad758397f3cd6b90f933df1 was indeed causing some
> >> problems.
> >>
> >> Yann, Bernd, can you review/ack this patch from Benoît?
> > 
> > Hi Thomas,
> > 
> > reviewing it will be difficult for me because I can not do a runtime test 
> > because I do not have access to RPI hardware.
> > 
> > Currently I am preparing a patch series for the 17.0-Krypton version 
> > bump, I think I will send the first part of it to my github account in 
> > the coming days after some of my PR for the Kodi project are completed.
> > 
> > Backporting feature patches is, afair, something you do not really like ;)
> > As always, as a normal Kodi user, I do not know any release dates but 
> > 17.0-Krypton did not even reach alpha1 yet so expect several months until 
> > the next version is released. Maybe we should wait for it nonetheless?
> 
> Sorry to ask this, but do you have an explanation about not taking
> upstream patches ? It is not obvious for me.

It's not upstream patch we do not like. What we do not like are feature
patches. We try to limit the number of patches we have against packages,
so we limit ourselves to bug-fix patches.

> Also, I began to implement this fix on my own, and after seeing that
> master branch have implemented this, I thought that it would better to
> backport it. (Plus some addition from my side, that I will try to report
> upstream).

Yes, backporting upstream changes is preferred instead of rolling your
own (unless the backport is not technically possible, of course).

Also, your 'additions' no longer make those patches simple upstream
backports. If they are really needed, then the upstream backports should
be in their own patches, with your additions in separate patches (note
that this might be the case, I haven't looked at the patches).

But since those are feature patches, this discussion is moot anyway...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'



More information about the buildroot mailing list