[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Thomas Petazzoni]

The version of the khrplatform.h header bundled with odroid-mali has a
definition of the khronos_intptr_t and khronos_ssize_t that doesn't
match the official Khronos registry headers or the Mesa3D headers. Due
to this, it causes conflicts with some packages that redefines those
types (with the correct definitions), such as libepoxy.

Issue reported upstream at: https://github.com/mdrjr/c2_mali/issues/1

Since nobody bothered fixing the issue even though it has been happening
since July 2016 (first build failure at
http://autobuild.buildroot.net/results/ed8d562ae5fdb472a83f9a07b2f755c80c972c34/),
let's mark this package as BROKEN.

Fixes:

  http://autobuild.buildroot.net/results/ca48bb6291ca16e410edb83b5cdeb24847b6eaee/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/odroid-mali/Config.in | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/package/odroid-mali/Config.in b/package/odroid-mali/Config.in
index e5c07f2..5a6af75 100644
--- a/package/odroid-mali/Config.in
+++ b/package/odroid-mali/Config.in
@@ -5,6 +5,16 @@ config BR2_PACKAGE_ODROID_MALI
 	select BR2_PACKAGE_ODROID_SCRIPTS # runtime
 	depends on BR2_TOOLCHAIN_USES_GLIBC
 	depends on BR2_aarch64 || BR2_ARM_EABIHF
+	# The version of the khrplatform.h header bundled with
+	# odroid-mali has a definition of the khronos_intptr_t and
+	# khronos_ssize_t that doesn't match the official Khronos
+	# registry headers or the Mesa3D headers. Due to this, it
+	# causes conflicts with some packages that redefines those
+	# types (with the correct definitions), such as libepoxy.
+	#
+	# Issue reported upstream at:
+	# https://github.com/mdrjr/c2_mali/issues/1
+	depends on BROKEN
 	help
 	  Install the ARM Mali drivers for odroidc2 based systems.
 
-- 
2.7.4

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Yann E. MORIN]

Thomas, All,

On 2017-03-04 15:34 +0100, Thomas Petazzoni spake thusly:
> The version of the khrplatform.h header bundled with odroid-mali has a
> definition of the khronos_intptr_t and khronos_ssize_t that doesn't
> match the official Khronos registry headers or the Mesa3D headers. Due
> to this, it causes conflicts with some packages that redefines those
> types (with the correct definitions), such as libepoxy.
> 
> Issue reported upstream at: https://github.com/mdrjr/c2_mali/issues/1
> 
> Since nobody bothered fixing the issue even though it has been happening
> since July 2016 (first build failure at
> http://autobuild.buildroot.net/results/ed8d562ae5fdb472a83f9a07b2f755c80c972c34/),
> let's mark this package as BROKEN.
> 
> Fixes:
> 
>   http://autobuild.buildroot.net/results/ca48bb6291ca16e410edb83b5cdeb24847b6eaee/
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Upstream does not really exist: a single one-shot drop of binary blobs,
with hsitory limited to no more than two months and 7 comits, all one
year ago...

Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  package/odroid-mali/Config.in | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/package/odroid-mali/Config.in b/package/odroid-mali/Config.in
> index e5c07f2..5a6af75 100644
> --- a/package/odroid-mali/Config.in
> +++ b/package/odroid-mali/Config.in
> @@ -5,6 +5,16 @@ config BR2_PACKAGE_ODROID_MALI
>  	select BR2_PACKAGE_ODROID_SCRIPTS # runtime
>  	depends on BR2_TOOLCHAIN_USES_GLIBC
>  	depends on BR2_aarch64 || BR2_ARM_EABIHF
> +	# The version of the khrplatform.h header bundled with
> +	# odroid-mali has a definition of the khronos_intptr_t and
> +	# khronos_ssize_t that doesn't match the official Khronos
> +	# registry headers or the Mesa3D headers. Due to this, it
> +	# causes conflicts with some packages that redefines those
> +	# types (with the correct definitions), such as libepoxy.
> +	#
> +	# Issue reported upstream at:
> +	# https://github.com/mdrjr/c2_mali/issues/1
> +	depends on BROKEN
>  	help
>  	  Install the ARM Mali drivers for odroidc2 based systems.
>  
> -- 
> 2.7.4
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Thomas Petazzoni]

Hello,

