Create Task
Maniphest T10504

Abi compliance checker flaky/not working
Open, Needs TriagePublic
Actions

Description

It seems to me something broke recently with the ABI checks on build.kde.org. e.g. the checks for the ABI of the libs build and installed as part of Okteta suddenly no longer yield results, despite no related change on Okteta side.

Last with result: https://build.kde.org/job/Extragear/job/okteta/job/kf5-qt5%20SUSEQt5.10/26/ (see also copy of relevant log below in case build.kd.org loses its history).

I also saw that for kwayland ABI check results are flaky, sometimes results, sometimes not. here to start with one with result, the next does not, then again result: https://build.kde.org/job/Extragear/job/okteta/job/kf5-qt5%20SUSEQt5.10/26/

Though at least for okteta that also correlates with the Appstreamercli checks suddenly no longer forwarding the right(?) number to the graph on the overview page, instead it dropped to 0 issues each build since then, despite the same warnings in the run log found.

No idea myself what the cause is, from my distance I suspect some syncing issue in the build.kde.org setup, or perhaps some changes due to different Python packages being used now.

Log of last run with ABI results in the report page:

17:35:43 + python3 -u ci-tooling/helpers/create-abi-dump.py --project okteta --branchGroup kf5-qt5 --platform SUSEQt5.10 --buildLog currentBuildLog.txt --environment production --usingInstall /home/jenkins//install-prefix/
17:35:48 WARNING: can't find ldconfig
17:35:48 Using GCC 8 (x86_64-suse-linux, target: x86_64)
17:35:48 WARNING: May not work properly with GCC 4.8.[0-2], 6.* and higher due to bug #78040 in GCC. Please try other GCC versions with the help of --gcc-path=PATH option or create ABI dumps by ABI Dumper tool instead to avoid using GCC. Test selected GCC version first by -test option.
17:35:55 cc1: warning: command line option ���-std=c++11��� is valid for C++/ObjC++ but not for C
17:35:55 Checking header(s) 0.4.0 ...
17:36:13 Creating library ABI dump ...
17:36:13 Dump path: abi_dumps/KastenCore/0.4.0/ABI.dump
17:36:25 WARNING: can't find ldconfig
17:36:25 Using GCC 8 (x86_64-suse-linux, target: x86_64)
17:36:25 WARNING: May not work properly with GCC 4.8.[0-2], 6.* and higher due to bug #78040 in GCC. Please try other GCC versions with the help of --gcc-path=PATH option or create ABI dumps by ABI Dumper tool instead to avoid using GCC. Test selected GCC version first by -test option.
17:36:30 cc1: warning: command line option ���-std=c++11��� is valid for C++/ObjC++ but not for C
17:36:30 Checking header(s) 0.4.0 ...
17:36:52 Creating library ABI dump ...
17:36:52 Dump path: abi_dumps/KastenGui/0.4.0/ABI.dump
17:37:02 WARNING: can't find ldconfig
17:37:02 Using GCC 8 (x86_64-suse-linux, target: x86_64)
17:37:02 WARNING: May not work properly with GCC 4.8.[0-2], 6.* and higher due to bug #78040 in GCC. Please try other GCC versions with the help of --gcc-path=PATH option or create ABI dumps by ABI Dumper tool instead to avoid using GCC. Test selected GCC version first by -test option.
17:37:09 cc1: warning: command line option ���-std=c++11��� is valid for C++/ObjC++ but not for C
17:37:09 Checking header(s) 0.4.0 ...
17:37:21 Creating library ABI dump ...
17:37:21 Dump path: abi_dumps/KastenControllers/0.4.0/ABI.dump
17:37:31 WARNING: can't find ldconfig
17:37:31 Using GCC 8 (x86_64-suse-linux, target: x86_64)
17:37:31 WARNING: May not work properly with GCC 4.8.[0-2], 6.* and higher due to bug #78040 in GCC. Please try other GCC versions with the help of --gcc-path=PATH option or create ABI dumps by ABI Dumper tool instead to avoid using GCC. Test selected GCC version first by -test option.
17:37:36 cc1: warning: command line option ���-std=c++11��� is valid for C++/ObjC++ but not for C
17:37:36 Checking header(s) 0.10.0 ...
17:37:48 Creating library ABI dump ...
17:37:48 Dump path: abi_dumps/OktetaCore/0.10.0/ABI.dump
17:38:01 WARNING: can't find ldconfig
17:38:01 Using GCC 8 (x86_64-suse-linux, target: x86_64)
17:38:01 WARNING: May not work properly with GCC 4.8.[0-2], 6.* and higher due to bug #78040 in GCC. Please try other GCC versions with the help of --gcc-path=PATH option or create ABI dumps by ABI Dumper tool instead to avoid using GCC. Test selected GCC version first by -test option.
17:38:06 cc1: warning: command line option ���-std=c++11��� is valid for C++/ObjC++ but not for C
17:38:06 Checking header(s) 0.10.0 ...
17:38:21 Creating library ABI dump ...
17:38:21 Dump path: abi_dumps/OktetaGui/0.10.0/ABI.dump
17:38:33 WARNING: can't find ldconfig
17:38:33 Using GCC 8 (x86_64-suse-linux, target: x86_64)
17:38:33 WARNING: May not work properly with GCC 4.8.[0-2], 6.* and higher due to bug #78040 in GCC. Please try other GCC versions with the help of --gcc-path=PATH option or create ABI dumps by ABI Dumper tool instead to avoid using GCC. Test selected GCC version first by -test option.
17:38:37 cc1: warning: command line option ���-std=c++11��� is valid for C++/ObjC++ but not for C
17:38:37 Checking header(s) 0.4.0 ...
17:38:49 Creating library ABI dump ...
17:38:49 Dump path: abi_dumps/OktetaKastenCore/0.4.0/ABI.dump
17:39:01 WARNING: can't find ldconfig
17:39:01 Using GCC 8 (x86_64-suse-linux, target: x86_64)
17:39:01 WARNING: May not work properly with GCC 4.8.[0-2], 6.* and higher due to bug #78040 in GCC. Please try other GCC versions with the help of --gcc-path=PATH option or create ABI dumps by ABI Dumper tool instead to avoid using GCC. Test selected GCC version first by -test option.
17:39:07 cc1: warning: command line option ���-std=c++11��� is valid for C++/ObjC++ but not for C
17:39:07 Checking header(s) 0.4.0 ...
17:39:25 Creating library ABI dump ...
17:39:25 Dump path: abi_dumps/OktetaKastenGui/0.4.0/ABI.dump
17:39:34 WARNING: can't find ldconfig
17:39:34 Using GCC 8 (x86_64-suse-linux, target: x86_64)
17:39:34 WARNING: May not work properly with GCC 4.8.[0-2], 6.* and higher due to bug #78040 in GCC. Please try other GCC versions with the help of --gcc-path=PATH option or create ABI dumps by ABI Dumper tool instead to avoid using GCC. Test selected GCC version first by -test option.
17:39:40 cc1: warning: command line option ���-std=c++11��� is valid for C++/ObjC++ but not for C
17:39:40 Checking header(s) 0.4.0 ...
17:39:52 Creating library ABI dump ...
17:39:52 Dump path: abi_dumps/OktetaKastenControllers/0.4.0/ABI.dump
[Pipeline] archiveArtifacts
17:40:02 Archiving artifacts
[Pipeline] sh
17:40:02 + python3 -u ci-tooling/helpers/check-abi.py --project okteta --branchGroup kf5-qt5 --platform SUSEQt5.10 --environment production
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!
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!
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!
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!
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 = 2 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 = 2 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 = 2 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 = 2 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 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 = 1 in the builds, that should not happen, as SONAMEs should only rise and never go lower!
17:40:11 INFO:root:Do an ABI check for KastenControllers
17:40:11 WARNING:root:No released version was found, just use the oldest commit.
17:40:11 INFO:root:check 98c68dda5dae434e257a6d52ac1bd667859c35bd(old) -> d52f59108495080ede6e3053495748b138f8ae01(new)
17:40:11 DEBUG:root:abi-compliance-checker -report-path compat_reports/KastenControllers_compat_report.html -l KastenControllers --old /srv/archives/production/ABIReference/KastenControllers_98c68dda5dae434e257a6d52ac1bd667859c35bd_SUSEQt5.10.abidump --new /srv/archives/production/ABIReference/KastenControllers_d52f59108495080ede6e3053495748b138f8ae01_SUSEQt5.10.abidump
17:40:11 WARNING:root:abi-compliance-checker exited with 1:
17:40:11 Preparing, please wait ...
17:40:11 Comparing ABIs ...
17:40:11 Comparing APIs ...
17:40:11 Creating compatibility report ...
17:40:11 Binary compatibility: 0%
17:40:11 Source compatibility: 1.5%
17:40:11 Total binary compatibility problems: 277, warnings: 0
17:40:11 Total source compatibility problems: 339, warnings: 0
17:40:11 Report: compat_reports/KastenControllers_compat_report.html
17:40:11 
17:40:11 INFO:root:Do an ABI check for KastenCore
17:40:11 WARNING:root:No released version was found, just use the oldest commit.
17:40:11 INFO:root:check 98c68dda5dae434e257a6d52ac1bd667859c35bd(old) -> d52f59108495080ede6e3053495748b138f8ae01(new)
17:40:11 DEBUG:root:abi-compliance-checker -report-path compat_reports/KastenCore_compat_report.html -l KastenCore --old /srv/archives/production/ABIReference/KastenCore_98c68dda5dae434e257a6d52ac1bd667859c35bd_SUSEQt5.10.abidump --new /srv/archives/production/ABIReference/KastenCore_d52f59108495080ede6e3053495748b138f8ae01_SUSEQt5.10.abidump
17:40:12 WARNING:root:abi-compliance-checker exited with 1:
17:40:12 Preparing, please wait ...
17:40:12 Comparing ABIs ...
17:40:12 Comparing APIs ...
17:40:12 Creating compatibility report ...
17:40:12 Binary compatibility: 93.5%
17:40:12 Source compatibility: 73.9%
17:40:12 Total binary compatibility problems: 27, warnings: 55
17:40:12 Total source compatibility problems: 91, warnings: 31
17:40:12 Report: compat_reports/KastenCore_compat_report.html
17:40:12 
17:40:12 INFO:root:Do an ABI check for KastenGui
17:40:12 WARNING:root:No released version was found, just use the oldest commit.
17:40:12 INFO:root:check 98c68dda5dae434e257a6d52ac1bd667859c35bd(old) -> d52f59108495080ede6e3053495748b138f8ae01(new)
17:40:12 DEBUG:root:abi-compliance-checker -report-path compat_reports/KastenGui_compat_report.html -l KastenGui --old /srv/archives/production/ABIReference/KastenGui_98c68dda5dae434e257a6d52ac1bd667859c35bd_SUSEQt5.10.abidump --new /srv/archives/production/ABIReference/KastenGui_d52f59108495080ede6e3053495748b138f8ae01_SUSEQt5.10.abidump
17:40:13 WARNING:root:abi-compliance-checker exited with 1:
17:40:13 Preparing, please wait ...
17:40:13 Comparing ABIs ...
17:40:13 Comparing APIs ...
17:40:13 Creating compatibility report ...
17:40:13 Binary compatibility: 90.7%
17:40:13 Source compatibility: 73.3%
17:40:13 Total binary compatibility problems: 50, warnings: 54
17:40:13 Total source compatibility problems: 162, warnings: 31
17:40:13 Report: compat_reports/KastenGui_compat_report.html
17:40:13 
17:40:13 INFO:root:Do an ABI check for OktetaCore
17:40:13 WARNING:root:No released version was found, just use the oldest commit.
17:40:13 INFO:root:check c5e844d3ebacb8e4663922f36cb8b9beede3c985(old) -> d52f59108495080ede6e3053495748b138f8ae01(new)
17:40:13 DEBUG:root:abi-compliance-checker -report-path compat_reports/OktetaCore_compat_report.html -l OktetaCore --old /srv/archives/production/ABIReference/OktetaCore_c5e844d3ebacb8e4663922f36cb8b9beede3c985_SUSEQt5.10.abidump --new /srv/archives/production/ABIReference/OktetaCore_d52f59108495080ede6e3053495748b138f8ae01_SUSEQt5.10.abidump
17:40:14 WARNING:root:abi-compliance-checker exited with 1:
17:40:14 Preparing, please wait ...
17:40:14 Comparing ABIs ...
17:40:14 Comparing APIs ...
17:40:14 Creating compatibility report ...
17:40:14 Binary compatibility: 7.2%
17:40:14 Source compatibility: 52.1%
17:40:14 Total binary compatibility problems: 52, warnings: 5
17:40:14 Total source compatibility problems: 86, warnings: 4
17:40:14 Report: compat_reports/OktetaCore_compat_report.html
17:40:14 
17:40:14 INFO:root:Do an ABI check for OktetaGui
17:40:14 WARNING:root:No released version was found, just use the oldest commit.
17:40:14 INFO:root:check c5e844d3ebacb8e4663922f36cb8b9beede3c985(old) -> d52f59108495080ede6e3053495748b138f8ae01(new)
17:40:14 DEBUG:root:abi-compliance-checker -report-path compat_reports/OktetaGui_compat_report.html -l OktetaGui --old /srv/archives/production/ABIReference/OktetaGui_c5e844d3ebacb8e4663922f36cb8b9beede3c985_SUSEQt5.10.abidump --new /srv/archives/production/ABIReference/OktetaGui_d52f59108495080ede6e3053495748b138f8ae01_SUSEQt5.10.abidump
17:40:15 WARNING:root:abi-compliance-checker exited with 1:
17:40:15 Preparing, please wait ...
17:40:15 Comparing ABIs ...
17:40:15 Comparing APIs ...
17:40:15 Creating compatibility report ...
17:40:15 Binary compatibility: 86.4%
17:40:15 Source compatibility: 65.2%
17:40:15 Total binary compatibility problems: 12, warnings: 74
17:40:15 Total source compatibility problems: 81, warnings: 3
17:40:15 Report: compat_reports/OktetaGui_compat_report.html
17:40:15 
17:40:15 INFO:root:Do an ABI check for OktetaKastenControllers
17:40:15 WARNING:root:No released version was found, just use the oldest commit.
17:40:15 INFO:root:check 98c68dda5dae434e257a6d52ac1bd667859c35bd(old) -> d52f59108495080ede6e3053495748b138f8ae01(new)
17:40:15 DEBUG:root:abi-compliance-checker -report-path compat_reports/OktetaKastenControllers_compat_report.html -l OktetaKastenControllers --old /srv/archives/production/ABIReference/OktetaKastenControllers_98c68dda5dae434e257a6d52ac1bd667859c35bd_SUSEQt5.10.abidump --new /srv/archives/production/ABIReference/OktetaKastenControllers_d52f59108495080ede6e3053495748b138f8ae01_SUSEQt5.10.abidump
17:40:16 WARNING:root:abi-compliance-checker exited with 1:
17:40:16 Preparing, please wait ...
17:40:16 Comparing ABIs ...
17:40:16 Comparing APIs ...
17:40:16 Creating compatibility report ...
17:40:16 Binary compatibility: 21.2%
17:40:16 Source compatibility: 19.9%
17:40:16 Total binary compatibility problems: 427, warnings: 0
17:40:16 Total source compatibility problems: 596, warnings: 10
17:40:16 Report: compat_reports/OktetaKastenControllers_compat_report.html
17:40:16 
17:40:16 INFO:root:Do an ABI check for OktetaKastenCore
17:40:16 WARNING:root:No released version was found, just use the oldest commit.
17:40:16 INFO:root:check 98c68dda5dae434e257a6d52ac1bd667859c35bd(old) -> d52f59108495080ede6e3053495748b138f8ae01(new)
17:40:16 DEBUG:root:abi-compliance-checker -report-path compat_reports/OktetaKastenCore_compat_report.html -l OktetaKastenCore --old /srv/archives/production/ABIReference/OktetaKastenCore_98c68dda5dae434e257a6d52ac1bd667859c35bd_SUSEQt5.10.abidump --new /srv/archives/production/ABIReference/OktetaKastenCore_d52f59108495080ede6e3053495748b138f8ae01_SUSEQt5.10.abidump
17:40:17 WARNING:root:abi-compliance-checker exited with 1:
17:40:17 Preparing, please wait ...
17:40:17 Comparing ABIs ...
17:40:17 Comparing APIs ...
17:40:17 Creating compatibility report ...
17:40:17 Binary compatibility: 58%
17:40:17 Source compatibility: 81.6%
17:40:17 Total binary compatibility problems: 8, warnings: 7
17:40:17 Total source compatibility problems: 37, warnings: 7
17:40:17 Report: compat_reports/OktetaKastenCore_compat_report.html
17:40:17 
17:40:17 INFO:root:Do an ABI check for OktetaKastenGui
17:40:17 WARNING:root:No released version was found, just use the oldest commit.
17:40:17 INFO:root:check 98c68dda5dae434e257a6d52ac1bd667859c35bd(old) -> d52f59108495080ede6e3053495748b138f8ae01(new)
17:40:17 DEBUG:root:abi-compliance-checker -report-path compat_reports/OktetaKastenGui_compat_report.html -l OktetaKastenGui --old /srv/archives/production/ABIReference/OktetaKastenGui_98c68dda5dae434e257a6d52ac1bd667859c35bd_SUSEQt5.10.abidump --new /srv/archives/production/ABIReference/OktetaKastenGui_d52f59108495080ede6e3053495748b138f8ae01_SUSEQt5.10.abidump
17:40:18 WARNING:root:abi-compliance-checker exited with 1:
17:40:18 Preparing, please wait ...
17:40:18 Comparing ABIs ...
17:40:18 Comparing APIs ...
17:40:18 Creating compatibility report ...
17:40:18 Binary compatibility: 97.2%
17:40:18 Source compatibility: 89.2%
17:40:18 Total binary compatibility problems: 13, warnings: 17
17:40:18 Total source compatibility problems: 25, warnings: 14
17:40:18 Report: compat_reports/OktetaKastenGui_compat_report.html
17:40:18 
17:40:18 + true
[Pipeline] archiveArtifacts
17:40:18 Archiving artifacts
[Pipeline] archiveArtifacts
17:40:18 Archiving artifacts

Log of builds afterwards:

17:09:51  + python3 -u ci-tooling/helpers/create-abi-dump.py --project okteta --branchGroup kf5-qt5 --platform SUSEQt5.10 --buildLog currentBuildLog.txt --environment production --usingInstall /home/jenkins//install-prefix/
[Pipeline] archiveArtifacts
17:09:54  Archiving artifacts
17:09:54  ‘logs/*/*/log.txt’ doesn’t match anything: even ‘logs’ doesn’t exist
17:09:54  No artifacts found that match the file pattern "logs/*/*/log.txt". Configuration error?
[Pipeline] sh
17:09:55  + python3 -u ci-tooling/helpers/check-abi.py --project okteta --branchGroup kf5-qt5 --platform SUSEQt5.10 --environment production
[Pipeline] archiveArtifacts
17:10:07  Archiving artifacts
17:10:07  ‘compat_reports/*_compat_report.html’ doesn’t match anything: even ‘compat_reports’ doesn’t exist
17:10:07  No artifacts found that match the file pattern "compat_reports/*_compat_report.html". Configuration error?
[Pipeline] archiveArtifacts
17:10:07  Archiving artifacts

Details

Differential Revisions
D19220: create-abi-dump: match new jenkings log format.

Related Objects
Search...

Restricted Application added a subscriber: sysadmin. · View Herald TranscriptFeb 19 2019, 10:28 PM
bcooksley added a subscriber: bcooksley.Feb 20 2019, 4:24 AM

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!
knauss added a comment.Feb 20 2019, 5:15 PM

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?

The other issue with not syncing - I need to enable more debug logs for create-abi-dump to locate the issue.

kossebau added a comment.EditedFeb 20 2019, 5:32 PM
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?

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?

Update: I guess the script gets confused here by me not exporting that very numbering also in the package name, like those of the cmake config files (where the name is e.g. KastenCore as before). Which indeed flaws again the basic idea of co-instability when it comes to developers, but I alowed myself some inconsistency here as I actually want to enforce distributions to pick up the latest version, as the older one has quite some legacy I want to disappear from the scene :;)
Future versions of Kasten though will again have that, once my complete rewrite is done. No-one would have noticed ideally ;)

BTW, do you know more about SONAMES? Over for libappimage a question was thrown about what rules there actually exist, and so far I could not find more info. https://github.com/AppImage/libappimage/pull/72#issuecomment-464742690 and ff. Happy to learn more.

The other issue with not syncing - I need to enable more debug logs for create-abi-dump to locate the issue.

Guess kwayland is the less complex target for that for a start then. Thanks for looking into it, I found this ABI service quite interesting so far, and look forward to have it back.

knauss added a comment.Feb 21 2019, 11:20 AM

@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

with this timestamp prefix, my regex fails to find the needed cmake. Do I need to be able to parse both kinds of build logs?

knauss added a comment.Feb 21 2019, 11:21 AM

same is true for kwayland.

knauss added a comment.Feb 21 2019, 12:26 PM

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?

Well currently I use the CMake name as library name (KastenCore) , that's why I do not catch this rename from (Kasten3Core -> Kasten4Core).
Why does those libs needs to be "easier co-installabale"? Normally the SONAME makes the libraries already co-installable, as on is named libfoo.0 and the other libfoo.1. Many Linux distributions add the SONAME to the package name, so you can easily keep to libraries versions. As the libfoo symbolic link points to libfoo.1 all new compiled packages will use the new ABI.
I'm very interested in your thoughts about the rename of libraries.

Update: I guess the script gets confused here by me not exporting that very numbering also in the package name, like those of the cmake config files (where the name is e.g. KastenCore as before). Which indeed flaws again the basic idea of co-instability when it comes to developers, but I alowed myself some inconsistency here as I actually want to enforce distributions to pick up the latest version, as the older one has quite some legacy I want to disappear from the scene :;)
Future versions of Kasten though will again have that, once my complete rewrite is done. No-one would have noticed ideally ;)

This sounds like a normal ABI bump would be just enough.

BTW, do you know more about SONAMES? Over for libappimage a question was thrown about what rules there actually exist, and so far I could not find more info. https://github.com/AppImage/libappimage/pull/72#issuecomment-464742690 and ff. Happy to learn more.

There are no really rules about SONAME. The next SONAME should be higher than the last one. You can use everything. As most projects are using for SONAME a simple number, the toolset in distributions is the best for this. I would recommend this, too! Many think that the version and SONAME needs to be connected somehow. But normally the ABI interface is not connected to version. If you find any good reasons to break simple number, I'm very interessed in those reasons.

Debian f.ex. adding abiX to an lib that broke its ABI without bumping the SONAME by upstream like here: https://packages.debian.org/unstable/libkf5akonadiprivate5abi2 (The idea is that 5abi2 is lower than 6, so if upstream will bump the SONAME, Debian is detecting this correctly).

kossebau added a comment.EditedFeb 21 2019, 4:01 PM

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

Let me start with giving some context, so you might understand why I did this (or are able to point out where I am thinking bogus :) ):

The main motivation for Okteta is actually the Kasten framework (something still WIP, so never did more PR about, also very long-term, but not yet dead). Doing a hex editor is more the testing dummy for this document-centric framework (as a bytearray is a nice simple primitive data structure to have for a document, and I also need a hex editor sometimes).
Kasten itself should allow to easily construct new application from Kasten components, with special components per document type.
In Qt4/KDE4 times I was doing lots of iterations of the APIs of Kasten. And had components for multiple document formats. And not always spent time to update all of them to new versions of Kasten.
At the same time I also reused the components I had written to create plugns/extensions to other programs, like KDevelop (though only the Okteta plugin for KDevelop ever got published, by being integrated in the KDevelop repo, the rest stayed private so far).
As result though it happened that I had multiple internally Kasten components re-using plugins to other non-Kasten programs using different API versions of the Kasten framework. To allow the plugins to live together in the same process I then had added versioning to the C++ namespaces (e.g. (namespace Okteta2 {}, namespace Kasten3 {}), to avoid symbol clashes. As well as had added versioning to the include dirs and cmake package names, so I could have development files of different Kasten versions clashless next to each other in the same installation prefix. As well as added the ABI versioning to the library base name, so that e.g. the main libFoo.so development lib symink would not clash between co-installed development files.
So there was a suffix with the ABI version to every usage of terms "Kasten" and "Okteta" everywhere.
And yes, I also needed to do this for the non-Kasten-Qt/KF.only Okteta libs oktetacore & oktetagui, as the different Kasten components I did were also making use of those, and their API was changing as well, so the same isolation was needed.
As result there also never have been two ABI version with the same library basenames, as the ABI version was encoded in the basename. By historic accident the cmake logic set the SOVERSION to the ABI version as well, but that was rather meaningless. And actually, from POV of starting by 0 for each new library, if new=first-time-usage-of-basename, a bit wrong, that's why my recent version change commits just set it to 0.

When then the port to Qt5/KF5 happened, I reset the ABI versioning, given Qt4-based versions were no longer interesting to avoid clashes with :) At the same time though I was also unsure about the future, like about the name Kasten and if I have time to work more on this. So I decided for the first Qt5-based version to drop the ABI version from the basenames of the package names, given it would be != the name of any next ABI version as well, and Kasten0Okteta0 looking strange somehow.
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.

Why easy life when one can make it complicated? ;) Well, actually making things this complicated over here has made it non-complicated elsewhere, so for me the trade-off paid out.

When it comes to packaging by distributions, there have been no complains about the library and cmake config file naming so far. And I assume that most also will just have 0.26 be a replacement for 0.25. So my internal versioning for my own sanity seems not to mess things for them.

The next SONAME should be higher than the last one.

Is this an assumption based on heuristics, because it is just naturally to do +1 for each new version?
But isn't all that is really required to have a SONAME id which is unique, so the linker/loader knows what library file to pick? What logic relies on that one version of a library is the follow-up version of the previous one? The ABI is incompatible in any case, so whether it's the one right after or second-next or one-before is an information which is not really helping any system, or?

bcooksley added a comment.Feb 22 2019, 5:24 AM

@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.

kossebau added a comment.Feb 22 2019, 9:53 PM

@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 (plasnned for upcoming week)?

knauss added a comment.Feb 24 2019, 9:41 PM
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)?

The base is selected like this:

  1. get all commits that have the same SONAME.
  2. filter those commits with are they tagged as "vX.Y.Z" or "X.V.Z" (-rc, -alpha, -beta, -a, -b are allowed, too)
  3. if any commits are filtered select the oldest version, otherwise select the oldest commit.

That means if you tag a version, this commit is used as new base (and merge the stable branch to master). Than the correct base should be used.
git tag --merged needs to output the correct version.

Currently it is not decided if "select the oldest version" needs to replaced with the "select the highest version". But therefor we need test data.

knauss added a comment.Feb 25 2019, 12:50 AM
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.

When it comes to packaging by distributions, there have been no complains about the library and cmake config file naming so far. And I assume that most also will just have 0.26 be a replacement for 0.25. So my internal versioning for my own sanity seems not to mess things for them.

I'm not saying you do it wrong, I just mean you didn't had to rename the libraries, as a ABI bump would have been enough. But distributions do not care that much, if you rename the library and reset SONAME or just bump the SONAME. The interface changes, so they try to build everything against the new library.

And keep in mind distributions are used to fixed the mess upstream produces and not everything that was not correct is given back to upstream, as it is already too late to fix it.

As you see from Debian:
https://tracker.debian.org/pkg/okteta

you forgotten to bump ABI for libkasten3okteta1controllers1.

The next SONAME should be higher than the last one.

Is this an assumption based on heuristics, because it is just naturally to do +1 for each new version?
But isn't all that is really required to have a SONAME id which is unique, so the linker/loader knows what library file to pick?

You are right library name+SONAME needs to unique for one ABI, that is the only need.

What logic relies on that one version of a library is the follow-up version of the previous one? The ABI is incompatible in any case, so whether it's the one right after or second-next or one-before is an information which is not really helping any system, or?

With my distribution hat I can say, that this uniqueness is only one part of the story. If a human sees a libFoo.so.0 and libFoo.so.1, they think, okay everything linked against libFoo.so.0 is old and I need to recompile it to use libFoo.so.1. Because this is true for nearly all libraries also script are written with this in mind. On Debian we have scripts, that detect ABI bumps automatically and trigger a so called "transition": That will recompile everything against the new library that is still using the old library and you can track the status of this recompilation. If you start with a libfoo.so.99 and lower it, all scripts out in the wild, will go mad and do not detect it correctly. My recommend is for making the life of distribution more easy: Just bump SONAME, if you have no real good need to do it differently.

kossebau added a comment.EditedFeb 25 2019, 1:05 AM
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.

Yes, I did the number changes rather for my own mental version model. But also assuming that it will not break things for anyone, maybe just look strange to anyone else looking closer at it, otherwise even go unnoticed.

And keep in mind distributions are used to fixed the mess upstream produces and not everything that was not correct is given back to upstream, as it is already too late to fix it.

As you see from Debian:
https://tracker.debian.org/pkg/okteta

you forgotten to bump ABI for libkasten3okteta1controllers1.

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?

BTW, just in case you are active there, "hexadecimal editor for binary files" is wrong, one can use it for every file ;)

What logic relies on that one version of a library is the follow-up version of the previous one? The ABI is incompatible in any case, so whether it's the one right after or second-next or one-before is an information which is not really helping any system, or?

With my distribution hat I can say, that this uniqueness is only one part of the story. If a human sees a libFoo.so.0 and libFoo.so.1, they think, [...]

Yes, I would expect so that people make pattern from what they see over what is written in some specs hidden somwhere :P Those humans...

knauss added a comment.Feb 25 2019, 1:26 AM
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?

you need to look to the .symbols files in the debian directory to the exported symbols:
https://salsa.debian.org/qt-kde-team/extras/okteta/tree/master/debian

But as pino also updated the version information for the interesting file in the same commit, git tells you that the whole file was rewritten and you can't see what parts lead pino to bump the SONAME. So you would neeed to do remove the version form each line and than use diff:

https://salsa.debian.org/qt-kde-team/extras/okteta/commit/e47faba0f0127dd68f2d29d829ad17b7f6952bbd

BTW, just in case you are active there, "hexadecimal editor for binary files" is wrong, one can use it for every file ;)

You are welcome to give a better description it is a gitlab - so you can easily do merge request:
https://salsa.debian.org/qt-kde-team/extras/okteta/blob/master/debian/control

Or you give me a better description and I'll forward it...

With my distribution hat I can say, that this uniqueness is only one part of the story. If a human sees a libFoo.so.0 and libFoo.so.1, they think, [...]

Yes, I would expect so that people make pattern from what they see over what is written in some specs hidden somwhere :P Those humans...

Well my plan is to write a blogpost about all this abi checker stuff...

bcooksley added a comment.May 15 2019, 10:06 AM

Any update on this @knauss?