[04:42] <doko> tsimonq2: could you have a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/s/spyder-unittest/20180727_095719_aee99@/log.gz ?
[06:00] <infinity> wxl: Hey, could you apply another round of Democracy(tm) to https://launchpad.net/~techboard/+members ?
[12:19] <Bert_2> Hi, we're updating our webworkers from 16.04 to 18.04 and noticed there's a bit of a problem in 18.04 with libcurl. Both libcurl3 and libcurl4 actually supply .so files for libcurl4 (so that's weird for sure), on top of that some packages depends on the 3 package and others on the 4 package, so that leaves it difficult to keep everything installed (php-curl requires 4, shibboleth requires 3)
[12:19] <Bert_2> So, is that a mistake or what's the idea behind that?
[13:33] <mdeslaur> xnox: ^
[13:34] <mdeslaur> xnox: is the libcurl3 package support to provide libcurl.so.4, in conflict with libcurl4?
[13:35] <mdeslaur> s/support/supposed/
[13:35] <TJ-> bug #1776489
[13:35] <ubottu> bug 1776489 in xmltooling (Ubuntu) "libxmltooling7 depends on libcurl3, which has been replaced by libcurl4 in Bionic" [Undecided,Confirmed] https://launchpad.net/bugs/1776489
[13:38] <juliank> this seems so wrong
[13:40] <Bert_2> juliank: I agree
[13:44] <mdeslaur> oh, looks like libcurl3 has been shipping libcurl.so.4 for a long time
[13:49] <TJ-> there's a note in the changelog about it
[14:06] <xnox> Bert_2, mdeslaur, TJ-, juliank - the plan was to remove libcurl3 completely, and move over to libcurl4 throughout..... however, there is a package that not only depends on curl with openssl 1.0 ABI/API. Thus everything in the archive has moved onto libcurl4 with openssl1.1, but xmltooling....
[14:07] <xnox> the only way to keep xmltooling installable and usable to build documentation/packages was to reintroduce libcurl3 with openssl1.0 that ships libcurl4.so =/
[14:07] <xnox> it is extremely bad and ungly
[14:07] <juliank> xnox: why doesn't it ship a libcurl3 so?
[14:07] <juliank> were there other API breaks?
[14:08] <juliank> or a libcurl-openssl1.so.4
[14:08] <xnox> curl ones no, but things that try to access openssl ctx get confused as that has changed.
[14:09] <xnox> juliank, i can't remember the soname mess and why it had to be libcurl4 now, but things would have been broken or something.
[14:09] <juliank> hmm
[14:09] <juliank> odd
[14:09] <xnox> juliank, i'm confused how shibboleth-sp2  is involved, since as per tracker it was only http://people.canonical.com/~ubuntu-archive/transitions/html/curl4.html xmltooling
[14:09] <xnox> that was the last remaining package that needed libcurl3
[14:10] <xnox> it has libxmltooling7 dep
[14:15] <xnox> juliank, glory detail https://launchpad.net/ubuntu/+source/curl3/7.58.0-2ubuntu2 and https://launchpad.net/ubuntu/+source/xmltooling/1.6.4-1ubuntu2
[14:18] <juliank> xnox: details is a strong word
[14:18] <juliank> :D
[14:19] <juliank> I remembber there was something, but not what
[14:20] <TJ-> I've found a major problem with the vagrant-libvirt package on 18.04 where it defaults to attaching its management network to "eth0" with no way to change that, and yet due to persistent network names, eth0 rarely exists, so vagrant boxes fail to start. I've located the upstream issue report and found that latest code has a patch that helps admins configure it now. Would this need to be pulled in via
[14:20] <TJ-> Debian > 18.10 first, then SRU 18.04, or could we pull directly to 18.04 since it breaks vagrant fundamentally?
[14:20] <TJ-> Upstream issue (see my comments at the very end) is https://github.com/vagrant-libvirt/vagrant-libvirt/issues/609
[14:20] <TJ-> I'm about to open an Ubuntu bug to track this
[14:34] <TJ-> Bug #1784229
[14:34] <ubottu> bug 1784229 in vagrant-libvirt (Ubuntu) "18.04: VM fails to start due to management_network assuming non-existent interface eth0" [Undecided,New] https://launchpad.net/bugs/1784229
[14:35] <xnox> Bert_2, so i see xml-security-c v2.0 out which appears to compile fine against openssl 1.1.... i wonder if recompiling all the new things from source is the answer here... to get all the things working.
[14:37] <Bert_2> xnox: well yeah, we can't really compile shib ourselves on these production machines
[14:37] <xnox> Bert_2, i understand.
[14:38] <Bert_2> I mean, we are students and stuff, but the application we run are of a sort of important to a large amount (10-60k) students
[14:38] <xnox> Bert_2, i wonder if we will be able to provide the upgraded curl4/openssl1.1 stack via backports or srus.
[14:38] <Bert_2> and we are struggling to even get shib to run properly with the workaround in the blogpost
[14:39] <Bert_2> xnox: I personally think SRUS would be appropriate in this case, since shib2 is just plain broken right now and it's a universe package anyway
[14:39] <xnox> Bert_2, i have not read the blogpost. If I were you, I would assume shib is not available on 18.04 yet. And either stick to 16.04, or run shib things from xenial lxd container on bionic host.
[14:39] <xnox> Bert_2, when we did this botch, we were expecting to fix it properly in time for bionic release =/
[14:39] <Bert_2> an LXD container is not an option in this case since php requires curl4
[14:39] <xnox> but clearly that didn't happen.
[14:40] <Bert_2> yeah, clearly :P
[14:40] <Bert_2> but yeah, we sorta assumed things were more tested/safe now that 18.04.1 was around
[14:40] <xnox> Bert_2, i secretely expected that noboby is using this one little niche thing..... how young and wrong was I.
[14:40] <TJ-> Bert_2: could you use a proxy connection from 18.04 into an LXD-16.04 container for this functionality ?
[14:41] <Bert_2> we are looking into reinstalling to 16.04 if we have to, but we really don't want to
=== joachim is now known as Guest22259
[14:41] <Bert_2> TJ-: maybe if we proxy PHP out to something else, but that would also be quite a lot of work for just a few students, and hard to test
[14:42] <Bert_2> and that would leave our FastCGI users confused
[14:42] <Bert_2> since apache would run in the LXD container
[14:46] <Bert_2> Ok, we got it working with the workaround/hack
[14:46] <Bert_2> turns out they've changed the user that runs shibd
[14:46] <Bert_2> therefore shibd can't read the certificate/key pair it needs
[14:47] <Bert_2> and it doesn't log that problem, so we had strace it
[14:47] <Bert_2> that's really not nice...
[14:47] <xnox> charming!
[14:47] <Bert_2> such a change should be in the release notes
[14:47] <Bert_2> love 2 unrelated issues intermixing, makes things extra spicy <3
[14:48] <xnox> Bert_2, reading the blog post, i think we should be able to fix up the libcurl3/libcurl4 mess as an SRU.
[14:49] <Bert_2> xnox: we agree
[14:49] <Bert_2> 3 people have been working on this for several hours here :P
[14:49] <Bert_2> and I think a fix should be easy
[14:50] <Bert_2> any idea who is willing to sponsor/do this, and what the ETA might be (days, weeks, months)?
[15:26] <Bert_2> xnox: I've added a bug on the situation with the user change in shib, since it also results in upgrade issues: https://bugs.launchpad.net/ubuntu/+source/shibboleth-sp2/+bug/1784231
[15:26] <ubottu> Launchpad bug 1784231 in shibboleth-sp2 (Ubuntu) "Unreported change of shibd user" [Undecided,Confirmed]
=== joachim is now known as Guest81566
[18:55] <TJ-> who/which channel is responsible for the cloud-images archives?
[18:56] <Ionic> what's the first version to support the :all multi-arch annotation for dependencies? seems like that's not working for trusty... and maybe even xenial
[19:22] <tsimonq2> doko: ack
[21:14] <Unit193> xnox: Huh, what caused you to update libtorrent-rasterbar?
[21:59] <wxl> infinity: not enough takers on the call for applicants?
[22:38] <doko> Unit193: boost?