| === joelkraehemann is now known as joel2001k | ||
| RAOF | Argh! Why don't I get any email for Mir build failures?! | 01:55 |
|---|---|---|
| Skuggen | ahasenack: Hi! (it's early morning here now) | 04:45 |
| === bpsecret- is now known as bpsecret | ||
| jibel | xnox, yes we still use autopilot for UI tests of ubiquity | 06:50 |
| 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. | 07:42 |
| doko | xnox: dropping python2 stuff is ok, I probably just needed it for the python removal, which likely isn't necessary anymore | 08:22 |
| === md_5- is now known as md_5 | ||
| tkamppeter | doko, could you help on a gcc problem with ppc64: bug 1862053? | 08:53 |
| ubottu | bug 1862053 in gcc (Ubuntu) "Compiler gets stuck (or extremely slow) on ppc64el" [High,New] https://launchpad.net/bugs/1862053 | 08:53 |
| doko | tkamppeter: could you attach the preprocessed source of that file, including the command line options to build it? | 09:01 |
| 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:03 |
| doko | tkamppeter: build the file with -save-temps and look for .i or .ii file | 09:06 |
| tkamppeter | doko, will try. | 09:07 |
| doko | ta | 09:07 |
| doko | on ppc64el of course | 09:08 |
| tkamppeter | doko, could you not do this step also? | 09:13 |
| doko | tkamppeter: I can try, but not my priority for next week | 09:24 |
| tkamppeter | doko, OK. | 09:26 |
| doko | tkamppeter: but everybody has access to ppc64el boxes | 09:32 |
| LocutusOfBorg | doko, python-importlib-metadata syncd, it doesn't FTBFS anymore | 09:40 |
| doko | Mario Limonciello here? | 10:03 |
| Laney | doko: that is superm1, but not often on IRC - email works better ime | 10:06 |
| doko | yep, sent it | 10:11 |
| mitya57 | xnox: python3-windowmocker uses Qt 4, unfortunately. But at least it's Python 3. | 10:28 |
| mitya57 | If you could remove autopilot's dependency on any window-mocker, that would be ideal of course. | 10:29 |
| doko | jibel: ^^^ | 10:36 |
| 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:51 |
| 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 | 10:58 |
| 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:09 |
| 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:12 |
| jibel | xnox, it could but autopilot is not really a build-dep of ubiquity. | 11:13 |
| cpaelzer | thanks xnox | 11:15 |
| 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:16 |
| cpaelzer | but knowing that there were some odd cases makes me feel better | 11:17 |
| xnox | jibel: i know, but just to highlight it purely as documentation, even if it's not in fact used. | 11:18 |
| RikMills | mitya57 jibel: just drop the qt4 plugin of windowmocker? the changelog and file lists say there is a Qt5 one shipped | 11:21 |
| 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:22 |
| jibel | xnox, did you upload the changes you did yesterday to the vcs? | 11:27 |
| 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:29 |
| xnox | jibel: for which package? =) | 11:41 |
| 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:42 |
| Laney | ah, we lost tab completion in lp-shell at some point :( | 11:44 |
| jibel | xnox, for autopilot | 11:45 |
| xnox | jibel: should we vendorise autopilot in ubiquity?! =) | 11:53 |
| 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:01 |
| rbasak | Looking | 12:02 |
| 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:03 |
| ubottu | bug 1862344 in autopilot (Ubuntu) "Please switch from python-windowmocker to python3-windowmocker" [Undecided,New] https://launchpad.net/bugs/1862344 | 12:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| rbasak | Are you sure? | 12:11 |
| ahasenack | ~50% | 12:12 |
| ahasenack | this beast takes 30min to build | 12:12 |
| ahasenack | and fails with parallel building | 12:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:27 |
| 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:28 |
| 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:29 |
| rbasak | Sure - that'd be a good first step | 12:31 |
| ahasenack | and how about adding the typedef just to the affected apps, instead of mysql as a whole? | 12:34 |
| 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:35 |
| === Wryhder is now known as Lucas_Gray | ||
| tkamppeter | doko, I am trying to get a ppc64el machine on juju, but it seems to take ages until it is ready. | 12:43 |
| 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:45 |
| tkamppeter | ahasenack, where do I have to enter it? | 12:46 |
| ahasenack | tkamppeter: your shell, after having sourced the credentials file for canonistack | 12:46 |
| 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:47 |
| ahasenack | could be too | 12:48 |
| Laney | I asked the sysadmins if they could take a look | 12:51 |
| 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:57 |
| cjwatson | tkamppeter: https://wiki.canonical.com/InformationInfrastructure/IS/CanoniStack-BOS01#Non-Juju | 12:58 |
| Laney | TIL about the Juju workflow | 12:58 |
| 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 | 12:59 |
| ahasenack | yep | 13:00 |
| doko | a warning, and then exiting with an error? maybe ask the update-binfmts maintainer ;p | 13:00 |
| 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:01 |
| 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:04 |
| ahasenack | cjwatson: doko https://bugs.launchpad.net/ubuntu/+source/binfmt-support/+bug/1862347 | 13:06 |
| ahasenack | thx | 13:06 |
| ubottu | Launchpad bug 1862347 in binfmt-support (Ubuntu) "apparmor error while removing python3.7 in lxd" [Undecided,New] | 13:06 |
| cjwatson | thanks | 13:06 |
| 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:11 |
| tkamppeter | ahasenack, now I need somehow to SSH into it. | 13:12 |
| === ricab is now known as ricab|lunch | ||
| ahasenack | you didn't create an ssh key before? | 13:12 |
| 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:14 |
| ahasenack | rbasak: cpaelzer: hah, similar case to ethtool iirc: #1862302 | 13:21 |
| 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:22 |
| tkamppeter | ahasenack, I succeeded now, folloeing all the instructions. | 13:36 |
| ahasenack | nice | 13:36 |
| tkamppeter | ahasenack, thank you very much. | 13:37 |
| ahasenack | good luck in your debugging :) | 13:37 |
| tkamppeter | doko, I succeeded to generate this pre-processed file. It is attached to bug 1862053 now. | 14:04 |
| ubottu | bug 1862053 in gcc (Ubuntu) "Compiler gets stuck (or extremely slow) on ppc64el" [High,New] https://launchpad.net/bugs/1862053 | 14:04 |
| 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:05 |
| === ricab|lunch is now known as ricab | ||
| 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:50 |
| === ricab is now known as ricab|bbl | ||
| rbasak | ahasenack: +1 | 14:54 |
| 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:55 |
| rbasak | (just so others can find it if it errors, etc) | 14:56 |
| ahasenack | sure | 14:56 |
| ahasenack | rbasak: ok, all 3 imported | 15:07 |
| === ricab|bbl is now known as ricab | ||
| === ginggs_ is now known as ginggs | ||
| 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:28 |
| 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 ... | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!