Hi folks,
this week I had my 2nd +1 duty (Wed+Thu). I looked into some transitions and applied some of my new learnings from the last +1 Maint meeting. I found quite a few packages which just failed to build on Launchpad and I could re-trigger the build to fix them and move some transitions forward. mumps is still building on riscv64 after ~16h but is looking good.
OK - kcm-fcitx5 ppc64el rebuilt (auto-fcitx5) => 100%
OK - xmltooling armhf rebuilt (auto-xmltooling)
OK - shibboleth-sp armhf (auto-xmltooling)
OK - callaudiod ppc64el rebuilt (auto-callaudiod) => 100%
.. - mumps no-change rebuild (auto-scotch) => looking good
Also, I looked into some other build issues from update_excuses and filed one removal bug for "kore".
OK - qmath3d ppc64el rebuilt
OK - kore => removal bug & update-excuse, https://pad.lv/1912484
In between I took one item from the sponsoring queue and reviewed and upload of s390-tools.
OK - s390-tools[-signed] 2.15.1-0ubuntu6
Looking into the autopkgtests I could trigger a few which had environment issues (i.e. "unknown" version) and some others. Only a few of them passed easily.
NO - r-cran-lwgeom/hirsute/s390x vs ['r-cran-sf/0.9-7+dfsg-1', 'r-cran-sp/1:1.4-5-1', 'r-cran-testthat/3.0.1-1', 'rcpp/1.0.6-1', 'proj/7.2.1-1']
NO - pyopencl/hirsute/amd64 vs ['mesa/20.3.3-1']
OK - paperwork/ppc64el vs ['python-dateutil/2.8.1-5']
OK - netplan.io/hirsute/ppc64el vs dnsmasq/2.82-1ubuntu2
NO - tcpslice/armhf vs ['libpcap/1.10.0-2']
NO - dogtag-pki vs ['389-ds-base/1.4.4.9-1build2', 'net-snmp/5.9+dfsg-3ubuntu1']
So I had a closer look into the dogtag-pki failure on s390x. I could easily reproduce the problem inside a s390x LXD container, but wasn't able to isolate the root cause... After quite some investigation I was able to produce a debug trace of the problem, and to me it looks like the issue is actually not inside this package, but rather inside the LDAP server (i.e. 389-ds-base), as the debug log shows an "SEVERE: Unable to modify o=pki-tomcat-CA: netscape.ldap.LDAPException: error result (1); Operations error", i.e. "Internal Server Error" (https://docs.oracle.com/cd/E19957-01/816-5618-10/netscape/ldap/LDAPException.html#OPERATION_ERROR). I do not really understand why the LDAP server would behave differently on s390x than on all the other architectures, but I guess this is for another time...
Debug log: https://paste.ubuntu.com/p/vx9JB6VTjF/
Cheers,
Lukas
this week I had my 2nd +1 duty (Wed+Thu). I looked into some transitions and applied some of my new learnings from the last +1 Maint meeting. I found quite a few packages which just failed to build on Launchpad and I could re-trigger the build to fix them and move some transitions forward. mumps is still building on riscv64 after ~16h but is looking good.
OK - kcm-fcitx5 ppc64el rebuilt (auto-fcitx5) => 100%
OK - xmltooling armhf rebuilt (auto-xmltooling)
OK - shibboleth-sp armhf (auto-xmltooling)
OK - callaudiod ppc64el rebuilt (auto-callaudiod) => 100%
.. - mumps no-change rebuild (auto-scotch) => looking good
Also, I looked into some other build issues from update_excuses and filed one removal bug for "kore".
OK - qmath3d ppc64el rebuilt
OK - kore => removal bug & update-excuse, https://pad.lv/1912484
In between I took one item from the sponsoring queue and reviewed and upload of s390-tools.
OK - s390-tools[-signed] 2.15.1-0ubuntu6
Looking into the autopkgtests I could trigger a few which had environment issues (i.e. "unknown" version) and some others. Only a few of them passed easily.
NO - r-cran-lwgeom/hirsute/s390x vs ['r-cran-sf/0.9-7+dfsg-1', 'r-cran-sp/1:1.4-5-1', 'r-cran-testthat/3.0.1-1', 'rcpp/1.0.6-1', 'proj/7.2.1-1']
NO - pyopencl/hirsute/amd64 vs ['mesa/20.3.3-1']
OK - paperwork/ppc64el vs ['python-dateutil/2.8.1-5']
OK - netplan.io/hirsute/ppc64el vs dnsmasq/2.82-1ubuntu2
NO - tcpslice/armhf vs ['libpcap/1.10.0-2']
NO - dogtag-pki vs ['389-ds-base/1.4.4.9-1build2', 'net-snmp/5.9+dfsg-3ubuntu1']
So I had a closer look into the dogtag-pki failure on s390x. I could easily reproduce the problem inside a s390x LXD container, but wasn't able to isolate the root cause... After quite some investigation I was able to produce a debug trace of the problem, and to me it looks like the issue is actually not inside this package, but rather inside the LDAP server (i.e. 389-ds-base), as the debug log shows an "SEVERE: Unable to modify o=pki-tomcat-CA: netscape.ldap.LDAPException: error result (1); Operations error", i.e. "Internal Server Error" (https://docs.oracle.com/cd/E19957-01/816-5618-10/netscape/ldap/LDAPException.html#OPERATION_ERROR). I do not really understand why the LDAP server would behave differently on s390x than on all the other architectures, but I guess this is for another time...
Debug log: https://paste.ubuntu.com/p/vx9JB6VTjF/
Cheers,
Lukas
