Thanks for sorting that Tobias.

The FreeBSD builders now have the package pulseaudio-qt installed (also libfakekey).

I'll add it later.

Version 1.0.1 is part of Tumbleweed, just zypper in 'cmake(KF5PulseAudioQt)' or pulseaudio-qt-devel.

With regards to FreeBSD, what are your plans there?

@bcooksley thanks for your help

First jobs started - https://build.kde.org/job/Extragear/job/elisa/

Thanks for the information.
I have added a stable branch.
Could you please run the DSL Job Seed job?

The lack of stable builds for Elisa is due to a lack of stable branch definitions in logical-module-structure in the kde-build-metadata repository.
(See the existing Elisa section)

Thanks @bcooksley for your help.

I've asked the folks who look after our FreeBSD machines to install llvm-symbolizer.
In the meantime, the above change should resolve this issue.

So this error only arises on Freebsd, and the tests pass normally on the Suse instance, as well locally on my Arch. I assume it's a platform dependent false positive?
It's a bit unfortunate because the traceback is not symbolized, so it's difficult to understand where this comes from. Would it be possible to install llvm-symbolizer on the image?

I assume you've gone through the steps needed to ensure this is a false positive and not an actual bug which needs to be fixed?

In T10504#177126, @kossebau wrote:

Hm, rather there was an ABI change I had not intended and missed. Not familiar with debian and that web interface, is there a quick way to see what ABI breakage there was?

In T10504#177125, @knauss wrote:

In T10504#176838, @kossebau wrote:

thanks for your detailed reasons of the nameing schema. I'll just strip the relevant parts I wanted to comment on.

And now we are at the point where there actually will be a new version. Worse, there is a rewrite/redesign of Kasten happening for some time, which though got stuck for now, so I escaped to backport a few of the things done to the working version. And given the design gaps between the old and new Kasten design, I have a desire to have the old version of Kasten disappear as soon as possible out of the public, for any chance of someone deciding to pick it up, as low as it is, but it should be better -> 0 % now :) (Update:) Thus not reviving support for co-installation of development files or for co-usage in the same process, by adding ABI version to namespaces & package names.

Ok you don't want co-usage nor co-installation, than I simple ABI bump would be enough. As the complete library rename only makse sense, if you want to provide co-usage. Co-installation is possible, as the ABI differs, the filename differs so the linker links to the correct ABI and distributions package the differnent ABI versions in differnent packages. IMO you would need to rename the basename, if you want to ship the old interface within together with the new version.

In T10504#176838, @kossebau wrote:

In T10504#176977, @kossebau wrote:

@knauss I can report that for Okteta the creation of the ABI reports work again, thanks for fixing :)

One question: is there a way to reset the base against which the ABI check is done? Or how is this supposed to work in general?
Right now I have only changed things in the master branch, where I first bumped the ABI version (or in my case the libname) before I started to do all the changes to the API. I am almost done now, and would then branch off 0.26 branch for an upcoming release with the new API/ABI version of the Okteta libs. So what will I be seeing once I change stable branch in the KDE build-metadata from 0.25 to 0.26 (planned for upcoming week)?

@knauss I can report that for Okteta the creation of the ABI reports work again, thanks for fixing :)

With the exception of D19222 all of those have now been integrated.

Please merge the commits in following order:
D19219
D19220
D19221
D19222
D19218

Build logs from our Docker images can be found at https://build.kde.org/job/Administration/
In this case, the image last changed 26 days ago.

In T3689#175858, @danders wrote:

Afaiu abi-dumper is the new way of creating dumps. From home page:
"This new way is based on the analysis of the debug-info from binary objects. It's more reliable, faster and simple way. "
Any particular reason for not to use abi-dumper? (Just curious)

@knauss: The log format likely changed recently as part of Jenkins updates, you'll need to update to handle the newer (as seen in Okteta) format. Older style formats (like those in the current libkgapi log) won't be produced anymore.

I'm very interested in your thoughts about the rename of libraries.

That commit also changed the name of the lib itself, which carries some ABI version as part of the base name (e.g. Kasten3Core -> Kasten4Core), to allow for easier co-installations. Seems the ABI checker is surprised by that then :) Surely not what your average lib does, but also not really wrong, no?

same is true for kwayland.

@bcooksley: it looks like the consoleText is formated diffently for okteta than f.ex for libkgapi:
https://build.kde.org/job/Extragear/job/okteta/job/kf5-qt5%20SUSEQt5.10/47/consoleText
vs.
https://build.kde.org/job/Applications/job/libkgapi/job/stable-kf5-qt5%20SUSEQt5.10/6/consoleText

I've ported the Groovy logic for this, however will need some time to do testing to make sure everything works correctly (as it will involve porting of the GCC/MSVC/etc warnings parsers as well)

In T10504#176765, @knauss wrote:

Well the SONAME got reseted with f.ex. be89e0003ff99bbcbe0eb220451471d37e6ff964, so far I know you should never ever lower the SONAME. Or was the 3 a mistake before?

Well the SONAME got reseted with f.ex. be89e0003ff99bbcbe0eb220451471d37e6ff964, so far I know you should never ever lower the SONAME. Or was the 3 a mistake before?

It looks like how Jenkins implements this internally has changed - it now has a new section for this.
I suspect the old "deprecated" methods are no longer being run, hence the lack of results.

I'm not as familiar with this as @knauss but at a glance i'd say the following is related:

