Re: [gentoo-dev] [PATCH] meson.eclass: require at least meson-0.41.1
Ühel kenal päeval, P, 22.07.2018 kell 20:27, kirjutas Zac Medico:
> Require newer meson in order to avoid build failures triggered
> if >=meson-0.41.1 is not installed soon enough. For example,
> I experienced bug 649264 because I upgraded xorg-proto and
> libxshmfence packages before meson.
>
> Fixes: https://bugs.gentoo.org/649264
Closes, not Fixes?
> ---
> eclass/meson.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index f2202a04593..2523bec57ac 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -59,7 +59,7 @@ EXPORT_FUNCTIONS src_configure src_compile src_test
> src_install
> if [[ -z ${_MESON_ECLASS} ]]; then
> _MESON_ECLASS=1
>
> -MESON_DEPEND=">=dev-util/meson-0.40.0
> +MESON_DEPEND=">=dev-util/meson-0.41.1
By my understanding this should be 0.44.1, not 0.41.1.
At least 0.43.0 is one of the broken versions.
0.44.1 is also the lowest available version in tree; raising
MESON_DEPEND to that would as a side-effect not require ebuilds to have
their own meson depend, when they need newer versions (>=0.41 was
common in gnome 3.26, might be >=0.44 in newer).
> >=dev-util/ninja-1.7.2"
>
> # @ECLASS-VARIABLE: MESON_AUTO_DEPEND
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] meson.eclass: require at least meson-0.41.1
On 07/23/2018 01:08 AM, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 22.07.2018 kell 20:27, kirjutas Zac Medico:
>> Require newer meson in order to avoid build failures triggered
>> if >=meson-0.41.1 is not installed soon enough. For example,
>> I experienced bug 649264 because I upgraded xorg-proto and
>> libxshmfence packages before meson.
>>
>> Fixes: https://bugs.gentoo.org/649264
>
> Closes, not Fixes?
Closes is more accurate, yes.
>> ---
>> eclass/meson.eclass | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
>> index f2202a04593..2523bec57ac 100644
>> --- a/eclass/meson.eclass
>> +++ b/eclass/meson.eclass
>> @@ -59,7 +59,7 @@ EXPORT_FUNCTIONS src_configure src_compile src_test
>> src_install
>> if [[ -z ${_MESON_ECLASS} ]]; then
>> _MESON_ECLASS=1
>>
>> -MESON_DEPEND=">=dev-util/meson-0.40.0
>> +MESON_DEPEND=">=dev-util/meson-0.41.1
>
> By my understanding this should be 0.44.1, not 0.41.1.
> At least 0.43.0 is one of the broken versions.
0.44.1 is what I meant to type, yes.
> 0.44.1 is also the lowest available version in tree; raising
> MESON_DEPEND to that would as a side-effect not require ebuilds to have
> their own meson depend, when they need newer versions (>=0.41 was
> common in gnome 3.26, might be >=0.44 in newer).
Great!
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] meson.eclass: require at least meson-0.41.1
On Sun, Jul 22, 2018 at 11:27 PM Zac Medico wrote: > > Require newer meson in order to avoid build failures triggered > if >=meson-0.41.1 is not installed soon enough. For example, > I experienced bug 649264 because I upgraded xorg-proto and > libxshmfence packages before meson. > > Fixes: https://bugs.gentoo.org/649264 I suggest jumping to 0.45.1 (latest stable on all archs). Feel free to push that.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Mon, Jul 23, 2018 at 1:47 AM Andreas K. Huettel wrote: > > Am Donnerstag, 19. Juli 2018, 23:51:17 CEST schrieb Ben Kohler: > > Hello, > > > > I'd like to propose adding USE=udev to our linux profiles (in > > profiles/default/linux/make.defaults probably). This flag is already > > enabled on desktop profiles but it also affects quite a few packages > > > > Any objections to this idea? > > We removed the dedicated "server profiles" and told everyone > "Don't ever use -*"; if you want to have a sane minimal set of features use > the base profile as e.g. default/linux/amd64/17.0". > > If with USE=udev this profile still fulfills the definition of "sane minimal > set of features", then it's fine. > > (Keep in mind, we have all sorts of people out there running gentoo not only > on desktops or beefy servers.) > > Otherwise it should stay in desktop profile. USE="udev" is a sane default for anything that will be running on real or emulated hardware. It might not be necessary for containers, which don't do any hardware management.
[gentoo-dev] RFC: gles global USE flag, USE=opengl clarifying
Hello, Currently we have rather a mess in terms of OpenGL API handling. I think much of it comes from USE=opengl being rather vague - is it supposed to mean "Use desktop GL", "Use GLX", or "Enable OpenGL support". All of these mean quite different things: * desktop GL means full OpenGL API, which in turn can be either used via GLX platform (X11 only) or EGL platform. * GLX means GLX platform - usable only on X11; all good and same as desktop GL in the past, but we have people wanting wayland-only now (and YES, desktop GL via EGL platform _is_ a thing), and GLX obviously isn't something that works in native wayland. * GL support could mean 3D via OpenGL in general; be it OpenGL, GLESv2, GLESv3... To make things easier to follow, there are basically three different concepts and potential choices to make: * API * Platform * Windowing system API is either "full desktop" OpenGL (think e.g. OpenGL 4.5), or GLES; GLES has multiple versions, but in practice it's GLESv2 with optional support for GLESv3 - however afaik latest mesa supports GLESv3 too whenever GLESv2 is built. Platform is either GLX or EGL. GLX only works in combination with "full desktop" OpenGL; EGL can work with either. For non-Linux there's also CGL (OSX), WGL (Windows), EAGL (iOS) and more. Can be interesting for Gentoo Prefix. "EGL is an interface between Khronos rendering APIs such as OpenGL ES or OpenVG and the underlying native platform window system." - thus the third choice with EGL platform - windowing system. This then is about supporting a certain graphics environment with EGL (with GLX that can be taken as just always X). This can be for example x11, wayland, GBM (think rendering 3D directly on top of a KMS terminal), win32, cocoa, android, vivante framebuffer (with proprietary vivante 3D stack; not applicable to open source etnaviv), DispmanX (RPi), etc. This can be a choice especially for certain kind of OpenGL libraries; one big example I know of is GStreamer GL libraries. Anyhow, here's an initial proposal to try to sort it out via a USE=gles global USE flag and a set of guidelines how to use it together with a USE=opengl and other related USE flags in ebuilds: use.desc: opengl - Add support for desktop OpenGL (3D graphics) gles - Add support for OpenGL ES, or prefer it over desktop OpenGL. This should usually only be enabled globally on embedded systems that do not support full desktop GL. [How is it correct to refer to "full desktop" GL without it being confusing with OpenGL in general?] Guidelines: * If package has optional GL support in general (can work with either desktop GL or GLES when OpenGL is enabled; doesn't care which one is there), use both opengl and gles in IUSE and enable GL support and ebuild logic when either is enabled * If package is fully about OpenGL (GL itself isn't optional) and supports either desktop GL or GLES, but not both at once: IUSE="gles" and use GLES if that is set, "full desktop" GL otherwise. * If package is fully about OpenGL (GL itself isn't optional) and supports either desktop GL or GLES, including both at once: IUSE="gles +opengl" and use whichever is enabled. As GL isn't optional as a whole, require at least one of them: REQUIRED_USE="|| ( gles opengl )". * If package has optional OpenGL support and needs specific logic for the chosen API: IUSE="gles opengl" or IUSE="gles +opengl", depending if GL should be default enabled (albeit we might want to revise this via profile level defaults flag instead?) - don't default enable gles, as it's not a common use case and such embedded system users will have it globally enabled anyways. ** Enable any of the GL logic only if either gles or opengl is enabled. ** If both are supported at the same time, enable whichever is chosen by user (this could often mean also passing a generic --enable-gl passing if either USE is set and then specifying the API to use with a separate build flag). ** If both are not supported at the same time, set REQUIRED_USE="gles? ( !opengl )", use whichever is chosen (keeping in mind that both might be disabled → no GL at all). * If package needs to provide choices for the used GL platform or windowing system, while GL itself is optional as a whole, don't forget to keep the dependencies and other logic for the platform/WS conditional to USE=gles and/or USE=opengl. This is usually easiest to handle via GL_DEPS helper variable with dependencies applicable to either and then putting it in as e.g. "opengl? ( $GL_DEPS ) gles? ( $GL_DEPS )" together with any specific ones; similar for certain needed REQUIRED_USEs, with appropriate conditional blocks in src_configure(). * If package supports X11 via either GLX or EGL x11 windowing system, just enable GLX via USE="opengl X" (or USE="-gles X" if no opengl in IUSE) and EGL x11 via USE="egl X". Don't forget that "egl X" should pull in EGL and X dependencies necessary for it only if GL as a whole is enabled, if that is optional. * It is OK to have certain REQUIRED_US
[gentoo-dev] Deprecation of virtual/libmysqlclient and virtual/mysql as providers for libmysqlclient.so
With the current state of the forks of MySQL diverging, the client libraries are no longer compatible. Since virtual packages cannot handle rebuilds of subscribed packages when a consumer changes, the following action is to be taken by all developers: If you need libmysqlclient.so, please depend on dev-db/mysql-connector-c. If you need or can use libmariadb.so, please depend on dev-db/mariadb-connector-c. (Yes the above packages coexist just fine.) Please remove references to virtual/libmysqlclient as it does not work as I intended (and explained above). This virtual will be last-rites once nothing depends on it. Please remove all DEPEND on virtual/mysql where it is used for libraries. virtual/mysql is the client and server tools *only*. It is not correct to rely on this for libraries any longer. A good example for DEPEND is tests where the client/server binaries are run. RDEPEND for the purpose of running client/server is fine for virtual/mysql. Almost all of the consumers of virtual/mysql have already been updated (save mysql-cluster). Some are already stable. At a point in the future, likely in 2019, the compatibility DEPEND that exist in the consumers will be removed and may break packages which are not updated. In the coming months, I will try my best to test and report bugs on packages which I can find. I welcome any discussion on the details, but this is the only sane move for Gentoo and the ABI incompatibilities that exist on the client libraries. Thank you, Brian Evans signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: gles global USE flag, USE=opengl clarifying
On Mon, 23 Jul 2018 20:11:37 +0300 Mart Raudsepp wrote: > Currently we have rather a mess in terms of OpenGL API handling. > ... > Guidelines: > ... Thanks for discussing this with me earlier even though I don't feel I have a large say in the matter. Having faced this mess on ARM, it can be a little frustrating so any improvements are very welcome. +1 -- James Le Cuirot (chewi) Gentoo Linux Developer pgpCzqykaKfOp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] meson.eclass: require at least meson-0.41.1
On 07/23/2018 07:56 AM, Mike Gilbert wrote: > On Sun, Jul 22, 2018 at 11:27 PM Zac Medico wrote: >> >> Require newer meson in order to avoid build failures triggered >> if >=meson-0.41.1 is not installed soon enough. For example, >> I experienced bug 649264 because I upgraded xorg-proto and >> libxshmfence packages before meson. >> >> Fixes: https://bugs.gentoo.org/649264 > > I suggest jumping to 0.45.1 (latest stable on all archs). Feel free to > push that. Pushed: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bbe649a35dc8e06e55abfdf8e98a743d1e50d5a0 -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: gles global USE flag, USE=opengl clarifying
On Mon, Jul 23, 2018 at 10:11 AM, Mart Raudsepp wrote: > Hello, > > Currently we have rather a mess in terms of OpenGL API handling. > I think much of it comes from USE=opengl being rather vague - is it > supposed to mean "Use desktop GL", "Use GLX", or "Enable OpenGL > support". All of these mean quite different things: > * desktop GL means full OpenGL API, which in turn can be either used > via GLX platform (X11 only) or EGL platform. > * GLX means GLX platform - usable only on X11; all good and same as > desktop GL in the past, but we have people wanting wayland-only now > (and YES, desktop GL via EGL platform _is_ a thing), and GLX obviously > isn't something that works in native wayland. > * GL support could mean 3D via OpenGL in general; be it OpenGL, GLESv2, > GLESv3... > > To make things easier to follow, there are basically three different > concepts and potential choices to make: > > * API > * Platform > * Windowing system > > API is either "full desktop" OpenGL (think e.g. OpenGL 4.5), or GLES; > GLES has multiple versions, but in practice it's GLESv2 with optional > support for GLESv3 - however afaik latest mesa supports GLESv3 too > whenever GLESv2 is built. > > Platform is either GLX or EGL. GLX only works in combination with "full > desktop" OpenGL; EGL can work with either. > For non-Linux there's also CGL (OSX), WGL (Windows), EAGL (iOS) and > more. Can be interesting for Gentoo Prefix. > > "EGL is an interface between Khronos rendering APIs such as OpenGL ES > or OpenVG and the underlying native platform window system." - thus the > third choice with EGL platform - windowing system. This then is about > supporting a certain graphics environment with EGL (with GLX that can > be taken as just always X). > This can be for example x11, wayland, GBM (think rendering 3D directly > on top of a KMS terminal), win32, cocoa, android, vivante framebuffer > (with proprietary vivante 3D stack; not applicable to open source > etnaviv), DispmanX (RPi), etc. > This can be a choice especially for certain kind of OpenGL libraries; > one big example I know of is GStreamer GL libraries. > > > > Anyhow, here's an initial proposal to try to sort it out via a USE=gles > global USE flag and a set of guidelines how to use it together with a > USE=opengl and other related USE flags in ebuilds: > > > use.desc: > opengl - Add support for desktop OpenGL (3D graphics) > gles - Add support for OpenGL ES, or prefer it over desktop OpenGL. This > should usually only be enabled globally on embedded systems that do not > support full desktop GL. > > [How is it correct to refer to "full desktop" GL without it being > confusing with OpenGL in general?] That's what people on my team call it to differentiate. "Desktop" vs ES. > Guidelines: > > * If package has optional GL support in general (can work with either > desktop GL or GLES when OpenGL is enabled; doesn't care which one is > there), use both opengl and gles in IUSE and enable GL support and > ebuild logic when either is enabled Sounds good. > * If package is fully about OpenGL (GL itself isn't optional) and > supports either desktop GL or GLES, but not both at once: IUSE="gles" > and use GLES if that is set, "full desktop" GL otherwise. Probably the best thing to do. > * If package is fully about OpenGL (GL itself isn't optional) and > supports either desktop GL or GLES, including both at once: IUSE="gles > +opengl" and use whichever is enabled. As GL isn't optional as a whole, > require at least one of them: REQUIRED_USE="|| ( gles opengl )". Sounds good. > * If package has optional OpenGL support and needs specific logic for > the chosen API: IUSE="gles opengl" or IUSE="gles +opengl", depending if > GL should be default enabled (albeit we might want to revise this via > profile level defaults flag instead?) - don't default enable gles, as > it's not a common use case and such embedded system users will have it > globally enabled anyways. > ** Enable any of the GL logic only if either gles or opengl is enabled. > ** If both are supported at the same time, enable whichever is chosen > by user (this could often mean also passing a generic --enable-gl > passing if either USE is set and then specifying the API to use with a > separate build flag). > ** If both are not supported at the same time, set REQUIRED_USE="gles? > ( !opengl )", use whichever is chosen (keeping in mind that both might > be disabled → no GL at all). > > * If package needs to provide choices for the used GL platform or > windowing system, while GL itself is optional as a whole, don't forget > to keep the dependencies and other logic for the platform/WS > conditional to USE=gles and/or USE=opengl. This is usually easiest to > handle via GL_DEPS helper variable with dependencies applicable to > either and then putting it in as e.g. "opengl? ( $GL_DEPS ) gles? ( > $GL_DEPS )" together with any specific ones; similar for certain needed > REQUIRED_USEs, with appropriate conditional blocks in sr
Re: [gentoo-dev] Deprecation of virtual/libmysqlclient and virtual/mysql as providers for libmysqlclient.so
On Mon, 2018-07-23 at 14:18 -0400, Brian Evans wrote: > With the current state of the forks of MySQL diverging, the client > libraries are no longer compatible. > > Since virtual packages cannot handle rebuilds of subscribed packages > when a consumer changes, the following action is to be taken by all > developers: > > If you need libmysqlclient.so, please depend on dev-db/mysql- > connector-c. > If you need or can use libmariadb.so, please depend on > dev-db/mariadb-connector-c. > > (Yes the above packages coexist just fine.) > > Please remove references to virtual/libmysqlclient as it does not > work > as I intended (and explained above). This virtual will be last-rites > once nothing depends on it. > > Please remove all DEPEND on virtual/mysql where it is used for > libraries. > virtual/mysql is the client and server tools *only*. > It is not correct to rely on this for libraries any longer. > A good example for DEPEND is tests where the client/server binaries > are run. > RDEPEND for the purpose of running client/server is fine for > virtual/mysql. > > Almost all of the consumers of virtual/mysql have already been > updated > (save mysql-cluster). Some are already stable. > > At a point in the future, likely in 2019, the compatibility DEPEND > that > exist in the consumers will be removed and may break packages which > are > not updated. > > In the coming months, I will try my best to test and report bugs on > packages which I can find. > > I welcome any discussion on the details, but this is the only sane > move > for Gentoo and the ABI incompatibilities that exist on the client > libraries. > > Thank you, > > Brian Evans > How do you plan on dispatching against them at compile/link-time, i.e. USE=libav/graphicsmagick/libressl? David
