They work in the CI, which is required to pass. So there is indeed something wrong with your local setup. And I'm afraid bug reports aren't the right place to ask for help with your dev setup.

(In reply to Nate Graham from comment #1)
> They work in the CI, which is required to pass. So there is indeed something
> wrong with your local setup. And I'm afraid bug reports aren't the right
> place to ask for help with your dev setup.

So you don't know what it could be th cause?

Nope, I didn't look at the attachment, because this is a bug tracker, not a place to get dev or configuration assistance. :) I might recommend https://discuss.kde.org/c/development/10 instead.

(In reply to Nate Graham from comment #3)
> Nope, I didn't look at the attachment, because this is a bug tracker, not a
> place to get dev or configuration assistance. :) I might recommend
> https://discuss.kde.org/c/development/10 instead.

Why I shoud ask people who knows progbably nothing about kwin test suite?🤔

Why are you assuming nobody there will be able to help you?

Regardless, you need to do some investigation yourself to read the logs and figure out why your local setup isn't working properly. Again, the tests are working in the CI, which means if they're failing for you, the problem is a local issue on your machine.

(In reply to Nate Graham from comment #5)
> Why are you assuming nobody there will be able to help you?

Are there any people who knows about test kwin test suite?

> Regardless, you need to do some investigation yourself to read the logs and
> figure out why your local setup isn't working properly. Again, the tests are
> working in the CI, which means if they're failing for you, the problem is a
> local issue on your machine.

May I ask where is procedure/description of assembly test suite and how it is executed?

(In reply to kloczek from comment #6)
> (In reply to Nate Graham from comment #5)
> > Why are you assuming nobody there will be able to help you?
> 
> Are there any people who knows about test kwin test suite?
Maybe. I don't know. They certainly aren't going to show up here to help you troubleshoot your dev environment, though.

> > Regardless, you need to do some investigation yourself to read the logs and
> > figure out why your local setup isn't working properly. Again, the tests are
> > working in the CI, which means if they're failing for you, the problem is a
> > local issue on your machine.
> 
> May I ask where is procedure/description of assembly test suite and how it
> is executed?
I don't know, and I doubt such a thing exists. Typically test quites aren't extensively documented. You run them and they pass or fail. If they fail, you investigate the failure.

(In reply to Nate Graham from comment #7)
[..]
> I don't know, and I doubt such a thing exists. Typically test quites aren't
> extensively documented. You run them and they pass or fail. If they fail,
> you investigate the failure.

Looks like you really don;t know to much about testing kwin .. which is a bit odd.
Why did you not wrote about that in first place?

So who knows?

Do you know at least how test suite is executed?

I'm a bug triager, not a KWin developers. I triaged this bug as "not a bug because it's a question about a local development setup". The purpose of bug triaging is to make sure that bug reports are reporting actual bugs, so we don't waste developers' time when they go looking through bug reports by making them wade through things that they can't work on.

I typically run tests with a bash alias:

function ktest {
    REPO=$( basename $( git rev-parse --show-toplevel ) )
    BUILD_DIR=~/kde/build/$REPO
    make --no-print-directory -C $BUILD_DIR test
}

When I'm in the source dir, I run `ktest` and it runs the tests from the build dir without me having to go there manually.

(In reply to Nate Graham from comment #10)
> I'm a bug triager, not a KWin developers. I triaged this bug as "not a bug
> because it's a question about a local development setup".

How do you know that this is not a bug?
Did you never saw test suite failing on one system and be perfectly fine on another one even if they have been assembled using the same binary packages caused by actual bug in tested code?

> The purpose of bug
> triaging is to make sure that bug reports are reporting actual bugs, so we
> don't waste developers' time when they go looking through bug reports by
> making them wade through things that they can't work on.
>
> I typically run tests with a bash alias:
> 
> function ktest {
>     REPO=$( basename $( git rev-parse --show-toplevel ) )
>     BUILD_DIR=~/kde/build/$REPO
>     make --no-print-directory -C $BUILD_DIR test
> }
> 
> When I'm in the source dir, I run `ktest` and it runs the tests from the
> build dir without me having to go there manually.

Is that ststem assembled out of Debian or some rpm based duistrinution?
Can you show me at least list of packages installed in that CI system?