[06:18] <cpaelzer> doko: for the bug I'm tracking on float precision I somehow think it might be libquadmath
[06:18] <cpaelzer> which is enabled in gcc-8
[06:18] <cpaelzer> what is the best way to have a normal cosmic with gcc-8 just without libquadmath
[10:54] <xnox> cpaelzer, which arch? cause i thought power has quadmath without needing libquadmath.
[10:57] <cpaelzer> xnox: well it changes
[10:57] <cpaelzer> gcc-8 + libquadmath != the results of before
[10:58] <cpaelzer> even gcc-8 (as in cosmic) and force removing libquadmath makes it work
[10:58] <cpaelzer> xnox: and yes ppc64el
[10:58] <xnox> huh
[10:58] <xnox> interesting
[11:04] <cpaelzer> and old gcc was compiled --disable-quadmath and such - so it was surely off beofre (lib or not)
[11:06] <xnox> cpaelzer, just FYI doko is in Manchester today, at GNU Tools Cauldron aka the gcc/binutils/what-not conference
[11:35] <xnox> slangasek, Laney - is it intentional that https://bugs.launchpad.net/autopkgtest-cloud does not have a bug tracker?
[11:35] <xnox> how can i report bugs against autopkgtest infra? use autopkgtest ubuntu package?
[11:35] <Laney> yes it is, use https://launchpad.net/auto-package-testing
[11:36] <xnox> oh, ok
[11:36] <xnox> thanks!
[11:39] <xnox> Laney, started typing bullshit, went to find data to back my claims, failed to find data that proves my narative, gave up.
[11:39]  * xnox found lots of data to disprove my narative....
[11:40] <Laney> rubber duckism is a valuable tool
[11:41] <xnox> Laney, =))) hm? what does "rubber duckism" means? =)
[11:41] <xnox> you mean like a bug bear?
[11:45] <cjwatson> https://en.wikipedia.org/wiki/Rubber_duck_debugging
[11:45] <Laney> It's not strictly what you did, but seems related.
[11:45] <Laney> :-)
[11:55] <ogra> lol ... the return of clippy ?
[12:00]  * juliank uses penguins
[12:00] <juliank> penguin debugging
[12:10] <msalvatore> doko: We're getting build failures for armhf when uploading a new version of libgit2 to the security-proposed ppa. I'm able to build for armhf locally and sbeattie was able to build it on cady. Do you have a minute to take a look? Build: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/15336959
[13:43] <doko> msalvatore: not before Wednesday
[13:44] <msalvatore> doko: Ok. If you could have a look on Wednesday it would be much appreciated.
[13:52] <doko> LocutusOfBorg: https://launchpad.net/ubuntu/+source/ldc/1:1.11.0-1 are there any llvm switches to target long-double-128?
[14:04] <ginggs> LocutusOfBorg: did you know? https://wiki.ubuntu.com/ProposedMigration#Testing_against_a_PPA - you don't have to experiment in the archive ;-)
[14:10] <LocutusOfBorg> doko, I don't get the question
[14:10] <LocutusOfBorg> please remove ppc64el and that is all :)
[14:10] <LocutusOfBorg> unsupported upstream, also debian requested its removal
[14:10] <LocutusOfBorg> so I can do the necessary rebuilds
[14:11] <LocutusOfBorg> ginggs, somewhat I tested locally, but I don't know why it is good there
[14:12] <LocutusOfBorg> I even asked a friend to help me, and we didn't come to understand what this code does:
[14:12] <LocutusOfBorg> echo "$components" | parallel --gnu --keep-order 'echo -e "\\nRunning {} tests"; SYMFONY_DEPRECATIONS_HELPER=weak phpunit --colors=always --exclude-group network,tty,benchmark,intl-data,functional,composer {} || (echo -e "\\e[41mKO\\e[0m {}" && $(exit 1));' && exit_code=0 || exit_code=$?
[14:12] <LocutusOfBorg> I don't get if the "exit" is quitting from the whole script or not, it seems not on my laptop, but it does against ppa/autopkgtestsuite
[14:50] <LocutusOfBorg> doko, btw, ppc64el has no reverse-deps, because the resulting compiler never worked, even to build a simple test hello world
[14:50] <LocutusOfBorg> so, removing is really the best thing to do
[15:07] <smoser> autopkg test question.
[15:07] <smoser> autopkgtest --output-dir=$out open-iscsi -- qemu /tmp/autopkgtest-$rel-amd64.img
[15:07] <smoser> isn't that supposed to build the binaries? if not... how do i tell it "please build binaries first".
[15:12] <cjwatson> It only builds the binaries if the test specifies build-needed; otherwise it fetches pre-built binaries from the archive.
[15:12] <cjwatson> I think the easiest way to override that is to fetch the source package separately and then pass the .dsc to autopkgtest rather than just the source package name.
[15:20] <bdmurray> didrocks: Could you have a look at bug 1791324 when you get a chance?
[15:23] <didrocks> bdmurray: yeah, I have a theory, but I'll read the code more on Monday to validate it
[15:25] <bdmurray> didrocks: Sounds good, thanks!
[15:25] <didrocks> yw, thanks for pointing me to the automatically filed bug, one less thing to do (I only looked at it on errors.ubuntu.com when receiving the email)
[15:50] <smoser> cjwatson: ok.. thank you. i was building from a git branch. so i guess i'll just have to build a dsc file first.
[15:51] <cjwatson> smoser: You can pass a directory name too
[15:51] <cjwatson> smoser: Lots of options in autopkgtest(1)
[15:51] <cjwatson> smoser: (If you meant for 'open-iscsi' to be a directory name, prefix it with ./ as otherwise it'll be interpreted as a source package name)
[15:52] <smoser> ah! thats it.
[15:56] <smoser> thank you cjwatson .  crazy. these 2 things are completely different:
[15:56] <smoser>  autopkgtest --output-dir=../out.d . -- ....
[15:56] <smoser> and
[15:56] <smoser>   cd ../ && autopkgtest --output-dir=out.d open-iscsi -- ...
[15:56] <smoser> and it just did not occur to me that it woudl be the case.
[16:56] <Saviq> tsimonq2: hey, is it by design that qml-module-qtquick-virtualkeyboard only has the .so for Styles, and not the keyboard itself https://packages.ubuntu.com/bionic/amd64/qml-module-qtquick-virtualkeyboard/filelist ?
[16:57] <Saviq> what should I do to get the kbd to show up, other than setting QT_IM_MODULE?
[16:58] <Saviq> now I'm getting an error that the module isn't installed, and unless it's supposed to be preloaded somehow I can't see it in the package?
[16:59] <Saviq> ah! qtvirtualkeyboard-plugin
[17:01] <tsimonq2> Saviq: Yep :)
[18:43] <xnox> cjwatson, are there any specific reasons why openssh, in default config insists on using two sockets to bind to [::]:22 and 0.0.0.0:22 separately, instead of binding to [::]:22 alone in dual v6/v4 mode? especially on hosts that default to such behaviour (/proc/sys/net/ipv6/bindv6only=0)
[18:44] <xnox> or is this something i should take upstream?
[18:44] <xnox> (maybe just openssh-portable i guess...)
[19:49] <slangasek> stgraber: is https://github.com/lxc/lxd/issues/4862 something you would plan to land on stable lxd series?  since bionic ships with 3.0.x, it would be good to have it at least fixed there before changing the behavior of the cosmic images
[19:58] <cjwatson> xnox: take it upstream, please
[19:58] <cjwatson> (this has been historically complicated; I haven't thought about to what extent it still makes sense)
[20:01] <stgraber> slangasek: It's in 3.0.2
[20:01] <slangasek> stgraber: oh, huzzah
[20:14] <xnox> cjwatson, ack. just thought i might be missing something obvious.
[21:05] <xnox> cjwatson, actually, i think i figured the obvious why.... that's the simple way to support any sshd_config's which may have overlapping things.