On Sat,  4 Mar 2017 15:34:19 +0100, Thomas Petazzoni wrote:
> The version of the khrplatform.h header bundled with odroid-mali has a
> definition of the khronos_intptr_t and khronos_ssize_t that doesn't
> match the official Khronos registry headers or the Mesa3D headers. Due
> to this, it causes conflicts with some packages that redefines those
> types (with the correct definitions), such as libepoxy.
> 
> Issue reported upstream at: https://github.com/mdrjr/c2_mali/issues/1
> 
> Since nobody bothered fixing the issue even though it has been happening
> since July 2016 (first build failure at
> http://autobuild.buildroot.net/results/ed8d562ae5fdb472a83f9a07b2f755c80c972c34/),
> let's mark this package as BROKEN.
> 
> Fixes:
> 
>   http://autobuild.buildroot.net/results/ca48bb6291ca16e410edb83b5cdeb24847b6eaee/
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  package/odroid-mali/Config.in | 10 ++++++++++
>  1 file changed, 10 insertions(+)

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Arnout Vandecappelle]

On 05-03-17 21:37, Thomas Petazzoni wrote:
> Hello,
> 
> On Sat,  4 Mar 2017 15:34:19 +0100, Thomas Petazzoni wrote:
>> The version of the khrplatform.h header bundled with odroid-mali has a
>> definition of the khronos_intptr_t and khronos_ssize_t that doesn't
>> match the official Khronos registry headers or the Mesa3D headers. Due
>> to this, it causes conflicts with some packages that redefines those
>> types (with the correct definitions), such as libepoxy.
>>
>> Issue reported upstream at: https://github.com/mdrjr/c2_mali/issues/1
>>
>> Since nobody bothered fixing the issue even though it has been happening
>> since July 2016 (first build failure at
>> http://autobuild.buildroot.net/results/ed8d562ae5fdb472a83f9a07b2f755c80c972c34/),
>> let's mark this package as BROKEN.
>>
>> Fixes:
>>
>>   http://autobuild.buildroot.net/results/ca48bb6291ca16e410edb83b5cdeb24847b6eaee/
>>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> ---
>>  package/odroid-mali/Config.in | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
> 
> Applied to master, thanks.

 I'm obviously late with commenting on this, but I think marking things as
BROKEN is wrong. It bypasses the legacy mechanism so it disappears without
notice. Also, BROKEN packages languish there for years without ever anyone
taking a look. Sometimes things do get repaired, but re-adding the package is
not much more complicated than

 So, I propose to remove all broken packages.

 [I have the feeling we discussed this kind of thing at some BR devel meeting at
some point, but I can't find it.]

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Yann E. MORIN]

Arnout, All,

On 2017-03-05 23:33 +0100, Arnout Vandecappelle spake thusly:
> On 05-03-17 21:37, Thomas Petazzoni wrote:
> > On Sat,  4 Mar 2017 15:34:19 +0100, Thomas Petazzoni wrote:
> >> The version of the khrplatform.h header bundled with odroid-mali has a
> >> definition of the khronos_intptr_t and khronos_ssize_t that doesn't
> >> match the official Khronos registry headers or the Mesa3D headers. Due
> >> to this, it causes conflicts with some packages that redefines those
> >> types (with the correct definitions), such as libepoxy.
> >>
> >> Issue reported upstream at: https://github.com/mdrjr/c2_mali/issues/1
> >>
> >> Since nobody bothered fixing the issue even though it has been happening
> >> since July 2016 (first build failure at
> >> http://autobuild.buildroot.net/results/ed8d562ae5fdb472a83f9a07b2f755c80c972c34/),
> >> let's mark this package as BROKEN.
> >>
> >> Fixes:
> >>
> >>   http://autobuild.buildroot.net/results/ca48bb6291ca16e410edb83b5cdeb24847b6eaee/
> >>
> >> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >> ---
> >>  package/odroid-mali/Config.in | 10 ++++++++++
> >>  1 file changed, 10 insertions(+)
> > 
> > Applied to master, thanks.
> 
>  I'm obviously late with commenting on this, but I think marking things as
> BROKEN is wrong. It bypasses the legacy mechanism so it disappears without
> notice. Also, BROKEN packages languish there for years without ever anyone
> taking a look. Sometimes things do get repaired, but re-adding the package is
> not much more complicated than
> 
>  So, I propose to remove all broken packages.

Agreed.

>  [I have the feeling we discussed this kind of thing at some BR devel meeting at
> some point, but I can't find it.]

Yes we did. And IIRC we agreed to get rid of BROKEN altogether.

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Thomas Petazzoni]

Hello,

On Sun, 5 Mar 2017 23:33:56 +0100, Arnout Vandecappelle wrote:

>  I'm obviously late with commenting on this, but I think marking things as
> BROKEN is wrong. It bypasses the legacy mechanism so it disappears without
> notice. Also, BROKEN packages languish there for years without ever anyone
> taking a look. Sometimes things do get repaired, but re-adding the package is
> not much more complicated than
> 
>  So, I propose to remove all broken packages.
> 
>  [I have the feeling we discussed this kind of thing at some BR devel meeting at
> some point, but I can't find it.]

True. But for this one case, the developer contributing the package is
still active, submitting patches for other things from time to time. So
I was hoping that a stronger hint at "please fix your packages
otherwise they'll get removed" was in order.

Let's say that we'll remove this package before the 2017.05 release if
nobody unbreaks it?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Arnout Vandecappelle]

On 05-03-17 23:40, Thomas Petazzoni wrote:
> Hello,
> 
> On Sun, 5 Mar 2017 23:33:56 +0100, Arnout Vandecappelle wrote:
> 
>>  I'm obviously late with commenting on this, but I think marking things as
>> BROKEN is wrong. It bypasses the legacy mechanism so it disappears without
>> notice. Also, BROKEN packages languish there for years without ever anyone
>> taking a look. Sometimes things do get repaired, but re-adding the package is
>> not much more complicated than
>>
>>  So, I propose to remove all broken packages.
>>
>>  [I have the feeling we discussed this kind of thing at some BR devel meeting at
>> some point, but I can't find it.]
> 
> True. But for this one case, the developer contributing the package is
> still active, submitting patches for other things from time to time. So
> I was hoping that a stronger hint at "please fix your packages
> otherwise they'll get removed" was in order.

 I think an outright removal (with the original contributors in Cc) is an
equally strong incentive.

> 
> Let's say that we'll remove this package before the 2017.05 release if
> nobody unbreaks it?

 And what with the 6 other packages (or package options) marked as broken? Can
we kill it?

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Thomas Petazzoni]

Hello,

On Mon, 6 Mar 2017 00:35:54 +0100, Arnout Vandecappelle wrote:

>  I think an outright removal (with the original contributors in Cc) is an
> equally strong incentive.

Agreed :-)

> > Let's say that we'll remove this package before the 2017.05 release if
> > nobody unbreaks it?  
> 
>  And what with the 6 other packages (or package options) marked as broken? Can
> we kill it?

Those ones have been marked as BROKEN since even longer, so I'm all for
removing them.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 >> I'm obviously late with commenting on this, but I think marking things as
 >> BROKEN is wrong. It bypasses the legacy mechanism so it disappears without
 >> notice. Also, BROKEN packages languish there for years without ever anyone
 >> taking a look. Sometimes things do get repaired, but re-adding the package is
 >> not much more complicated than
 >> 
 >> So, I propose to remove all broken packages.

 > Agreed.

 >> [I have the feeling we discussed this kind of thing at some BR devel meeting at
 >> some point, but I can't find it.]

 > Yes we did. And IIRC we agreed to get rid of BROKEN altogether.

I think you are mixing it up with BR2_DEPRECATED.

With that said, if nobody cares about fixing the package, then I'm OK
with removing it. Lets give it a bit of time and see what happens.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Arnout Vandecappelle]

On 07-03-17 16:42, Peter Korsgaard wrote:
>>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> 
>  >> I'm obviously late with commenting on this, but I think marking things as
>  >> BROKEN is wrong. It bypasses the legacy mechanism so it disappears without
>  >> notice. Also, BROKEN packages languish there for years without ever anyone
>  >> taking a look. Sometimes things do get repaired, but re-adding the package is
>  >> not much more complicated than
>  >> 
>  >> So, I propose to remove all broken packages.
> 
>  > Agreed.
> 
>  >> [I have the feeling we discussed this kind of thing at some BR devel meeting at
>  >> some point, but I can't find it.]
> 
>  > Yes we did. And IIRC we agreed to get rid of BROKEN altogether.
> 
> I think you are mixing it up with BR2_DEPRECATED.

 That's why I couldn't find it :-)


> With that said, if nobody cares about fixing the package, then I'm OK
> with removing it. Lets give it a bit of time and see what happens.

 The problem with BROKEN is the same as with BR2_LEGACY: it doesn't appear in
the legacy menu. You could argue that BROKEN is different because it simply
can't be used at all. However, for the user there is no difference: it used to
work (I hope we can assume that when a package is added, it has worked at least
once on at least one platform...), and after a Buildroot update it suddenly
vanishes.

 So I propose the following: we can still mark things as BROKEN as a way to
motivate people to fix them, but during the RC month we properly remove them and
add a legacy entry.

 Patches for removing the broken stuff are coming.


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Thomas Petazzoni]

