Re: [Buildroot] [PATCH 1/1] package/mesa3d-demos: fix build failure on musl

[Thomas Petazzoni <thomas.petazzoni@bootlin.com>]

Hello Fiona,

On Wed, 5 Feb 2025 13:59:14 +0100
Fiona Klute <fiona.klute@gmx.de> wrote:

> As far as I remember you need need to build full OpenGL GLX, not just
> EGL. This is the related part of my defconfig:
> 
> BR2_PACKAGE_CAGE=y
> BR2_PACKAGE_MESA3D_DEMOS=y
> BR2_PACKAGE_LIBGLVND=y
> BR2_PACKAGE_MESA3D=y
> BR2_PACKAGE_MESA3D_LLVM=y
> BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_V3D=y
> BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ZINK=y
> BR2_PACKAGE_MESA3D_VULKAN_DRIVER_BROADCOM=y
> BR2_PACKAGE_MESA3D_VULKAN_DRIVER_SWRAST=y
> BR2_PACKAGE_MESA3D_OSMESA_GALLIUM=y
> BR2_PACKAGE_MESA3D_OPENGL_GLX=y
> BR2_PACKAGE_MESA3D_OPENGL_ES=y
> BR2_PACKAGE_XORG7=y
> BR2_PACKAGE_XKEYBOARD_CONFIG=y
> BR2_PACKAGE_LIBDECOR=y
> BR2_PACKAGE_LIBFREEGLUT=y

ACK, I'll give it a try.

> Note that the X stuff is for libraries required for GLX, it's still a
> pure Wayland setup.

A pure wayland setup with X is not... really a pure Wayland setup :-)

> > Basically, when fixing an issue, we should never just fix it. We should
> > always explain since when the problem has started happening.  
> The "uint" use was introduced here:
> 
> https://gitlab.freedesktop.org/mesa/demos/-/commit/813ebef7671f0e54d1b55be9e15ae5586b2b9eb1
> https://gitlab.freedesktop.org/mesa/demos/-/commit/5aaa7faeb4de9497535738830e6ebb8f10071877
> 
> The first and so far only mesa3d-demos release that contains those
> commits is 9.0.0 from March 2023. Considering that was added to
> Buildroot in early July 2023 (commit
> 80304d9911f34f8a0173a4f37d52f93177478cc7) it's probably safe to assume
> it's in all still supported releases.

ACK, thanks for the additional research.

> That said, making "since when" a strict requirement for accepting a fix
> seems problematic to me, because it might discourage people from
> participating. In my situation (getting paid to make things work,
> including upstreaming) it's a perfectly reasonable request. But people
> who send a patch here and there from hobby coding might feel their
> contributions aren't valued, and someone who has a manager breathing
> down their neck and complaining about time wasted might decide it's not
> worth the trouble. In case of doubt having a fix on the development
> branch (and backporting if someone bumps into the problem on a release)
> seems preferable over not having it at all. ;-)

I understand your concern. The issue is that if this effort is not done
by the contributor, then it falls on the Buildroot maintainer who
manages the LTS branch, and (s)he will have to do that on each and
every commit. Clearly, it makes a lot more sense to ask each individual
contributor to do a little bit more effort on their patches rather than
having the LTS maintainer have to do this for 100s of commits that have
to be analyzed to see if they should be backported.

In addition, asking this on contributors also forces them to do a
slightly more in-depth research, which also avoids "bogus" bug fixes
that paper over the problem instead of fixing the real root causes.

Hopefully you will understand those different arguments :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot