odroid-mali: mark package as BROKEN
PATCH 1/1 odroid-mali: mark package as BROKEN
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/
--- package/odroid-mali/Config.in | 10 ++++++++++ 1 file changed, 10 insertions(+)
package/odroid-mali/Config.in +10 -0
@@ -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.
Signature · 1 line
2.7.4
PATCH 1/1 odroid-mali: mark package as BROKEN
Thomas, All,
On 2017-03-04 15:34 +0100, Thomas Petazzoni spake thusly:
Quoted 13 lines
The version of the
khrplatform.hheader bundled with odroid-mali has a definition of thekhronos_intptr_tandkhronos_ssize_tthat 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.
Quoted 5 lines
Fixes:
http://autobuild.buildroot.net/results/ca48bb6291ca16e410edb83b5cdeb24847b6eaee/
Signed-off-by Thomas Petazzoni <[email protected]>
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...
Regards,
Yann E. MORIN.
Quoted 32 lines
--- package/odroid-mali/Config.in | 10 ++++++++++ 1 file changed, 10 insertions(+)package/odroid-mali/Config.in +10
-0@@ -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.Signature · 6 lines
2.7.4 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
Thomas Petazzoni
AppliedPATCH 1/1 odroid-mali: mark package as BROKEN
In reply to Thomas PetazzoniHello,
Quoted 13 lines · Thomas Petazzoni
The version of the
khrplatform.hheader bundled with odroid-mali has a definition of thekhronos_intptr_tandkhronos_ssize_tthat 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.
Quoted 8 lines
Fixes:
http://autobuild.buildroot.net/results/ca48bb6291ca16e410edb83b5cdeb24847b6eaee/
Signed-off-by Thomas Petazzoni <[email protected]>--- package/odroid-mali/Config.in | 10 ++++++++++ 1 file changed, 10 insertions(+)
Applied to master, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 odroid-mali: mark package as BROKEN
Quoted 18 lines · Thomas Petazzoni
Hello,
Quoted 15 lines · Thomas Petazzoni
The version of the
khrplatform.hheader bundled with odroid-mali has a definition of thekhronos_intptr_tandkhronos_ssize_tthat 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:
Quoted 8 lines
Quoted 6 lines
http://autobuild.buildroot.net/results/ca48bb6291ca16e410edb83b5cdeb24847b6eaee/
Signed-off-by Thomas Petazzoni <[email protected]>--- 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
Signature · 6 lines
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
PATCH 1/1 odroid-mali: mark package as BROKEN
Arnout, All,
On 2017-03-05 23:33 +0100, Arnout Vandecappelle spake thusly:
Quoted 26 lines · Thomas Petazzoni
Quoted 16 lines · Thomas Petazzoni
Quoted 15 lines
The version of the
khrplatform.hheader bundled with odroid-mali has a definition of thekhronos_intptr_tandkhronos_ssize_tthat 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:
Quoted 8 lines
Quoted 6 lines
http://autobuild.buildroot.net/results/ca48bb6291ca16e410edb83b5cdeb24847b6eaee/
Signed-off-by Thomas Petazzoni <[email protected]>--- package/odroid-mali/Config.in | 10 ++++++++++ 1 file changed, 10 insertions(+)Applied to master, thanks.
Quoted 7 lines
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 thanSo, I propose to remove all broken packages.
Agreed.
Quoted 2 lines
[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.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 odroid-mali: mark package as BROKEN
Quoted 8 lines
Quoted 8 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> 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
Quoted 8 lines
Quoted 1 line
So, I propose to remove all broken packages.
Agreed.
Quoted 2 lines
[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.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 odroid-mali: mark package as BROKEN
Quoted 10 lines · Peter Korsgaard
Quoted 9 lines
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> 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.
Quoted 8 lines
Quoted 6 lines
Agreed.
Quoted 2 lines
[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 :-)
Quoted 2 lines
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
Signature · 6 lines
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
PATCH 1/1 odroid-mali: mark package as BROKEN
Hello,
Quoted 6 lines · Arnout Vandecappelle
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/
Quoted 3 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 odroid-mali: mark package as BROKEN
Greetings,
Quoted 18 lines
Hello,
Quoted 6 lines · Arnout Vandecappelle
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/
Quoted 7 lines
Quoted 3 lines
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.
PATCH 1/1 odroid-mali: mark package as BROKEN
Hello,
Quoted 2 lines · daggs
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.
Quoted 1 line
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.
Quoted 1 line
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.
Quoted 1 line
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 odroid-mali: mark package as BROKEN
In reply to Arnout VandecappelleHello,
Quoted 10 lines · Arnout Vandecappelle
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 thanSo, 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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 odroid-mali: mark package as BROKEN
Quoted 12 lines · Thomas Petazzoni
Hello,
Quoted 8 lines · Arnout Vandecappelle
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 thanSo, I propose to remove all broken packages.
Quoted 7 lines
Quoted 2 lines
[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.
Quoted 3 lines
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
Signature · 6 lines
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
PATCH 1/1 odroid-mali: mark package as BROKEN
Hello,
Quoted 2 lines · Arnout Vandecappelle
I think an outright removal (with the original contributors in Cc) is an
equally strong incentive.
Agreed :-)
Quoted 5 lines
Quoted 2 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com