Hello,

On Tue, 7 Mar 2017 18:05:02 +0100, Arnout Vandecappelle wrote:

>  The problem with BROKEN is the same as with BR2_LEGACY: it doesn't appear in
> the legacy menu. You could argue that BROKEN is different because it simply
> can't be used at all. However, for the user there is no difference: it used to
> work (I hope we can assume that when a package is added, it has worked at least
> once on at least one platform...), and after a Buildroot update it suddenly
> vanishes.

Agreed. In this specific case, I believe odroid-mali definitely works
for some situations, so there are certainly valid use cases for the
package as it is today, i.e it is not *completely* broken. But it
causes some build failures, which nobody has taken care of, and
upstream is unlikely to be responsive/

>  So I propose the following: we can still mark things as BROKEN as a way to
> motivate people to fix them, but during the RC month we properly remove them and
> add a legacy entry.

Full ACK.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[daggs]

Greetings,

>
> Hello,
> 
> On Tue, 7 Mar 2017 18:05:02 +0100, Arnout Vandecappelle wrote:
> 
> >  The problem with BROKEN is the same as with BR2_LEGACY: it doesn't appear in
> > the legacy menu. You could argue that BROKEN is different because it simply
> > can't be used at all. However, for the user there is no difference: it used to
> > work (I hope we can assume that when a package is added, it has worked at least
> > once on at least one platform...), and after a Buildroot update it suddenly
> > vanishes.
> 
> Agreed. In this specific case, I believe odroid-mali definitely works
> for some situations, so there are certainly valid use cases for the
> package as it is today, i.e it is not *completely* broken. But it
> causes some build failures, which nobody has taken care of, and
> upstream is unlikely to be responsive/
> 
> >  So I propose the following: we can still mark things as BROKEN as a way to
> > motivate people to fix them, but during the RC month we properly remove them and
> > add a legacy entry.
> 
> Full ACK.
> 
> Thomas

