| Message ID | 20220519064312.391164-1-f_l_k@t-online.de |
|---|---|
| State | New |
| Headers | show |
| Series | [meta-oe,RFC,1/2] libdecor: initial add recipe | expand |
Hi Markus, Il giorno Thu, 19 May 2022 08:43:11 +0200 "Markus Volk" <f_l_k@t-online.de> ha scritto: > libdecor is a client-side decoration library for Wayland clients. It > is used by libsdl2 for window decoration and is required to provide > decoration for shells that use client-side decoration such as > gnome-shell or weston. > > Signed-off-by: Markus Volk <f_l_k@t-online.de> I'm afraid we're having an issue with this patch as well: AssertionError: The following recipes do not have a maintainer assigned to them. Please add an entry to meta/conf/distro/include/maintainers.inc file. libdecor (/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb) https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/3547/steps/14/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3604/steps/15/logs/stdio And also this warning: WARNING: Nothing RPROVIDES 'nativesdk-libdecor' (but virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for 'nativesdk-libdecor' NOTE: Runtime target 'nativesdk-libdecor' is unbuildable, removing... Missing or unbuildable dependency chain was: ['nativesdk-libdecor'] WARNING: Nothing RPROVIDES 'nativesdk-libdecor-dev' (but virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for 'nativesdk-libdecor-dev' NOTE: Runtime target 'nativesdk-libdecor-dev' is unbuildable, removing... Missing or unbuildable dependency chain was: ['nativesdk-libdecor-dev'] https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/5543/steps/12/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/4571/steps/12/logs/stdio
Also, does this need to be in core (as opposed to meta-oe)? Why? Alex On Thu, 19 May 2022 at 18:43, Luca Ceresoli via lists.openembedded.org <luca.ceresoli=bootlin.com@lists.openembedded.org> wrote: > > Hi Markus, > > Il giorno Thu, 19 May 2022 08:43:11 +0200 > "Markus Volk" <f_l_k@t-online.de> ha scritto: > > > libdecor is a client-side decoration library for Wayland clients. It > > is used by libsdl2 for window decoration and is required to provide > > decoration for shells that use client-side decoration such as > > gnome-shell or weston. > > > > Signed-off-by: Markus Volk <f_l_k@t-online.de> > > I'm afraid we're having an issue with this patch as well: > > AssertionError: > The following recipes do not have a maintainer assigned to them. Please > add an entry to meta/conf/distro/include/maintainers.inc file. libdecor > (/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb) > > https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/3547/steps/14/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3604/steps/15/logs/stdio > > And also this warning: > > WARNING: Nothing RPROVIDES 'nativesdk-libdecor' (but > virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb > RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for > 'nativesdk-libdecor' NOTE: Runtime target 'nativesdk-libdecor' is > unbuildable, removing... Missing or unbuildable dependency chain was: > ['nativesdk-libdecor'] WARNING: Nothing RPROVIDES > 'nativesdk-libdecor-dev' (but > virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb > RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for > 'nativesdk-libdecor-dev' NOTE: Runtime target 'nativesdk-libdecor-dev' > is unbuildable, removing... Missing or unbuildable dependency chain > was: ['nativesdk-libdecor-dev'] > > https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/5543/steps/12/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/4571/steps/12/logs/stdio > > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#165903): https://lists.openembedded.org/g/openembedded-core/message/165903 > Mute This Topic: https://lists.openembedded.org/mt/91203655/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
It doesn't need to be in core, but i would call having window decoration a core component because otherwise things will just not work as expected for weston/gnome-shell. I could also send that recipe to meta-oe if you prefer or just store it in meta-wayland since its wayland related stuff but if you aim to support libsdl in a proper way this recipe should be around somewhere i think. Personally i prefer sway. It has server side decoration and there is no need for libdecor. Markus Am 19.05.22 um 18:46 schrieb Alexander Kanavin: > Also, does this need to be in core (as opposed to meta-oe)? Why? > > Alex > > On Thu, 19 May 2022 at 18:43, Luca Ceresoli via lists.openembedded.org > <luca.ceresoli=bootlin.com@lists.openembedded.org> wrote: >> Hi Markus, >> >> Il giorno Thu, 19 May 2022 08:43:11 +0200 >> "Markus Volk"<f_l_k@t-online.de> ha scritto: >> >>> libdecor is a client-side decoration library for Wayland clients. It >>> is used by libsdl2 for window decoration and is required to provide >>> decoration for shells that use client-side decoration such as >>> gnome-shell or weston. >>> >>> Signed-off-by: Markus Volk<f_l_k@t-online.de> >> I'm afraid we're having an issue with this patch as well: >> >> AssertionError: >> The following recipes do not have a maintainer assigned to them. Please >> add an entry to meta/conf/distro/include/maintainers.inc file. libdecor >> (/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb) >> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/3547/steps/14/logs/stdio >> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3604/steps/15/logs/stdio >> >> And also this warning: >> >> WARNING: Nothing RPROVIDES 'nativesdk-libdecor' (but >> virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb >> RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for >> 'nativesdk-libdecor' NOTE: Runtime target 'nativesdk-libdecor' is >> unbuildable, removing... Missing or unbuildable dependency chain was: >> ['nativesdk-libdecor'] WARNING: Nothing RPROVIDES >> 'nativesdk-libdecor-dev' (but >> virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb >> RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for >> 'nativesdk-libdecor-dev' NOTE: Runtime target 'nativesdk-libdecor-dev' >> is unbuildable, removing... Missing or unbuildable dependency chain >> was: ['nativesdk-libdecor-dev'] >> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/5543/steps/12/logs/stdio >> https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/4571/steps/12/logs/stdio >> >> -- >> Luca Ceresoli, Bootlin >> Embedded Linux and Kernel engineering >> https://bootlin.com >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#165903):https://lists.openembedded.org/g/openembedded-core/message/165903 >> Mute This Topic:https://lists.openembedded.org/mt/91203655/1686489 >> Group Owner:openembedded-core+owner@lists.openembedded.org >> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >>
If it is in core, there should be something in core that consumes and makes use of it, and preferably automated tests for it. Is this the case? Shall weston enable it by default then? Alex On Thu, 19 May 2022 at 21:43, Markus Volk <f_l_k@t-online.de> wrote: > > It doesn't need to be in core, but i would call having window decoration a core component > because otherwise things will just not work as expected for weston/gnome-shell. I could also > send that recipe to meta-oe if you prefer or just store it in meta-wayland since its wayland related stuff but > if you aim to support libsdl in a proper way this recipe should be around somewhere i think. > Personally i prefer sway. It has server side decoration and there is no need for libdecor. > > Markus > > Am 19.05.22 um 18:46 schrieb Alexander Kanavin: > > Also, does this need to be in core (as opposed to meta-oe)? Why? > > Alex > > On Thu, 19 May 2022 at 18:43, Luca Ceresoli via lists.openembedded.org > <luca.ceresoli=bootlin.com@lists.openembedded.org> wrote: > > Hi Markus, > > Il giorno Thu, 19 May 2022 08:43:11 +0200 > "Markus Volk" <f_l_k@t-online.de> ha scritto: > > libdecor is a client-side decoration library for Wayland clients. It > is used by libsdl2 for window decoration and is required to provide > decoration for shells that use client-side decoration such as > gnome-shell or weston. > > Signed-off-by: Markus Volk <f_l_k@t-online.de> > > I'm afraid we're having an issue with this patch as well: > > AssertionError: > The following recipes do not have a maintainer assigned to them. Please > add an entry to meta/conf/distro/include/maintainers.inc file. libdecor > (/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb) > > https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/3547/steps/14/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3604/steps/15/logs/stdio > > And also this warning: > > WARNING: Nothing RPROVIDES 'nativesdk-libdecor' (but > virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb > RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for > 'nativesdk-libdecor' NOTE: Runtime target 'nativesdk-libdecor' is > unbuildable, removing... Missing or unbuildable dependency chain was: > ['nativesdk-libdecor'] WARNING: Nothing RPROVIDES > 'nativesdk-libdecor-dev' (but > virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb > RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for > 'nativesdk-libdecor-dev' NOTE: Runtime target 'nativesdk-libdecor-dev' > is unbuildable, removing... Missing or unbuildable dependency chain > was: ['nativesdk-libdecor-dev'] > > https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/5543/steps/12/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/4571/steps/12/logs/stdio > > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#165903): https://lists.openembedded.org/g/openembedded-core/message/165903 > Mute This Topic: https://lists.openembedded.org/mt/91203655/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
To my knowledge libsdl2 is the only consumer of libdecor right now. If you want to be able to run sdl programs in windows instead of just having them pasted to the background you would want to enable it by default. I love libsdl so my answer would be ... of course it should be build with decoration by default for weston. But on the other hand ... its mostly useful for games and fun stuff so it really depends on your goals. Markus > If it is in core, there should be something in core that consumes and > makes use of it, and preferably automated tests for it. Is this the > case? Shall weston enable it by default then? > > Alex > > On Thu, 19 May 2022 at 21:43, Markus Volk <f_l_k@t-online.de> wrote: >> It doesn't need to be in core, but i would call having window decoration a core component >> because otherwise things will just not work as expected for weston/gnome-shell. I could also >> send that recipe to meta-oe if you prefer or just store it in meta-wayland since its wayland related stuff but >> if you aim to support libsdl in a proper way this recipe should be around somewhere i think. >> Personally i prefer sway. It has server side decoration and there is no need for libdecor. >> >> Markus >> >> Am 19.05.22 um 18:46 schrieb Alexander Kanavin: >> >> Also, does this need to be in core (as opposed to meta-oe)? Why? >> >> Alex >> >> On Thu, 19 May 2022 at 18:43, Luca Ceresoli via lists.openembedded.org >> <luca.ceresoli=bootlin.com@lists.openembedded.org> wrote: >> >> Hi Markus, >> >> Il giorno Thu, 19 May 2022 08:43:11 +0200 >> "Markus Volk" <f_l_k@t-online.de> ha scritto: >> >> libdecor is a client-side decoration library for Wayland clients. It >> is used by libsdl2 for window decoration and is required to provide >> decoration for shells that use client-side decoration such as >> gnome-shell or weston. >> >> Signed-off-by: Markus Volk <f_l_k@t-online.de> >> >> I'm afraid we're having an issue with this patch as well: >> >> AssertionError: >> The following recipes do not have a maintainer assigned to them. Please >> add an entry to meta/conf/distro/include/maintainers.inc file. libdecor >> (/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb) >> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/3547/steps/14/logs/stdio >> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3604/steps/15/logs/stdio >> >> And also this warning: >> >> WARNING: Nothing RPROVIDES 'nativesdk-libdecor' (but >> virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb >> RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for >> 'nativesdk-libdecor' NOTE: Runtime target 'nativesdk-libdecor' is >> unbuildable, removing... Missing or unbuildable dependency chain was: >> ['nativesdk-libdecor'] WARNING: Nothing RPROVIDES >> 'nativesdk-libdecor-dev' (but >> virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb >> RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for >> 'nativesdk-libdecor-dev' NOTE: Runtime target 'nativesdk-libdecor-dev' >> is unbuildable, removing... Missing or unbuildable dependency chain >> was: ['nativesdk-libdecor-dev'] >> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/5543/steps/12/logs/stdio >> https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/4571/steps/12/logs/stdio >> >> -- >> Luca Ceresoli, Bootlin >> Embedded Linux and Kernel engineering >> https://bootlin.com >> >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#165910): https://lists.openembedded.org/g/openembedded-core/message/165910 >> Mute This Topic: https://lists.openembedded.org/mt/91203655/3618223 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [f_l_k@t-online.de] >> -=-=-=-=-=-=-=-=-=-=-=- >>
i have started here locally to resolve all dependencies to be able to build pipewire-native. Besides I tried to untie the node when building libpam-native, because otherwise I can't compile openssh-native either. All in all, the changes were more invasive than I had hoped. Quite some recipes needed to be added for native and I'm not sure if anything got broken in the process. In any case, RFC. Test-wise, I ran -c populate_sdk for my full image with about 13500 tasks. I had a problem with nativesdk-cairo and had to disable a runtime test. But that was related to the meson buildsystem. On the bright side, I otherwise had no issues with building nativesdk and the changes also solved some of my problems. nativesdk-libdecor-dev was created just fine here. Since this is all very experimental and even unsure if this should end up in core, editing the maintainer for libdecor still has time. For libusb1 I added a PACKAGECONFIG option and a comment what you want to enable it for. I'll send an updated patchset because it might be interesting for some to experiment with it. I also had to make some changes in meta-openembedded. I send these patches to openembedded-devel Markus Am 19.05.22 um 18:43 schrieb Luca Ceresoli: > And also this warning: > > WARNING: Nothing RPROVIDES 'nativesdk-libdecor' (but > virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb > RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for > 'nativesdk-libdecor' NOTE: Runtime target 'nativesdk-libdecor' is > unbuildable, removing... Missing or unbuildable dependency chain was: > ['nativesdk-libdecor'] WARNING: Nothing RPROVIDES > 'nativesdk-libdecor-dev' (but > virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb > RDEPENDS on or otherwise requires it) No eligible RPROVIDERs exist for > 'nativesdk-libdecor-dev' NOTE: Runtime target 'nativesdk-libdecor-dev' > is unbuildable, removing... Missing or unbuildable dependency chain > was: ['nativesdk-libdecor-dev']
On Fri, 2022-05-20 at 14:46 +0200, Markus Volk wrote: > i have started here locally to resolve all dependencies to be able to > build pipewire-native. Besides I tried to untie the node when building > libpam-native, because otherwise I can't compile openssh-native either. > All in all, the changes were more invasive than I had hoped. Quite some > recipes needed to be added for native and I'm not sure if anything got > broken in the process. In any case, RFC. Test-wise, I ran -c > populate_sdk for my full image with about 13500 tasks. I had a problem > with nativesdk-cairo and had to disable a runtime test. But that was > related to the meson buildsystem. On the bright side, I otherwise had no > issues with building nativesdk and the changes also solved some of my > problems. nativesdk-libdecor-dev was created just fine here. > > Since this is all very experimental and even unsure if this should end > up in core, editing the maintainer for libdecor still has time. For > libusb1 I added a PACKAGECONFIG option and a comment what you want to > enable it for. I'll send an updated patchset because it might be > interesting for some to experiment with it. > > I also had to make some changes in meta-openembedded. I send these > patches to openembedded-devel A number of the things you're adding native versions to worry me a little since they're often functionality from the native system which we've been trying hard not to duplicate. For example, you wouldn't want two udevs running. Worse, it may be eudev but could also be systemd and the native binaries are supposed to run on both systems. Similarly, you wouldn't expect a build to start a local ssh server via openssh. With libpam, we'd want to be sure that the library works in a number of different environments. These issues are probably why you see the native PACKAGECONFIG for libsdl being a bit more minimal to avoid these kinds of dilemmas. I also noticed you renamed gles2 to gles and I'm not sure if that will catch existing users our or not. There are definitely good things in the patch, for example the removal of obsolete config but there are things I'm unsure about (e.g. pipewire, libpam) and things I do think may cause more problems than they solve (openssh-native and eudev-native). Cheers, Richard
Those are valid objections and I wasn't happy with how invasive the necessary changes were either. The reason I'm still working on it is that I'd really like to have an alignment for native/target for libsdl2. As it is, libsdl2-native unconditionally adds x11. From the perspective that we eventually want to reach the point where wayland/x11 becomes an either/or decision, I think that should be changed. I did some cleanup and it is much less invasive now. To align native/target PACKAGECONFIG, only patches 1-3 are needed. 4-5 add pipewire and libdecor and I added them just for completeness. The patches are made for kirkstone because I have too many problems with the poky master branch distracting me at the moment. Markus Am 21.05.22 um 09:48 schrieb richard.purdie@linuxfoundation.org: > On Fri, 2022-05-20 at 14:46 +0200, Markus Volk wrote: > A number of the things you're adding native versions to worry me a > little since they're often functionality from the native system which > we've been trying hard not to duplicate. For example, you wouldn't want > two udevs running. Worse, it may be eudev but could also be systemd and > the native binaries are supposed to run on both systems. Similarly, you > wouldn't expect a build to start a local ssh server via openssh. > > With libpam, we'd want to be sure that the library works in a number of > different environments. > > These issues are probably why you see the native PACKAGECONFIG for > libsdl being a bit more minimal to avoid these kinds of dilemmas. > > I also noticed you renamed gles2 to gles and I'm not sure if that will > catch existing users our or not. > > There are definitely good things in the patch, for example the removal > of obsolete config but there are things I'm unsure about (e.g. > pipewire, libpam) and things I do think may cause more problems than > they solve (openssh-native and eudev-native). > > Cheers, > > Richard > > > > >
On Sun, 2022-05-22 at 10:48 +0200, Markus Volk wrote: > Those are valid objections and I wasn't happy with how invasive the > necessary changes were either. The reason I'm still working on it is > that I'd really like to have an alignment for native/target for libsdl2. > As it is, libsdl2-native unconditionally adds x11. From the perspective > that we eventually want to reach the point where wayland/x11 becomes an > either/or decision, I think that should be changed. The background helps thanks. Keep in mind that: a) users can change the default PACKAGECONFIG, even for the native version only. b) we have a general policy of trying to support most user's configs with the default native configuration. This isn't always possible and libsdl/mesa are particularly tricky as they reach further into the host than almost any other component we have. x11 on the host should be separately controlled to the target x11 since I can imagine developers with it on the desktop but not their target and the other way around too. As such I'm not sure the goal of making them match is compatible with the other things OE-Core tries to do. > I did some cleanup and it is much less invasive now. To align > native/target PACKAGECONFIG, only patches 1-3 are needed. 4-5 add > pipewire and libdecor and I added them just for completeness. We should add the PACKAGECONFIG entries, that is straight forward. What the defaults should be is a different question and trickier. If the config is there, that should be easier for you though. I'm actually personally roughly in favour of adding libdecor, I know others are less inclined. > > The patches are made for kirkstone because I have too many problems with > the poky master branch distracting me at the moment. What kind of issues? :/ I did merge one of your simpler patches to master FWIW but that does mean this series doesn't apply now which makes testing harder. Cheers, Richard
Am 22.05.22 um 11:24 schrieb richard.purdie@linuxfoundation.org:
> What kind of issues? :/
During the build of a systemd-based image, eudev was added. Possibly I
was to blame for this by my own changes ;)
But after updating the master branch yesterday, I also got build aborts
for some python modules. I didn't investigate this further, but switched
to the kirkstone branch.
Markus
On Sun, 2022-05-22 at 12:22 +0200, Markus Volk wrote: > Am 22.05.22 um 11:24 schrieb richard.purdie@linuxfoundation.org: > > > What kind of issues? :/ > During the build of a systemd-based image, eudev was added. Possibly I > was to blame for this by my own changes ;) Fair enough, I'm not aware of any issue like that in master and I'd have hoped we'd have noticed. > > But after updating the master branch yesterday, I also got build aborts > for some python modules. I didn't investigate this further, but switched > to the kirkstone branch. I'd be interested to know what kind of aborts as that shouldn't have happened. I'd be interested to understand what broke as it shouldn't have done and none of our testing has shown it. Cheers, Richard
Am 22.05.22 um 14:12 schrieb Richard Purdie: > > I'd be interested to know what kind of aborts as that shouldn't have > happened. I'd be interested to understand what broke as it shouldn't > have done and none of our testing has shown it. > I'm running short of time today, but will test a clean master build tomorrow. Markus
Am 22.05.22 um 14:12 schrieb richard.purdie@linuxfoundation.org: > I'd be interested to know what kind of aborts as that shouldn't have > happened. I'd be interested to understand what broke as it shouldn't > have done and none of our testing has shown it. > > Cheers, > > Richard > All-clear for the master branch. All of my issues seem to have been homemade. After cleaning tmp and doing a clean rebuild, i didn't have any build issues anymore. Markus
I have made some progress in building an image with DISTRO_FEATURE 'wayland' without X11. So far I had the problem that I had to enable x11 DISTRO_FEATURE to build many packages under wayland. So all recipes additionally pulled x11 support. I allowed the base xlibs to build under wayland and so was able to build my image without x11 DISTRO_FEATURE. Although I use code like thunar and therefore had to add 'x11' PACKAGECONFIG for gtk+3 and libepoxy and build cairo with xlib support, this had a positive effect on my image. Without the loss of features, my build's tasks were reduced from 13186 to 12781 just by using DISTRO_FEATURES:remove = "x11" in local.conf Am 22.05.22 um 11:24 schrieb richard.purdie@linuxfoundation.org: > On Sun, 2022-05-22 at 10:48 +0200, Markus Volk wrote: >> From the perspective >> that we eventually want to reach the point where wayland/x11 becomes an >> either/or decision, I think that should be changed. >
diff --git a/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb b/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb new file mode 100644 index 0000000000..3223d914ad --- /dev/null +++ b/meta/recipes-graphics/libdecor/libdecor_0.1.0.bb @@ -0,0 +1,30 @@ +SUMMARY = "libdecor - A client-side decorations library for Wayland clients" +LICENSE = "MIT" +LIC_FILES_CHKSUM = "file://LICENSE;md5=7ae2be7fb1637141840314b51970a9f7" + +SRC_URI = "git://gitlab.gnome.org/jadahl/libdecor.git;protocol=https;branch=master" + +DEPENDS = " \ + cairo \ + libxkbcommon \ + pango \ + wayland \ + wayland-native \ + wayland-protocols \ +" + +S = "${WORKDIR}/git" +SRCREV = "3ec3fadd59a21835079fbb3046d2bec6c649d6fa" + +PACKAGECONFIG ?= "dbus" + +PACKAGECONFIG[dbus] = "-Ddbus=enabled,-Ddbus=disabled,dbus" +PACKAGECONFIG[demo] = "-Ddemo=true,-Ddemo=false,virtual/libgl" + +inherit meson pkgconfig + +EXTRA_OEMESON += "--buildtype release" + + +BBCLASSEXTEND = "native nativesdk" +
libdecor is a client-side decoration library for Wayland clients. It is used by libsdl2 for window decoration and is required to provide decoration for shells that use client-side decoration such as gnome-shell or weston. Signed-off-by: Markus Volk <f_l_k@t-online.de> --- .../libdecor/libdecor_0.1.0.bb | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 meta/recipes-graphics/libdecor/libdecor_0.1.0.bb