KWin 5.17.3 compile error on zeus and master

[Progdrasil]

I've attaches the error log from the build. It seems as though it cant find the deleteWindowProperty (line 227 from the log). Ive tried finding if a dependency is missing but i've hit a wall with this one.

kwin_build.log

[schnitzeltony]

Strange - it is building fine an all my machines. FYI: You don't need to compare zeus/master: Still keep zeus synced to master so they should behave similar.

Will look into now and come back with a solution hopefully...

[schnitzeltony]

Somehow my build is so clever to understand

static void deleteWindowProperty(Window win, long int atom)

which I would expect

static void deleteWindowProperty(Xcb::Window win, long int atom)

Can you drop kwin's log.do_configure file here - would like to compare it with mine.

[Progdrasil]

Thanks for the info. Here is the file kwin.do_configure.log

[Progdrasil]

Would it be the fact that it was not able to find Xwayland or qml modules? or the build environment variables

[schnitzeltony]

Apart of different paths my conigure-log looks same...

Is it possible for you to create a patch for tests replacing

static void deleteWindowProperty(Window win, long int atom)

by

static void deleteWindowProperty(Xcb::Window win, long int atom)

in kwin-source/effects.cpp

If not I can do but not now...

[Progdrasil]

I created a pull request with the patch file, however, the compilation is still not working. There is an error attibuted to this same function:

kwin-5.17.3/effects.cpp:1951:54: error: use
 of deleted function 'KWin::Xcb::Window::Window(const KWin::Xcb::Window&)'
 1951 |         deleteWindowProperty(window()->window(), atom);

It also seems to be unable to find some tbs files kwin.do_configure.log kwin.do_compile.log

[schnitzeltony]

So the patch you sent won't do the job - it just gives a small piece of new information.

We have to understand what's going on here...

[Progdrasil]

I have setup a Dockerfile in order to have a similar build environment to what I have been using. to use it these are the commands (you need docker installed):

docker build  --build-arg "host_uid=$(id -u)" --build-arg "host_gid=$(id -g)" --tag "kwin:master" .
mkdir $PWD/build
chown -R $USER:$USER $PWD/build
docker run -it -v $PWD/build:/home/yocto/input/build kwin:master

This will source the bitbake environment (you need to accept the STM32 EULA). Once it has been sourced, you are in the bash environement.

This way we can debug in similar environments.

edited for docker tag error

build-environment.tar.gz

[schnitzeltony]

Thanks - that will help to find out what the culprit is. Unfortunately I have some tasks on my list of higher priority (gnome-desktop -> meta-gnome battle / say farewell to python2) so I hope to find time next week (51).

[Progdrasil]

No problem, I'll keep investigating in parallel with my other tasks. I'll let you know if I find anything.

Farewell python2, I will not be missing you.

[schnitzeltony]

docker build running... (had to move patches to patches -sub-folder)

Am newbie at docker so I need to ask:

How can I configure build from within docker to use my source download folder - it would take ages to download sources again?

[schnitzeltony]

docker run -it -v $PWD/build:/home/yocto/input/build plasma-mobile:master

complains

Unable to find image 'plasma-mobile:master' locally Trying to pull repository docker.io/library/plasma-mobile ... Trying to pull repository registry.fedoraproject.org/plasma-mobile ... Trying to pull repository quay.io/plasma-mobile ... Trying to pull repository registry.access.redhat.com/plasma-mobile ... Trying to pull repository registry.centos.org/plasma-mobile ... Trying to pull repository docker.io/library/plasma-mobile ... /usr/bin/docker-current: repository docker.io/plasma-mobile not found: does not exist or no pull access.

[Progdrasil]

you can link it with a docker volume, -v option of docker run. How do you configure the build to use your source directory usually?

Oh my bad I edited the build but not the run, the tag is kwin:master so the run command is:

docker run -it -v $PWD/build:/home/yocto/input/build kwin:master

[Progdrasil]

for the downloads you can do it this way:

docker run -it -v $PWD/build:/home/yocto/input/build -v <path/to/downloads>:/home/yocto/input/build/downloads kwin:master

[schnitzeltony]

On docker run I get

mkdir: cannot create directory ‘/home/yocto/input/build/conf’: Permission denied Error: Cannot write to /home/yocto/input/build, perhaps try sourcing with a writable path? i.e. . oe-init-build-env ~/my-build

[Progdrasil]

what are the permissions on your build directory on the host machine?

If you do not own it, change the ownership.

[schnitzeltony]

I created a path, moved into it and followed your instructions.

[superandy@superandy docker-test]$ ll total 12 drwxrwxr-x. 3 superandy superandy 4096 Dec 16 17:06 build -rw-r--r--. 1 superandy superandy 3735 Dec 16 17:08 Dockerfile drwxrwxr-x. 2 superandy superandy 4096 Dec 16 14:38 patches

[Progdrasil]

Is your user id 1000? if not run the command id -u and modify the dockerfile lines 41 and 42 (lines starting with ARG) to be equal the output of id -u. This should have worked during the build, but maybe not.

if it is 1000, are you running docker with the sudo prefix? if so add yourself to the docker group and log back in.

[schnitzeltony]

I cloned ST layers into my environment and honestly it frightens what I see:

• Last release is thud > 1 year ago => many append don't match. This could be worked around but shows how much they take care.
• They completely mix-up BSP with DISTRO and force you to use their 'DISTRO' which contains frightening things as mesa.bbappend

# Fix for commit: mesa: ship /etc/drirc in mesa-megadriver (SHA1 fbb688ab3eeca1bbfbaaaaffd8c81fd8052bcc68)
# mesa package is reset to null, so need to allow empty package
ALLOW_EMPTY_${PN} = "1"

or

meta-st-openstlinux/recipes-graphics/wayland/wayland-protocols/0001-linux-dmabuf-Add-support-for-YUV-Full-color-range.patch: Customize wayland-protocol in a DISTRO???

It looks to me that they put common ST-specific-knobs into a DISTRO layer. This is completely wrong because users have zero chance to use another DISTRO.

Sorry to say it that hard but it is not my job (meta-qt5-extra is just a hobby) to fix ST's crap. The only chance I see is to ask ST to cleanup their layers and remove ST-hardware specifics from DISTRO layer

[Progdrasil]

Okay, well i guess the culprit is something ST is doing.

Thanks alot for your time in this matter. It is much appreciated. It helps to know this as to not base myself on ST as i continue to delve into yocto.

[schnitzeltony]

And I've looked into the specs of stm32mp1. From what I've seen so far Raspi up to 3+ or imx6: Don't even think about KDE...

Hope this won't ruin your x-mas preparations

[Progdrasil]

Thanks for the recommendation we were looking to save time and not code some interfaces. We'll look into other paths.