[08:51] <tjaalton> slyon: hi, if you have the s390x vm available for debugging 389, please check it's logs, there should be more than in the dogtag pkispawn error dump
[08:55] <slyon> tjaalton: hey! Yes, that's a good point, checking the 389 logs. I need to re-run the LXD autopkgtest with "--shell-fail", to reproduce the logs
[09:17] <tjaalton> slyon: the folks at #389 are eager to find out why it's failing
[09:17] <tjaalton> though they're mostly in the US
[09:18] <slyon> tjaalton: I reproduced the logs.. there are two interesting files. Let me paste them somewhere
[09:18] <tjaalton> okay
[09:20] <slyon> tjaalton: here are all the logs from /var/log/dirsrv: https://paste.ubuntu.com/p/Q7xHNZYvkT/ https://paste.ubuntu.com/p/pjqj8NPzZj/ Are you in touch with the #389 folks?
[09:21] <tjaalton> yes I asked about this yesterday, but they only test with x86 so it's not something they've hit
[09:23] <slyon> Most interesting part from the logs seems to be this "ERR - entry_get_rdn_mods - Fails to split RDN "o=pki-tomcat-CA" into components" Although, I do not know what it means.
[09:23] <tjaalton> they might have an idea
[09:23] <slyon> Cool thanks! Maybe you can forward those logs and they can understand whats going on
[09:23] <tjaalton> we'll see
[09:27] <tjaalton> can you build 389 to test if reverting a commit helps?
[09:36] <slyon> Yes. I guess we can setup a PPA and run the autopkgtest against that to see if it makes a change
[09:38] <slyon> what commit do you have in mind?
[09:41] <tjaalton> the one that added the error message in the log
[09:42] <tjaalton> it's the topmost commit in that particular file, from last summer.. and it would roughly match the time when this started
[10:36] <Laney> oSoMoN: nice one on dh-elpa/gettext, that seems to be the cleanest way to fix it to me
[10:41] <oSoMoN> Laney, credit goes to you for the initial hint, thanks!
[11:37] <slyon> tjaalton: revertig https://github.com/389ds/389-ds-base/commit/2ccd0bed4e seems to work in manual testing! I triggered a full autopkgtest on the infrastructure against a PPA to see if it is working there as well. (https://launchpad.net/~slyon/+archive/ubuntu/testing/+packages)
[11:41] <tjaalton> slyon: cool, I filed a bug upstream and will add this info too
[13:47] <slyon> tjaalton: thanks! can you point me to that bug report? Also, I can confirm the test passes on autopkgtest.u.c with that one commit reverted: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute-slyon-testing/hirsute/s390x/d/dogtag-pki/20210122_114408_9ecb1@/log.gz
[13:48] <tjaalton> slyon:
[13:48] <tjaalton> @tjaalton
[13:48] <udevbot> Error: "tjaalton" is not a valid command.
[13:48] <tjaalton> uh
[13:48] <tjaalton> https://github.com/389ds/389-ds-base/issues/4563
[13:48] <slyon> thx!
[14:20] <Laney> bdmurray: any idea what's up with apport autopkgtests?
[14:21] <ygk_12345> hi all
[14:21] <Laney> not because you deleted apport from the PPA is it? 😏
[14:21] <ygk_12345> can someone tell me how to disable unattended security upgrades  through autoinstall for ubuntu 20.04 ?
[14:24] <ygk_12345> can someone help me with my query please
[14:27] <ygk_12345> how to disable unattended security upgrades  through autoinstall for ubuntu 20.04 ?
[14:29] <doko> bdmurray: please could you have a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/a/apport/20210122_112630_95059@/log.gz
[14:29] <doko> looking at the log, I don't understand which failing issue is responsible for the error
[14:35] <ygk_12345> is anyone here familiar with subiquity installer ?
[14:38] <Laney> ygk_12345: I don't know, you might have more luck in #ubuntu-server
[14:46] <oSoMoN> xnox, would you mind confirming bug #1911236 ?
[14:46] <oSoMoN> (re- your upload that skips that test)
[15:01] <xnox> oSoMoN:  i have no idea what you want? =)
[15:01] <xnox> oSoMoN:  what do you mean "confirming bug"?
[15:01] <oSoMoN> xnox, set the status to confirmed
[15:01] <xnox> and then what?
[15:01] <oSoMoN> then nothing, I just don't like to confirm my own bugs
[15:01] <xnox> oSoMoN:  the test is skipped; we are not going to work on this; so "fix released"?
[15:02] <tdaitx> Laney: I have commented back on bug 1903929, let me know if you need me to check anything else and/or (pointers on) how I can help to sort that out =)
[15:02] <oSoMoN> xnox, in an ideal world we would come back to it later, to at least file an upstream bug
[15:02] <oSoMoN> and skipping a test is hardly fixing it, the problem is real, even if we don't care much about it
[15:03] <oSoMoN> and it's a regression
[15:46] <tjaalton> slyon: still here? check the latest comment on the 389 bug, if you have that logfile
[15:46] <slyon> yes, currently doing meetings. But I think I pasted that logfile earlier. Will dig it out later
[15:49] <tjaalton> oh right
[15:56] <bdmurray> doko: I've found part of the problem.