17:40:11 WARNING:root:We searched for SONAME = 0, but found a newer SONAME = 3 in the builds, that should not happen, as SONAMEs should only rise and never go lower!
17:40:11 WARNING:root:We searched for SONAME = 0, but found a newer SONAME = 3 in the builds, that should not happen, as SONAMEs should only rise and never go lower!
17:40:11 WARNING:root:We searched for SONAME = 0, but found a newer SONAME = 3 in the builds, that should not happen, as SONAMEs should only rise and never go lower!
17:40:11 WARNING:root:We searched for SONAME = 0, but found a newer SONAME = 3 in the builds, that should not happen, as SONAMEs should only rise and never go lower!
17:40:11 WARNING:root:We searched for SONAME = 0, but found a newer SONAME = 3 in the builds, that should not happen, as SONAMEs should only rise and never go lower!
17:40:11 WARNING:root:We searched for SONAME = 0, but found a newer SONAME = 3 in the builds, that should not happen, as SONAMEs should only rise and never go lower!

In T3689#175818, @knauss wrote:

So far I understood abi-dumper is something different - I use abi-complience-checker to create those dumps.

To create a dump by hand this isn't that easy. see sysadmins/ci-tooling/helpers/create-abi-dump.py.

Hmmm. do not know how to proceed with this without the actual libs available.
I have tried building against a new lib and runing with old lib, with no problems.
I was unsuccesful using abi-dumper on the old lib, so cannot check if it gives the same output as for f7f9ca1a7a8bfd550022ca4aafe3bb2985a1bee4 above.
I guess I have to live with this atm and see how things shape up in the furure...

I'm not a expert in abi-complience-checker, so we need to find out together...

I get ABI error on use of QPair and QSet in kdiagram:
https://build.kde.org/job/Calligra/job/kdiagram/job/kf5-qt5%20SUSEQt5.10/8/artifact/compat_reports/KGantt_compat_report.html#Type_Binary_Problems_Medium
Afaics these lines have not been changed since last release.
I have added a public getter to the class, but it does not complain about that, so...
Also it does not complain about similar use in calligra (although not *exactly* the same, calligra uses other datatypes)
Can anybody shed any light on this?

That was fast. Thanks guys

Thanks for sorting that Tobias.
QuaZip was added to our SUSE images this morning.

The CI system breaks everything down into what we call a "platform", which is essentially a set of builders with a certain configuration (OS, Qt version).
These are the "SUSEQt5.10", "SUSEQt5.11", "SUSEQt5.12", "AndroidQt5.11", "FreeBSDQt5.12" and "WindowsQt5.11" names you'll see on jobs on the CI system.

We've had Qt 5.12 packaged and available since the first alpha and started to build KDE software against the second alpha - would it be possible to do it similarly in the KDE CI?
Starting to build also against pre-release Qt would be helpful as currently KDE CI is lagging behind what rolling release distros actually ship and it might help preventing some issues.

Thanks. Most of the preparation for this is now completed - i'm currently waiting on the Docker image to be built.

quazip-0.7.3 is now installed.

You can add the KDE:Qt:5.12 repository in the exact same fashion as before for the openSUSE images. It's been ready for a while.

FreeBSD already has 5.12 on CI

Adding maintainers of our SUSE images and FreeBSD systems.

YEAH so far the abi-compatibility-results.yaml for pim and Frameworks, as far as they got update the last days.
So we are surly hitting the end of this and catching up the loosen tails of all of this. I'll focus currently on other stuff, will look at it and fix stuff in a week or so.

Cool, i've now made that change to remove it.

@bcooksley I think we can remove vgem now from the CI system

Thanks everyone for the help

Many thanks for enabling surfaceless in those packages Fabian - very much appreciated.
I can confirm that has fixed the issue with KWin tests - https://build.kde.org/job/Plasma/job/kwin/job/kf5-qt5%20SUSEQt5.11/

That's true, but if openSUSE run our unit tests it would be found.

Martin and Vlad, could you please file the relevant bug? I'm not familiar enough with Mesa to provide all the information which they may need.

We can't roll back as far as I know. Please file a bug at bugzilla.opensuse.org against Mesa, adding all the relevant information.

Luca and Fabian, what's the best way of getting this rectified? Filing a bug against Mesa at SUSE?

The spec file: https://build.opensuse.org/package/view_file/X11:XOrg/Mesa/Mesa.spec?expand=1 - no surfacless

Some further hint: https://build.opensuse.org/public/build/X11:XOrg/openSUSE_Tumbleweed/x86_64/Mesa/_log shows --with-platforms=x11,drm,wayland while on https://sources.debian.org/src/mesa/18.2.8-2/debian/rules/ and https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa we see additional surfaceless enabled. This explains why the change for sufaceless did not work. Looks like an openSUSE packaging issue to me.

I don't think that removing vgem will help. The next code path is then using default platform and that will certainly fail. What I would like to see is strace of a failing test.

@graesslin Should I remove the VGem device as well? It seems the tests still fail after setting that environment variable.

Please retry.

More results from playing with strace and reading mesa code: @bcooksley please add LIBGL_ALWAYS_SOFTWARE=true to the environment variables for running the test. With that env variable set I got the test to use the kms_swrast device instead of the intel device

I played a little bit with strace to see what is used.

Unfortunately this didn't work - we now have: Failed to create surfaceless platform, trying with vgem device