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