my apologies, I've missed the initial mail with all the mails I'm getting.
I have a more direct line of communication to upstream, I'll try contacting them. will update asap.

as there is no x11 driver for this board (still pending review, not that it matters now), the usage of this pkg is rather limited.
the main usage is to run kodi, afaik kodi doesn't depends on libepoxy, so depending the pkg on kodi for now might be a valid solution.
I have fairly recent img (built 2 weeks ago based on the synced kodi 17 branch) and it compiled well without any errors.

thoughts?

DAgg.

[Buildroot] [PATCH] odroid-mali: mark package as BROKEN

[Thomas Petazzoni]

Hello,

On Wed, 8 Mar 2017 07:55:14 +0100, daggs wrote:

> my apologies, I've missed the initial mail with all the mails I'm getting.
> I have a more direct line of communication to upstream, I'll try contacting them. will update asap.

OK, thanks.

> as there is no x11 driver for this board (still pending review, not that it matters now), the usage of this pkg is rather limited.

Well, I did some comments on your xdriver_xf86-video-odroidc2 on
December 18, and you never came back with a new iteration of the
patches. So I did an additional review yesterday, and marked the
patches as Changes Requested in patchwork.

> the main usage is to run kodi, afaik kodi doesn't depends on libepoxy, so depending the pkg on kodi for now might be a valid solution.

This is really not clean at all, and I'm not sure it won't create a
circular dependency at the Config.in level.

> thoughts?

I think it's much easier to fix the original problem. We can fix the
issue by using the official khrplatform.h header, *BUT* I wanted
upstream to confirm that this is the correct thing to do. Indeed, the
khrplatform.h provided by the odroid-mali code does not use the same
size for the Khronos data types as the official Khronos header.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com