[01:38] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-97.120~14.04.1] (kernel)
[04:16] <tjaalton> I have a bit of a problem with tomcat8 vs tomcat8.0 and don't know how to best solve it
[04:16] <tjaalton> libtomcatjss-java needs libtomcat8.0-java
[04:17] <tjaalton> but with the current package it doesn't get upgraded, replacing libtomcat8-java with 8.0-java
[04:18] <tjaalton> I guess putting P/C/R: libtomcat8-java would solve it, but then all upgrades would get libtomcat8.0-java, which is not desirable since it's supposed to be temporary to allow dogtag/tomcatjss to work until they've been ported to new tomcat..
[04:33] <tjaalton> hmm, and now dist-upgrade worked without changes.. I'll poke it some more
[04:54] <slangasek> tjaalton: Conflicts/Replaces, without Provides, should be enough to tell apt to prefer the replacing package
[04:56] <tjaalton> slangasek: okay, I had a package which recommended libtomcat8-java and removing that made dist-upgrade work fine
[04:57] <tjaalton> shouldn't have had that installed in the first place. fresh install seems to work fine now at least
[04:57] <slangasek> ok
[06:28] <slangasek> jbicha: what did you want to do about gnome-core on ppc64el? (firefox)
[06:53] <slangasek> sergiusens: I see snapcraft autopkgtests failing in artful, which looks like actual bugs in snapcraft (bundling a subset of glibc libraries in the snaps, which are then incompatible with the new libc.so.6 on the system); do you concur?
[07:28] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-36.40~16.04.1]
[07:29] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-97.120~14.04.1]
[07:29] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-133.182]
[07:31] -queuebot:#ubuntu-release- New binary: glewlwyd [ppc64el] (artful-proposed/universe) [1.1-2ubuntu1] (no packageset)
[07:31] -queuebot:#ubuntu-release- New binary: glewlwyd [s390x] (artful-proposed/universe) [1.1-2ubuntu1] (no packageset)
[07:32] -queuebot:#ubuntu-release- New: accepted glewlwyd [ppc64el] (artful-proposed) [1.1-2ubuntu1]
[07:32] -queuebot:#ubuntu-release- New: accepted glewlwyd [s390x] (artful-proposed) [1.1-2ubuntu1]
[07:33] -queuebot:#ubuntu-release- New binary: glewlwyd [armhf] (artful-proposed/universe) [1.1-2ubuntu1] (no packageset)
[07:39] -queuebot:#ubuntu-release- New: accepted glewlwyd [armhf] (artful-proposed) [1.1-2ubuntu1]
[07:43] -queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (artful-proposed/universe) [17.10.2] (ubuntukylin)
[07:53] -queuebot:#ubuntu-release- New: accepted gnome-getting-started-docs [amd64] (artful-proposed) [3.26.0-0ubuntu1]
[07:53] -queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (artful-proposed) [17.10.2]
[07:53] -queuebot:#ubuntu-release- New: accepted gnome-user-docs [amd64] (artful-proposed) [3.26.0-0ubuntu1]
[07:57] -queuebot:#ubuntu-release- New sync: aether-ant-tasks (artful-proposed/primary) [1.0.1-1]
[07:58] -queuebot:#ubuntu-release- New: accepted aether-ant-tasks [sync] (artful-proposed) [1.0.1-1]
[08:00] <doko> $ apt-cache show linux-tools-4.13.0-11|grep Depends
[08:00] <doko> Depends: libaudit1 (>= 1:2.2.1), libbinutils (>= 2.29), libbinutils (<< 2.30), libc6 (>= 2.14), libdw1 (>= 0.157), libelf1 (>= 0.144), liblzma5 (>= 5.1.1alpha+20120614), libnuma1 (>= 2.0.11), libpci3 (>= 1:3.5.2-1), libslang2 (>= 2.2.4), libudev1 (>= 183), libunwind8, zlib1g (>= 1:1.1.4), linux-tools-common
[08:01] <doko> apw: ^^^ your binutils upper dependency is wrong. whatever relies in linux-tools on that is now broken in the release pocket
[08:01] -queuebot:#ubuntu-release- New binary: aether-ant-tasks [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
[08:04] -queuebot:#ubuntu-release- New: accepted aether-ant-tasks [amd64] (artful-proposed) [1.0.1-1]
[08:28] -queuebot:#ubuntu-release- New binary: python3.7 [s390x] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:31] -queuebot:#ubuntu-release- New binary: python3.7 [ppc64el] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:31] -queuebot:#ubuntu-release- New binary: python3.7 [i386] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:35] -queuebot:#ubuntu-release- New binary: python3.7 [amd64] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:36] <apw> doko, da'fuk ... how on earth did that happen
[08:36] <apw> doko, will look into it and get it sorted out
[08:36] <doko> apw: because you have 2.30 as an upper dependency
[08:37] <apw> doko, those are auto-dependencies, not ones we type
[08:37] <apw> it would have had to be built against the old version somehow
[08:37] <doko> ohh, it's an issue in binutils ;)
[08:38] <doko> but anywa, you should get tigher deps with a rebuild
[08:41] -queuebot:#ubuntu-release- New binary: python3.7 [arm64] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:41] -queuebot:#ubuntu-release- New binary: python3.7 [armhf] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
[08:51] <apw> doko, why are the ones there wrong? given the current version falls in that gap ?
[08:51] <apw> doko, is that not a major version clamp and intended as is ?
[08:52] <doko> no, it's the change of the soname, and that changes often
[08:52] <doko> you can avoid it by statically linking libbfd
[08:52] <doko> read the package description, it's not a stable ABI
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [amd64] (artful-proposed) [3.7.0~a1-1]
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [armhf] (artful-proposed) [3.7.0~a1-1]
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [ppc64el] (artful-proposed) [3.7.0~a1-1]
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [arm64] (artful-proposed) [3.7.0~a1-1]
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [s390x] (artful-proposed) [3.7.0~a1-1]
[08:58] -queuebot:#ubuntu-release- New: accepted python3.7 [i386] (artful-proposed) [3.7.0~a1-1]
[09:01] <apw> doko, ok, anyhow, they are supplied by binutils i believe, so a rebuild is sufficient to sort that out, right ?
[09:01] <apw> i may have a minor update i can justify uploading
[09:01] <doko> yes
[09:08] <Ukikie> 3.7?  Huh.
[09:17] <apw> t'is an alpha i assume, and us not be using it
[09:23] <fossfreedom_> quick question - for universe packages with no specific ubuntu changes - is sync'ing with debian unstable still occurring? Reason for the question - tlp is an older version in artful compared to unstable and I'm wondering why that is.
[09:25] <cjwatson> fossfreedom_: No, that stopped at Debian import freeze.  See https://wiki.ubuntu.com/ArtfulAardvark/ReleaseSchedule
[09:25] <fossfreedom_> ok. thanks.
[09:25] <cjwatson> Syncs can still be done manually by syncpackage if they're appropriate for the freeze state or have an exception
[09:34] <fossfreedom_> cjwatson: thanks - looks like it was uploaded around the time of the  freeze date.  no worries. it will be pulled in for 18.04
[09:51] <cjwatson> Indeed.
[10:15] -queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [150-2git1~ubuntu17.04.1 => 151-1~ubuntu17.04.1] (no packageset)
[10:15] -queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [150-2git1~ubuntu16.04.1 => 151-1~ubuntu16.04.1] (no packageset)
[10:20] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [151-1~ubuntu16.04.1]
[10:21] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [151-1~ubuntu17.04.1]
[11:52] <jbicha> slangasek: I'll just have gnome-core use epiphany-browser on ppc64el since chromium-browser isn't available there either
[11:59] <doko> jbicha, slangasek: I asked pat to schedule a session about firefox/rust/cargo maintenance. I think at least on architectures where we don't support firefox we can build with external dependencies like Debian is doing it. but lets see next week for that
[12:07] <jbicha> doko: it's likely that webkit2gtk 2.20 (March 2018) will have a build-dependency on gcc-6, how are you thinking we'll handle that?
[12:07] <sergiusens> slangasek I am sort of off today, can look at it tomorrow or ask elopio to start today if there is rush
[12:08] <doko> jbicha: is that the deprecated webkit?
[12:08] <jbicha> (since we have been backporting new webkit2gtk releases to 16.04 LTS as security releases)
[12:08] <jbicha> no
[12:08] <jbicha> deprecated webkit doesn't get new releases
[12:08] <doko> and it cannot be built with GCC 7?
[12:09] <jbicha> it can build with gcc-7 but gcc-6 & gcc-7 aren't in xenial currently
[12:10] <doko> well, package a new gcc-mozilla then ... but then do it with gcc-7 because that will be the one in the next lts
[12:12] <jbicha> ok, thanks
[12:46] <ahasenack> slangasek: thanks for moving ubuntu-advantage-tools to main
[12:58] <coreycb> hello release team, can we demote python-zunclient from main to universe? At this point it is just listed as a Build-Depend and Suggests.
[13:18] <jbicha> coreycb: it's already in universe https://launchpad.net/ubuntu/+source/python-zunclient/+publishinghistory
[13:18] <jbicha> https://people.canonical.com/~ubuntu-archive/madison.cgi?package=python-zunclient
[13:19] <coreycb> jbicha: ah, great. i got a proposed-migration warning this morning so maybe it was handled today.
[13:22] -queuebot:#ubuntu-release- Unapproved: python-oslo.middleware (zesty-proposed/main) [3.23.1-0ubuntu1 => 3.23.1-0ubuntu1.1] (openstack, ubuntu-server)
[16:02] <elopio> ping doko . Sergio tells me there are snapcraft issues in artful. Do you have a link?
[16:13] <ogra_> elopio, (from #snappy )
[16:13] <ogra_> oko> snapcraft autopkg test failure: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/s/snapcraft/20170922_010609_57ea7@/log.gz
[16:13] <ogra_> <doko> output: {{{b'/snap/godd/x1/bin/godd: relocation error: /snap/godd/x1/lib/x86_64-linux-gnu/libpthread.so.0: symbol __mmap, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference\n'}}}
[16:13] <ogra_> <doko> but it's built with glibc-2.26 ...
[16:17] <elopio> huh, this is running the snaps, not building them.
[16:22] <nacc> ogra_: interesting that's the error i got with my artful build of classic snap too
[16:23] <nacc> (for a different library)
[16:23] <ogra_> nacc, yeah, see the discussion from #snappy :) i mentioned that ...
[16:24] <nacc> ogra_: ah sorry
[16:24] <ogra_> but unlikely to be actually related i think
[16:24] <ogra_> especially since the above happens during build
[16:25] <nacc> ogra_: isn't the output from running hte pyhooks snap?
[16:26] <nacc> ogra_: or running any snap i this case?
[16:26] <ogra_> might be
[16:26] <nacc> ogra_: i'll read the logs a bit myself and see the backlog in #snappy
[16:26]  * ogra_ actually looks at the log 
[16:27] <ogra_> well, there wasnt much beyond the above and me saying "ah. i ahve seen that but only with classic on artful"
[16:28] <nacc> heh
[16:28] <nacc> ogra_: ok :)
[16:28] <ogra_> the snaps failing in the test are non-classic though
[16:28] <nacc> yep, understood -- tbh, my snap (well, the wrapper snapd ends up calling in my snap) is a lot like a non-classic snap. Except for it's write permissions.
[16:29] <nacc> so I *could* see it being similar, in terms of what library is from where and why
[16:29] <nacc> but again, i don't see how it would work with non-classic snaps either, if built on artful
[16:29] <nacc> i guess i don't konw what's built where :/
[16:30] <nacc> i would assume the snapcraft tests actually build the snap?
[16:30] <ogra_> thats a question for elopio i guess
[16:31] <nacc> yeah, it looks like it builds it (aroudn the middle of the log). I think it has to build it on the host, but it's not clear from the logs
[16:32] <nacc> elopio: --^ ?
[16:34] <elopio> nacc: yes, the test builds and runs snaps.
[16:36] <ogra_> elopio, it builds them on artful using artful deps ?
[16:36] <ogra_> that cant work ...
[16:36] <ogra_> (especially after the libc update)
[16:37] <slangasek> sergiusens: well, I think it's perhaps a "rush" in the sense that it might show that snapcraft, or the core snap, is currently broken on top of artful
[16:37] <ogra_> (since it will run them on top of the xenial core afterwards)
[16:37] <nacc> yeah, this is the same issue my classic snap has
[16:37] <nacc> it feels like this is another argument for "don't build on artful" :)
[16:37] <nacc> if it also affects confined snaps :)
[16:38] <ogra_> slangasek, nah ... that has never really worked (if it did, tha was by sheer luck) and should never have been promoted as "supported"
[16:38] <slangasek> nacc: well, it's at least an argument for "don't put half of glibc in your runtime and the other half in your snap"
[16:39] <ogra_> do never ever build snaps with host dependencies unless you are on xenial ... thats the only meme here
[16:39] <slangasek> but what's unusual is that the snapcraft testsuite errors reference only GLIBC_2.25... which is not the xenial, zesty, or artful version
[16:39] <ogra_> and the reason for snapcraft cleanbuild to exist
[16:39] <ogra_> yes, thats a bit weird indeed
[16:39] <nacc> ogra_: good poinnt, so i think if the snapcraft dep8 tests did cleanbuilds, they might pass
[16:40] <nacc> ogra_: although that would potentially required nested lxd on all archs where it runs
[16:40] <ogra_> yes, for sure
[16:40] <ogra_> since the lib versions match the core version the snaps are executed on
[16:40] <nacc> slangasek: the issue is glibc is blacklisted (at least that's what we think) so none of it is in the snap
[16:40] <ogra_> right
[16:40] <ogra_> the libc version in use comes from the core snap
[16:41] <nacc> slangasek: so building on artful leaves link-time dependencies to be satisfied by core, which is xenial, regardless of where your snap built
[16:41] <slangasek> nacc: libpthreads, libdl are part of glibc; they are showing up as symbol mismatches
[16:41] <nacc> slangasek: hrm
[16:41] <nacc> slangasek: maybe it's not a good ennough blacklist :)
[16:41] <slangasek> so it's possible libc is blacklisted but the other bits are not
[16:41] <nacc> slangasek: yeah, in my case (git-ubuntu) it was libdl that threw the error
[16:41] <slangasek> mind you, not /all/ of the test failures were this - but at least some of them are lolwut why are you splitting glibc
[16:41] <ogra_> https://launchpadlibrarian.net/337868387/core_16-2.27.6+git381.783a1f9_amd64.manifest
[16:41] <ogra_> libc-bin	2.23-0ubuntu9
[16:41] <ogra_> libc6:amd64	2.23-0ubuntu9
[16:41] <ogra_> libc6:i386	2.23-0ubuntu9
[16:41] <ogra_> hmmmmm
[16:41] <ogra_> mmm
[16:41] <ogra_> m
[16:42] <ogra_> slangasek, but we are not splitting it
[16:42] <ogra_> the one shipped in core is mandatory
[16:42] <slangasek> ogra_: have you looked at the errors in the log?
[16:43] <ogra_> and snapcraft has code to prevent the libc package to ever end up inside a snap app package
[16:43] <ogra_> yes
[16:43] <slangasek> there are paths referring to libdl.so and libpthreads inside the snap being tested
[16:43] <ogra_> i see the mention of 2.25
[16:43] <slangasek> which means these libraries have not successfully been blacklisted from exclusion from the application snap
[16:43] <ogra_> ah
[16:43] <ogra_> yeah
[16:44] <ogra_> so thats the issue then (still though ... why do they link against 2.25 ?)
[16:45] <ogra_> hmm
[16:47] <nacc> is the bug i snapcraft (not the link, but the libc blacklist) that snapcraft/internal/libraries._get_system_libs looksl ike this: http://paste.ubuntu.com/25593456/
[16:47] <nacc> that's a hardcoded only libc.so.6
[16:47] <ogra_> well, snapcraft explicitly denies installation of libc6
[16:48] <ogra_> $ dpkg -S /lib/x86_64-linux-gnu/libpthread.so.0
[16:48] <ogra_> libc6:amd64: /lib/x86_64-linux-gnu/libpthread.so.0
[16:48] <ogra_> and also:
[16:48] <ogra_> ls -l /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0
[16:48] <ogra_> lrwxrwxrwx 1 root root 18 Sep 12 08:36 /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0 -> libpthread-2.23.so
[16:48] <ogra_> so there shouldnt be a libpthread.so.0 inside the godd snap
[16:48] <nacc> ogra_: ah ok
[16:49] <ogra_> because of the blacklist
[16:49] <ogra_> and the one from core should be used
[16:49] <ogra_> the question is how did it sneak into the godd snap
[16:50] <nacc> ogra_: where is the blacklist implementation? repo/_base:_fix_symlink ?
[16:50] <nacc> ogra_: i'm not seeing that many references to libc in the source
[16:50] <ogra_> not sure, sergiusens or kyrofa would know
=== alan_g is now known as alan_g_
[16:51] <ogra_> there is a txt file somewhere that snapcraft parses
[16:51] <ogra_> but at the same time it also walks ldd output for the built binaries
[16:51] <ogra_> and i think the txt file (the actual blacklist) applies to deb package names ...
[16:52] <ogra_> not sure if there is any verification against deb contents for the blacklisting
[16:53] <elopio> snapcraft/internal/repo/manifest.txt
[16:54] <ogra_> yeah
[16:54] <ogra_> and that only lists deb names
[16:56] <slangasek> coreycb: strange that you got an email about python-zunclient, that seems to have been in response to me fixing the component on the version in -proposed... taking it /off/ of component-mismatches.  Well, another thing to debug at some point
[16:57] <coreycb> slangasek: interesting, ok
[16:58] <elopio> There's also libraries/16.04
[16:59] <nacc> elopio: libdl.so.2 is listed twice? is that file generated?
[17:00] <ogra_> well
[17:01] <ogra_> that lists 16.04 versions
[17:01] <ogra_> hmm, but the link versions
[17:02] <nacc> i'm very cofused by snapcraft/internal/libraries.py
[17:02] <nacc> if you're building on 17.10
[17:02] <nacc> it wo't find any libs file
[17:02] <elopio> nacc: should be: libraries/generate_lib_list.py
[17:02] <nacc> or does it generate it if it's not there?
[17:03] <nacc> i wonder if that's this bug? no libraries file found, so only libc.so.6 is excluded
[17:03] <elopio> nacc: and yes, that's what I was trying. Making a libraries/17.10, and see what happens on artful.
[17:03] <nacc> elopio: _get_system_libs specifically
[17:03] <nacc> elopio: yep
[17:03] <elopio> but well, I'm very lost on this code too. For this, we need kyrofa or sergiusens.
[17:03] <ogra_> i guess kyrofa actually
[17:03] <ogra_> iirc he wrote that bit and the ldd crawler
[17:06] <ogra_> grep pthread /home/ogra/Devel/branches/snapcraft/libraries/16.04
[17:06] <ogra_> libpthread.so.0
[17:06] <ogra_> libpthread.so.0
[17:06] <ogra_> also interesting that this is listed twice inn a row
[17:06] <nacc> ogra_: yeah lots of dupes in that file
[17:06] <ogra_> seems others actually follow the symlink and list link as well asbinary lib
[17:07] <ogra_> which might be because libpthread-2.23.so actually has a dash in the version ? (wild guess)
[17:08] <ogra_> well, whatever ...  we'll need kyrofa
[17:08] <nacc> so it seems like there might need to be two independent fixes (IMO, not konwing anythign about snapcraft): 1) there should be lib lists for all supported build targets; 2) the fallback for only excluding libc.so.6 itself is too narrow and will almost always (with libc mismatches) lead to issues like this -- it should be all libraries provided by libc
[17:08] <nacc> (the bin pkg)
[17:08] <ogra_> well ... 1) there is only one build target :)
[17:08] <ogra_> thats the whole point
[17:09] <nacc> ogra_: true, so the the artful self-tests need to use cleanbuild as well :)
[17:09] <ogra_> yeah
[17:09] <nacc> *artful snapcraft dep8 tests
[17:10] <ogra_> elopio, do you know if there is a reason behind not using cleanbuild in that test ?
[17:10] <ogra_> (and thus pulling in artful deps that will clash with the core snap anyway)
[17:11] <ogra_> (even beyond this libc issues that will cause probs, but perhaps there is some valid reason to actually build native on artful)
[17:18] <elopio> ogra_: mainly, that we couldn't use lxc until recently. But also, I think one of our goals is to be able to build snaps in any distro and use them in any distro.
[17:19] <elopio> I'm not totally sure about that last one. Now that our container builds story is getting a lot better, I think it could make sense to always build in x.
[17:19] <sergiusens> there are two things at play here, the package blacklist and then there's the thing i have been wanting to get rid of for ages but brings in some breakage, there's library collecting from the host so you don't need to bring in the equivalent stage-packages entry for everything that would be satisfied by a build-packages entry
[17:20] <ogra_> ellwell, the last one will definitely not work until we have base snaps for all possible releases and distro combos
[17:20] <ogra_> elopio, ^^
[17:20] <ogra_> sergiusens, well, even if your blacklist works using artful libs inside of snaps that run on top of a xenial core screams for breakage
[17:21] <ogra_> sergiusens, that can work once there are base snaps and an artful-base exists .. but not before
[17:21] <ogra_> the test should just use cleanbuild if possible
[17:21] <elopio> with libraries/17.10, godd works built and run in artful.
[17:21] <ogra_> matter of luck :)
[17:22] <nacc> yeah, it seems like you're just not hitting some ABI change, right?
[17:22] <ogra_> (though its is go ... that will behave better anyway ... if your snap includes actual libs via stage-packages that can quickly fall apart)
[17:22] <nacc> but it's possible to get an ABI change in any of this that might break an app?
[17:22] <sergiusens> ogra_ the only requirement we were given for anything other than xenial (and in future, not built using a proper base) is that people should be allowed to experiment
[17:22] <elopio> ogra_: I wasn't saying it was a good solution, just reporting on my experiment :)
[17:22] <ogra_> sergiusens, sure ... and keep the pieces
[17:23] <nacc> elopio: if nothing else, that fix allows people to continue to usupported experiment
[17:23] <ogra_> sergiusens, but surely nothing you should use in an official test
[17:24] <ogra_> anyway, myth solved \o/
[17:24] <nacc> the implication is, also, though that there is a missing unit or integration test for this, right?
[17:24] <sergiusens> ogra_ the tests were fine as they allowed us to know where we standed, now I need to sit down and think
[17:24] <sergiusens> nacc what is missing?
[17:24] <ogra_> heh, thats another way to put it indeed :)
[17:24] <nacc> sergiusens: a snap was allowed to build using components of libc from a distribution and nnot the core snap
[17:25] <nacc> sergiusens: and ship said components in their sap
[17:25] <nacc> *snap (my n key is struggling!)
[17:25] <sergiusens> nacc oh, that is what we were told to allow and not worry about
[17:25] <ogra_> lol
[17:25] <nacc> who in the world said that?
[17:25] <nacc> it can't work...
[17:25] <ogra_> well
[17:25] <sergiusens> nacc I'd rather not mention ;-)
[17:25] <nacc> ok, it *might* work in some cases :)
[17:25] <ogra_> it would work if you included *all* of libc
[17:25] <nacc> yeah
[17:25] <nacc> you can't include part of it, that's the point slangasek was making
[17:25] <ogra_> the issue here is that only pieces of the libc package were included
[17:26] <ogra_> i.e. not libc itself
[17:26] <nacc> ogra_: yep
[17:26] <ogra_> but libpthread
[17:26] <ogra_> and libdl
[17:26] <nacc> well everythingn but libc.so.6 :)
[17:26] <ogra_> right
[17:26] <nacc> elopio:
[17:26] <nacc> elopio'
[17:26] <sergiusens> ogra_ ah, ic; that can be fixed
[17:26] <nacc> bah! that filelist fix will fix that, at least
[17:27] <sergiusens> nacc I would rather just not auto include anything :-)
[17:27] <ogra_> sergiusens, nut that wont help with other libs that are linked against a newer libc ... which will fall apart equally
[17:27] <sergiusens> this is a perfect excuse for that
[17:27] <ogra_> s/nut/but/
[17:27] <nacc> sergiusens: what do you mean by auto include?
[17:27] <ogra_> (unless the actual libc they link against gets included fully in the snap indeed)
[17:27] <sergiusens> and just raise en error with missing libraries that people will figure out with stage-packages or not
[17:30] <sergiusens> nacc say you say `build-packages: [licurl-dev]`, this would install -dev and libcurl on the host; if you noticed, you don't need to add a `stage-packages: [libcurl]` entry because we crawl the host for libraries to make things easier; I have disliked this feature since forever and given the no break policy we just left it there and added an entry t
[17:30] <sergiusens> o not do this. It seems it would be beneficial for everyone that this not be done automatically at all and raise an error with the missing libraries you have. Anyhow, this is getting snapcraft specific, not sure if worth discussing on #ubuntu-release anymore
[17:31] <nacc> sergiusens: +1 on being as explicit as possible
[17:35] <nacc> ogra_: but this still does't explain the wrong GLIBC version in the logs, right?
[18:19] <doko> slangasek: the reason that you see GLIBC_2.25 is that this is the symbol version. glibc 2.26 didn't have any new symbols compared to glibc-2.25.
[18:19] <nacc> doko: ah that makes sense
[18:20] <nacc> doko: so it is the 2.26 version of the other libs showing that
[18:20] <nacc> doko: thanks!
[18:20] <slangasek> doko: aha, check
[18:21] <doko> what *might* happen is that you see https://sourceware.org/bugzilla/show_bug.cgi?id=22150
[18:21] <ubot5> sourceware.org bug 22150 in ld "[2.29 Regression] ld.bfd keeps a version reference in .gnu.version_r for symbols which are optimized out" [Normal,Resolved: fixed]
[18:21] <doko> or LP: #1715641
[18:21] <ubot5> Launchpad bug 1715641 in dpkg (Ubuntu) "network-manager built against glibc-2.26 requires GLIBC_2.25 symbol yet doesn't depend on recent enough glibc" [Undecided,Triaged] https://launchpad.net/bugs/1715641
[18:21] <doko> if that was built with a binutils (<< 2.29-12)
[18:22] <doko> but I didn't investigate that
[18:23] <nacc> doko: i think we understand (to some degree) why this is happenning to snaps
[18:28] <doko> I think you'll have some fun with glibc-3.0, when glibc starts dropping deprecated symbols ... and keeping the soname
[18:29] <nacc> doko: ugh
[18:29] <nacc> doko: yeah :)
[18:36] <infinity> Eh?  We won't drop symbols and keep the soname.
[18:36] <infinity> That would be madness.
[18:37] <nacc> infinity: that's what i would have thought, but i was trusting doko :)
[18:38] <doko> infinity: that's the long term plan for glibc-3.0, yes. speak with upstream, carlos and florian
[18:39] <infinity> doko: That's a curious new take on things.  I will indeed talk with Carlos.
[18:39] <infinity> It's always in the past been understood that dropping symbols would be libc7.
[18:41] <doko> but the next versions will be .27 and .28 ...
[21:26] <slangasek> doko: the bogl ftbfs is some sort of toolchain bug; an inline function disappears and generates "undefined reference" when building with -Os