[01:55] <RAOF> Argh! Why don't I get any email for Mir build failures?!
[04:45] <Skuggen> ahasenack: Hi! (it's early morning here now)
[06:50] <jibel> xnox, yes we still use autopilot for UI tests of ubiquity
[07:42] <RAOF> xnox: I've uploaded Mir 1.7.0 with all the build-fixes I know about; assuming ppc64el and s390x aren't more than usually hateful that should build everywhere and be migrateable.
[08:22] <doko> xnox: dropping python2 stuff is ok, I probably just needed it for the python removal, which likely isn't necessary anymore
[08:53] <tkamppeter> doko, could you help on a gcc problem with ppc64: bug 1862053?
[09:01] <doko> tkamppeter: could you attach the preprocessed source of that file, including the command line options to build it?
[09:03] <tarzeau> i guess that's still valid? https://www.phoronix.com/scan.php?page=news_item&px=No-Wayland-Default-20.04-LTS
[09:03] <tkamppeter> doko, the command line options to compile it are in the log right before the line telling that the build process got terminated.
[09:03] <doko> but not the preprocessed source
[09:03] <tkamppeter> doko, but how does one obtain a pre-processed source?
[09:06] <doko> tkamppeter: build the file with -save-temps and look for .i or .ii file
[09:07] <tkamppeter> doko, will try.
[09:07] <doko> ta
[09:08] <doko> on ppc64el of course
[09:13] <tkamppeter> doko, could you not do this step also?
[09:24] <doko> tkamppeter: I can try, but not my priority for next week
[09:26] <tkamppeter> doko, OK.
[09:32] <doko> tkamppeter: but everybody has access to ppc64el boxes
[09:40] <LocutusOfBorg> doko, python-importlib-metadata syncd, it doesn't FTBFS anymore
[10:03] <doko> Mario Limonciello here?
[10:06] <Laney> doko: that is superm1, but not often on IRC - email works better ime
[10:11] <doko> yep, sent it
[10:28] <mitya57> xnox: python3-windowmocker uses Qt 4, unfortunately. But at least it's Python 3.
[10:29] <mitya57> If you could remove autopilot's dependency on any window-mocker, that would be ideal of course.
[10:36] <doko> jibel: ^^^
[10:51] <xnox> jibel:  i think ubiquity needs to declare an build-depends on autopilot, such that automated tools don't forget that it is used there!
[10:58] <cpaelzer> I might need soem foreign/mutliarch help - http://paste.ubuntu.com/p/8DYhgMRstF/
[10:58] <cpaelzer> I don't see what would be missing, other tests worked that way but here it just says no without further details
[11:09] <cpaelzer> well - it didn't build i386 binaries - as it isn't in the whitelist I guess https://launchpad.net/ubuntu/+source/strongswan/5.8.2-1ubuntu1
[11:09] <cpaelzer> but then why doe it trigger the i386 test http://autopkgtest.ubuntu.com/packages/s/strongswan/focal/i386
[11:09] <cpaelzer> Hmm, I'll file a badtest but I must admit I seem to miss a piece of the i386-puzzle on this one
[11:12] <xnox> cpaelzer:  we have bugs that things get triggered on i386 when it shouldn't
[11:12] <xnox> vorlon:  has been managing these; after the first time, britney does finally forget about i386 for them.
[11:13] <jibel> xnox, it could but autopilot is not really a build-dep of ubiquity.
[11:15] <cpaelzer> thanks xnox
[11:16] <cpaelzer> I'll file a force-badtest MP and explain why - if the solution is different than the force-badtest that can be done in response to the MP instead of merging it
[11:17] <cpaelzer> but knowing that there were some odd cases makes me feel better
[11:18] <xnox> jibel:  i know, but just to highlight it purely as documentation, even if it's not in fact used.
[11:21] <RikMills> mitya57 jibel: just drop the qt4 plugin of windowmocker? the changelog and file lists say there is a Qt5 one shipped
[11:22] <mitya57> +1. I think we should switch python3-autopilot-tests to python3-windowmocker and then drop the Python 2 and Qt 4 parts of window-mocker.
[11:27] <jibel> xnox, did you upload the changes you did yesterday to the vcs?
[11:29] <jibel> can someone file a bug against autopilot, i'll have a look next week.
[11:29] <Laney> now what's happened to seeded-in-ubuntu
[11:29] <jibel> unless someone want to to it
[11:41] <xnox> jibel:  for which package? =)
[11:42] <xnox> jibel:  the previous autopilot upload into the archive was from me in 2017, and it was on top of last CI-train release from march that year
[11:44] <Laney> ah, we lost tab completion in lp-shell at some point :(
[11:45] <jibel> xnox, for autopilot
[11:53] <xnox> jibel:  should we vendorise autopilot in ubiquity?! =)
[12:01] <ahasenack> rbalint: I wanted to probe your memory of https://git.launchpad.net/~usd-import-team/ubuntu/+source/isc-kea/tree/debian/patches/mysql-8.0
[12:01] <ahasenack> rbalint: sorry
[12:01] <ahasenack> rbasak: I wanted to probe your memory of https://git.launchpad.net/~usd-import-team/ubuntu/+source/isc-kea/tree/debian/patches/mysql-8.0
[12:01] <ahasenack> rbasak: in particular, the "Instead we drop the test" bit of the description, which doesn't seem to be part of the patch
[12:02] <rbasak> Looking
[12:03] <doko> bryce: your spammassassin upload still requires python (unversioned) in the autopkg tests
[12:03] <mitya57> jibel: filed bug 1862344. I tried to fix it myself, but the package FTBFS locally for some reason, so I gave up.
[12:04] <rbasak> ahasenack: I think "the test" was this, or similar: https://gitlab.isc.org/isc-projects/kea/commit/ef559d3c3881dafd527b43ac3fc6e771091d6198#7e2229fde9f8ea99bd48e7fb735236b2ddbd1aec_19_19
[12:04] <rbasak> ahasenack: by "drop the test", I meant we're altering the commit from upstream
[12:05] <ahasenack> rbasak: there is a configure check for my_bool, it finds it, because of our workaround in mysql-8 I believe
[12:05] <ahasenack> but then makes wrong assumptions, thinking it's NOT mysql-8 that it's dealing with
[12:05] <rbasak> That's sort of correct
[12:05] <rbasak> This is a mess :(
[12:05] <ahasenack> rbasak: will we be keeping the workaround for 20.04?
[12:05] <rbasak> MySQL 8 dropped my_bool
[12:05] <rbasak> Favouring bool instead
[12:06] <rbasak> We re-added it because it broke too many reverse deps
[12:06] <ahasenack> but now they will never be fixed
[12:06] <ahasenack> well, "never" is a strong word
[12:07] <rbasak> But upstreams that do version testing, rather than feature testing, are now assuming the wrong thing
[12:07] <ahasenack> and it's perhaps starting to introduce other sorts of problems, like the one I described
[12:07] <rbasak> We were hoping it'd be fixed by upstreams building from not-Ubuntu
[12:07] <rbasak> They all need to be using bools and stop using my_bool
[12:08] <rbasak> IIRC, we still haven't finished sending all the patches upstream yet
[12:08] <rbasak> It needs yet more effort to resolve properly, I agree
[12:08] <rbasak> I'd like to chat about this at our next sprint
[12:10] <rbasak> The other problem with all of this is that C++ has a specialist implementation of std::vector<bool> that uses bitfields
[12:10] <rbasak> And when that is done, you can no longer take an address of an element inside the vector
[12:10] <ahasenack> Skuggen: hi :) That's what my ping from yesterday was about, fyi ^
[12:10] <rbasak> C++ programs that did this with std::vector<my_bool> break when my_bool is typedeffed to a bool
[12:10] <ahasenack> yeah, that's the build error I got
[12:10] <ahasenack> because it detected my_bool
[12:11] <rbasak> Are you sure?
[12:12] <ahasenack> ~50%
[12:12] <ahasenack> this beast takes 30min to build
[12:12] <ahasenack> and fails with parallel building
[12:13] <rbasak> One way around it is to put the my_bool in a single-element struct and change all the code to indirect through it.
[12:13] <ahasenack> damn, I overwrote those logs
[12:13] <rbasak> That's the only real long term fix for the C++ vector of my_bool pattern for results AFAIK
[12:13] <ahasenack> I'm going to tell it to not find my_bool
[12:14] <ahasenack> the code has ifdefs for that already
[12:14] <ahasenack> and uses <char> in that vector thing, if that makes any sense
[12:14] <rbasak> I'm not sure that the behaviour is properly defined to use a char instead
[12:14] <rbasak> But that's what upstream did and it seemed to work
[12:15] <rbasak> What change has caused this to be an issue again?
[12:15] <ahasenack> new upstream version, which ironically has the patch you backported above
[12:15] <rbasak> Ah, I see
[12:15] <rbasak> So you want to apply just my backport as a patch to it
[12:16] <ahasenack> and I was looking for the "disabled test"
[12:16] <ahasenack> your patch is there, just surrounded by ifdefs
[12:16] <ahasenack> which trigger on my_bool being found, because we still define it
[12:16] <rbasak> Yeah
[12:16] <rbasak> So I pulled out the ifdefs
[12:16] <ahasenack> and gcc picks the wrong ifdef result
[12:16] <rbasak> If you apply an equivalent patch to the modification I made, the result should be the same
[12:16] <ddstreet> Laney i'll have seeded-in-ubuntu MP ready shortly, btw
[12:17] <ahasenack> or, I remove the configure test for my_bool so it doesn't find it, and takes the other path
[12:17] <ahasenack> assuming correctly it's mysql8
[12:17] <rbasak> I think that would be more confusing
[12:18] <Laney> ddstreet: ah ok, I just fixed it too
[12:18] <rbasak> Because there are two "mysql8"s
[12:18] <Laney> but you can do it
[12:18] <rbasak> One with the typedef, and one without
[12:18] <Laney> why did it just break, do you know?
[12:18] <rbasak> That's why I did it the other way
[12:18] <Laney> Looks like it came from a quite old commit
[12:18] <ahasenack> you mean the real one, and ubuntu's hack
[12:18] <rbasak> Right
[12:18] <ddstreet> Laney i rewrote most of ubuntutools
[12:18] <Laney> or did that only just get merged?
[12:18] <ahasenack> I'm surprised upstream is ok with us doing that
[12:18] <rbasak> And the presence or absence of my_bool now gives you an inconclusive result
[12:19] <ddstreet> yes just merged for focal
[12:19] <Laney> nod
[12:19] <rbasak> I patched it that way because I figured that in an Ubuntu-specific patch, the answer is known and no configure test is not required
[12:19] <rbasak> So it's clearer in a quilt patch to drop the #if directives in the direction that we know to be correct in our case
[12:20] <rbasak> no configure test is required
[12:20] <ahasenack> don't we still have time to fix this for 20.04?
[12:20] <ahasenack> this was in eoan, right?
[12:21] <ahasenack> cpaelzer: I got a file conflict updating qemu-system-common, on /usr/bin/ivshmem-client, is that known/expected?
[12:21] <rbasak> We could, if we want to take that work on right now
[12:22] <rbasak> It is true that users might get upset at us for the patch during the 20.04 lifetime when they try to build things against our MySQL
[12:22] <ahasenack> rbasak: does debian have that change too?
[12:22] <cpaelzer> ahasenack: yes it is known and the fix alread yuploaded
[12:22] <rbasak> Debian doesn't have 8.0 yet
[12:22] <ahasenack> cpaelzer: ok
[12:23] <ahasenack> rbasak: so they likely won't have that patch
[12:23] <rbasak> Also, Debian builds against MariaDB
[12:23] <ahasenack> ah, right
[12:23] <rbasak> However this all affects configure scripts only
[12:23] <rbasak> Since really an upstream project wanting to support a build against MySQL 8.0 should be avoiding use of the my_bool typedef
[12:23] <cpaelzer> ahasenack: 1862287 if you want to look
[12:23] <rbasak> Our patch makes the decision making process in the configure script a little more complicated
[12:23] <ahasenack> rbasak: we all know checking for versions can be brittle, it's always best to check for features
[12:23] <ahasenack> and my_bool is a "feature"
[12:24] <rbasak> Unfortunately we introduced "my_bool might be a real bool, rather than an int"
[12:24] <rbasak> Which it turns out in C++ breaks std::vector
[12:24] <ahasenack> "do we have my_bool?" "is it mysql8?" "is it ubuntu's mysql8?"
[12:25] <rbasak> However the point of the typedef is that we should be able to change its definition without breaking the API
[12:25] <rbasak> So someone wanting to support all three needs to do "do we have my_bool? If so support it being either an int or a bool. If not, use a bool"
[12:27] <rbasak> Perhaps it would suffice if we (I?) wrote that up somewhere for affected users to find.
[12:27] <ahasenack> I'd prefer if we didn't have to carry that workaround :)
[12:28] <Skuggen> Hm, I wonder where I put the work I did related to this (list of upstreams with bugs reported for it, scripts to do reverse-dep builds in the ppa, etc)
[12:29] <Skuggen> We could do a set of ppa builds with an 8.0 without the patch to see how many still haven't been updated?
[12:31] <rbasak> Sure - that'd be a good first step
[12:34] <ahasenack> and how about adding the typedef just to the affected apps, instead of mysql as a whole?
[12:35] <ahasenack> 1 vs N problem?
[12:35] <ahasenack> at least we would have a known set of affected apps, and could revisit each one everytime it's updated
[12:35] <ahasenack> instead of leaving it in mysql and wondering when it could be dropped
[12:43] <tkamppeter> doko, I am trying to get a ppc64el machine on juju, but it seems to take ages until it is ready.
[12:45] <ahasenack> tkamppeter: canonistack?
[12:45] <tkamppeter> ahasenack, yes
[12:45] <ahasenack> it usually work. I don't use juju for that, though
[12:45] <tkamppeter> ahasenack, how do you access?
[12:45] <ahasenack> tkamppeter: let me give you a one liner
[12:45] <ahasenack> tkamppeter: focal ppc64el?
[12:46] <tkamppeter> ahasenack, where do I have to enter it?
[12:46] <ahasenack> tkamppeter: your shell, after having sourced the credentials file for canonistack
[12:47] <ahasenack> tkamppeter: openstack server create --key-name andreas_canonistack-bos01 --flavor cpu1-ram2-disk20 --image 108d7998-a3a7-44ed-b43d-82c30634f976 focal-ppc64el
[12:47] <ahasenack> that will give you a focal ppc64 instance with 1 core, 2G of ram, 20G of disk, called focal-ppc64el (visible with "nova list" after the launch)
[12:47] <ahasenack> tkamppeter: ah, well, details
[12:47] <ahasenack> the ssh key
[12:47] <ahasenack> (--key-name)
[12:47] <ahasenack> do you know how to create one for openstack?
[12:47] <Laney> dunno, it's taking ages to schedule for me, might actually be a problem there
[12:48] <ahasenack> could be too
[12:51] <Laney> I asked the sysadmins if they could take a look
[12:57] <tkamppeter> ahasenack, no, I do not know how to create that key
[12:57] <ahasenack> doko: hi, I was replacing python 3.7 with 3.8 in a lxd container to rebuild something with py3.8, and then ran autoremove, but it failed like this: https://pastebin.ubuntu.com/p/KGJNsy8xNm/
[12:58] <cjwatson> tkamppeter: https://wiki.canonical.com/InformationInfrastructure/IS/CanoniStack-BOS01#Non-Juju
[12:58] <Laney> TIL about the Juju workflow
[12:59] <cjwatson> (With ahasenack's adjustments for getting a ppc64el instance specifically)
[12:59] <doko> Unlinking and removing bytecode for runtime python3.7
[12:59] <doko> update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/python3.7 for writing: Permission denied
[12:59] <doko> update-binfmts: warning: unable to disable binary format python3.7
[12:59] <doko> update-binfmts: exiting due to previous errors
[13:00] <ahasenack> yep
[13:00] <doko> a warning, and then exiting with an error? maybe ask the update-binfmts maintainer ;p
[13:01] <cjwatson> please file a bug?
[13:01] <cjwatson> I do binfmt-support in my free time
[13:01] <ahasenack> yeah, was just looking what the src package was
[13:04] <cjwatson> It would help if python* updated to use --unimport though
[13:04] <cjwatson> See /usr/share/doc/binfmt-support/README.Debian
[13:04] <cjwatson> That would make it not be a fatal error here
[13:04] <ahasenack> I used ubuntu-bug, waiting for launchpad while it does the refresh every 10s thingy
[13:04] <ahasenack> ok, almost there
[13:06] <ahasenack> cjwatson: doko https://bugs.launchpad.net/ubuntu/+source/binfmt-support/+bug/1862347
[13:06] <ahasenack> thx
[13:06] <cjwatson> thanks
[13:11] <tkamppeter> ahasenack, I succeeded creating this server now, at openstack they are much faster going to the attic, getting an old ppc64el server, undusting it, putting it into a rack, installing focal, and then assigning it to me than at juju.
[13:12] <tkamppeter> ahasenack, now I need somehow to SSH into it.
[13:12] <ahasenack> you didn't create an ssh key before?
[13:14] <tkamppeter> Yes, I created it now with the commands on  https://wiki.canonical.com/InformationInfrastructure/IS/CanoniStack-BOS01#Non-Juju
[13:14] <tkamppeter> Without I was not able to create the server.
[13:14] <tkamppeter> Now I have the server and it is "active".
[13:21] <ahasenack> rbasak: cpaelzer: hah, similar case to ethtool iirc: #1862302
[13:22] <ahasenack> new hwe kernel requires new userland tools
[13:22] <Skuggen> ahasenack: Yeah, we added it to MySQL because there were quite a few reverse-deps that needed it
[13:36] <tkamppeter> ahasenack, I succeeded now, folloeing all the instructions.
[13:36] <ahasenack> nice
[13:37] <tkamppeter> ahasenack, thank you very much.
[13:37] <ahasenack> good luck in your debugging :)
[14:04] <tkamppeter> doko, I succeeded to generate this pre-processed file. It is attached to bug 1862053 now.
[14:05] <tkamppeter> Also the manual initiation of the package build on the ppc64el server hung at the same point and the command line for the pre-processing also, but the hang seems after the pre-processing, as the *.i file looks complete.
[14:50] <ahasenack> rbasak: +1 to add to the whitelist? https://paste.ubuntu.com/p/nwnqwx3ctj/
[14:50] <ahasenack> oh, one more, vmvm
[14:50] <ahasenack> 1s
[14:50] <ahasenack> rbasak: https://paste.ubuntu.com/p/KYcM5ZQwYs/
[14:54] <rbasak> ahasenack: +1
[14:55] <ahasenack> rhx
[14:55] <ahasenack> rbasak: I'll import them manually next, ok?
[14:55] <rbasak> Sure
[14:55] <rbasak> In a screen please
[14:56] <rbasak> (just so others can find it if it errors, etc)
[14:56] <ahasenack> sure
[15:07] <ahasenack> rbasak: ok, all 3 imported
[23:28] <juliank> tjaalton: to reduce the risk of forgetting: 2nd hang fix just pushed by Chris Wilson in https://gitlab.freedesktop.org/drm/intel/issues/1164 -
[23:29] <juliank> Funnily he closed my 1150 as duplicate of 1164, not sure why, but as long as it's getting fixed, I can't complain ...