[04:01] <Lord-Kamina> Is there any way to get access to the config.log of a failed ppa build?
[06:19] <ePierre> Lord-Kamina, yes
[06:19] <Lord-Kamina> How?
[06:19] <ePierre> Lord-Kamina, in your PPA launchpad page, click on "View package details"
[06:19] <ePierre> Lord-Kamina, then click "View all builds"
[06:20] <ePierre> then you can filter to find your build and you should be able to click "see the log"
[06:20] <Lord-Kamina> But that shows the build log.
[06:20] <Lord-Kamina> Not the config.log.
[06:21] <Lord-Kamina> I'm trying to do a backport, and I guess something in the dependencies broke gcc, but I can't figure out what.
[06:21] <Lord-Kamina> I thought it might have been perl 5.24, but on another machine (same OS) I tried gcc4
[06:22] <Lord-Kamina> gcc-4.9 instead of 4.8 with perl 5.24 and it appeared to work.
[06:22] <Lord-Kamina> And I cannot get any more info from launchpad it seems, other than "checking whether the C compiler works... no"
[06:24] <ePierre_> Lord-Kamina, oh sorry... in that case I don't know!
[06:24] <Lord-Kamina> :( thanks anyway.
[08:32] <cjwatson> Lord-Kamina: The only way to do that is for your build to arrange to cat the config.log when it fails.  dh_auto_configure does this automatically, but perhaps you're bypassing or not using it.
[08:33] <cjwatson> Lord-Kamina: But if all else fails, something like ./configure ... || { code=$?; cat config.log; exit $?; } should work
[10:11] <kjackal> Hi! I am facing a problem with building snaps from launchpad (LP) builders. I have a single snap, named microk8s, and I would like to release to edge from the code's master branch and to track 1.10/edge  from the code's  1.10 branch. I first created a snap for the master->edge path, but then when I select the 1.10 code branch and click "Create a new snap package" in the snap "Name: " I have to use the name "microk8s" again and
[10:11] <kjackal> this errors with "There is already a snap package owned by microk8s developers with this name."
[10:12] <kjackal> Am I missing something? Same snap release to different tracks from different branches. Is this possible with LP builders?
[10:15] <cjwatson> The name there is just the name for the object (the snap recipe, if you like) in Launchpad, not the name of the underlying snap.  You must use a different name for the object in Launchpad.
[10:15] <cjwatson> But that doesn't mean the actual snap will end up with a different name.
[10:16] <cjwatson> If you put something different in the Name: field then it should work fine.
[10:16] <cjwatson> microk8s-1.10 or whatever
[10:18] <kjackal> awesome, thanks cjwatson we might want to update step 6 in https://docs.snapcraft.io/build-snaps/ci-integration
[10:19] <cjwatson> Yeah, I'll see about writing something better there.
[10:19] <cjwatson> Though as ever we want to avoid putting too much detail in and being confusing.
[10:19] <cjwatson> (I didn't write that document originally.)
[10:20] <kjackal> so in launchpad.snaps.getByName I should be looking for microk8s-1.10, right?
[10:21] <cjwatson> Yes
[10:21] <kjackal> awesome, thanks
[11:45] <rbasak> Could somebody take a look at https://answers.launchpad.net/launchpad/+question/670853 please? I think Lars is looking to start testing a mysql-8.0 transition soon.
[11:46] <rbasak> ("Please increase repository size in ppa:mysql-ubuntu/mysql-8.0")
[12:05] <moon127> rbasak: I've bumped it the same as 5.7 as suggested
[12:05] <rbasak> moon127: thank you!
[12:27] <Skuggen> Thanks!
[13:26] <cjwatson> kjackal: https://github.com/canonical-docs/snappy-docs/pull/418 FYI
[13:26] <gitlab-bot> canonical-docs issue (Pull request) 418 in snappy-docs "Improve directions for "Name" field of LP snaps" (comments: 0) [Open]
[13:28] <kjackal> cjwatson: +1 , Thank you
[17:55] <Lord-Kamina> cjwatson I was using whatever the original package had (which was a manual configure), I replaced that with dh_auto_configure and I got the output I needed, thanks.
[17:55] <Lord-Kamina> Now I gotta figure out how to fix it.
[17:56] <cjwatson> Good luck
[18:01] <Lord-Kamina> It's not finding gcc. Shouldn't gcc/g++-4.9 work on trusty?
[18:10] <cjwatson> Lord-Kamina: Can you post a link to the build log?
[18:10] <cjwatson> I don't really feel like guessing.
[18:11] <cjwatson> (Also, trusty has GCC 4.8, not 4.9.)
[19:03] <Lord-Kamina> cjwatson, that's apparently not the problem anymore. Either way, you are right, trusty normally has gcc-4.8 but I was under the impression gcc-4.9 was also _easily_ installable.
[19:04] <Lord-Kamina> Currently I'm getting burned on something else. I need aclocal-1.15, was trying to backport automake and am getting this: https://launchpadlibrarian.net/379414545/buildlog_ubuntu-trusty-i386.automake-1.15_1%3A1.15-4ubuntu1ppa-trusty1_BUILDING.txt.gz
[19:56] <Lord-Kamina> Why does launchpad refuse to install texinfo?
[19:59] <nacc> Lord-Kamina: have you tried buildling it locally?
[20:00] <Lord-Kamina> No, I don't have a machine running trusty at hand; but this at least should be pretty straightforward.
[20:01] <Lord-Kamina> However... The following packages have unmet dependencies:
[20:01] <Lord-Kamina>  sbuild-build-depends-automake-1.15-dummy : Depends: texinfo but it is not going to be installed
[20:01] <nacc> Lord-Kamina: ... schroot, lxd, etc.
[20:01] <Lord-Kamina> Literally failing because it doesn't want to install texinfo.
[20:01] <nacc> Lord-Kamina: but you need to find out why
[20:06] <Lord-Kamina> Yeah, but I don't really know how.
[20:10] <nacc> Lord-Kamina: right, that's why i said build it locally :)
[20:44] <Lord-Kamina> Making a trusty vm now. ugh.
[20:46] <nacc> Lord-Kamina: you don't need a VM
[20:47] <nacc> Lord-Kamina: that's overkill for just building a srcpkg, at least
[20:47] <nacc> Lord-Kamina: sbuild with a chroot or lxd is sufficient
[20:55] <Lord-Kamina> nacc, a VM is easier for me because I have little experience with Linux.
[20:55] <Lord-Kamina> I'm a mac user.
[20:56] <nacc> Lord-Kamina: i see
[20:58] <Lord-Kamina> Fairly advanced and more than somewhat familiar with the bsd innards but things as simple as apt can sometimes still be largely black magic to me. :P
[21:04] <nacc> Lord-Kamina: if i had to guess, it's because you're using a ppa for perl?
[21:04] <nacc> Lord-Kamina: one that's not been updated since january of last year...
[21:04] <Lord-Kamina> Could be.
[21:12] <Lord-Kamina> Is there a command to find a package that depends on another package?
[21:12] <nacc> Lord-Kamina: reverse-depends and apt-cache rdepends
[21:13] <Lord-Kamina> Don't know if it's actually related to the issue on the ppa, since this is a fresh install.
[21:13] <Lord-Kamina> But perl was complaining about libenchant having unmet dependencies.
[21:13] <Lord-Kamina> Even though I don't think perl directly depends on enchant.
[23:21] <cjwatson> Lord-Kamina: "is not going to be installed" invariably means that there's something deeper in the stack of dependencies that can't be resolved into a consistent set of packages to install.  Unfortunately apt notoriously doesn't tell you about the details up-front and it usually takes a little digging to figure it out.
[23:21] <cjwatson> chdist(1) is my usual tool for this; looking
[23:25] <cjwatson> Lord-Kamina: Right, that perl PPA provides perl 5.24 itself, but it doesn't provide rebuilt versions of all the libraries that would need to be rebuilt against it in order to actually be able to use it in practice
[23:25] <cjwatson> Lord-Kamina: If you dig deep enough, the actual unmet dependency is:  libxml-libxml-perl : Depends: perlapi-5.18.2
[23:25] <cjwatson> Lord-Kamina: I would recommend dropping that perl-5.24 PPA
[23:26] <cjwatson> Lord-Kamina: You're not going to have a good time trying to use perl 5.24 on trusty without an awful lot more work
[23:26] <cjwatson> Lord-Kamina: If you drop that then automake-1.15's build-dependencies are satisfiable
[23:58] <Lord-Kamina> cjwatson, I see. Thank you very much. I was using that ppa in the first place because something else that I needed to build requires perl 5.20 I think.