[07:50] <Esokrates> Did anybody here use apport-retrace recently in sandbox mode and it worked?
[07:51] <Esokrates> bdmurray: could you have a look at https://bugs.launchpad.net/apport/+bug/1866996 ?
[08:12] <tjaalton> juliank: hi, is the focal kernel i915 stable now for you?
[08:13] <juliank> tjaalton: yes both 17 and 18 are stable
[08:13] <juliank> I crashed it yesterday but that was me running out of memory :)
[08:15] <tjaalton> cool, I'll close the bug then
[08:51] <seb128> hum, is libc6/i386 known to have issues in focal(-proposed)
[08:52] <seb128> some autopkgtest started failing with symbols errors, e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/p/pulseaudio/20200312_060342_3f30a@/log.gz
[08:52] <seb128>  /usr/lib/gcc-cross/i686-linux-gnu/9/../../../../i686-linux-gnu/bin/ld: /lib/i386-linux-gnu/librt.so.1: undefined reference to `__clock_nanosleep@GLIBC_PRIVATE'
[08:52] <seb128> etc
[08:52] <seb128> doko, xnox, juliank, ^ do you know?
[08:54] <seb128> hum, also just did an upload and got an armhf failure from the builds
[08:54] <juliank> there was omething about gcc is using private symbols and needs rebuilds
[08:54] <seb128> E: This installation run will require temporarily removing the essential package libc6:armhf due to a Conflicts/Pre-Depends loop.
[08:54] <juliank> this should be fixed soon
[08:54] <juliank> (the E: error)
[08:54] <seb128> k
[08:55] <juliank> The gcc one I think was uploaded too
[08:55] <seb128> the archive is not having a great week with the libc changes!
[08:55] <juliank> yup
[08:55] <seb128> also shouldn't disruptive changes like that go through a ffe before landing?
[08:56] <seb128> the idea is that we should be focussing on bugfixing after ff...
[08:56] <juliank> heh
[08:56] <juliank> that would make sense
[08:57] <juliank> but then it would not change anything, anyway
[08:57] <doko> juliank, seb128: glibc mismatch for native and cross compilers, please retrigger with the glibc in -proposed
[08:57] <seb128> doko, thanks
[10:11] <seb128> doko, bdmurray, apport migrated without glibc so now the autopkgtest are failing unless retried with a trigger :-/
[12:09] <ahasenack> teward: hi, good morning. MIR team is ok with the nginx plan. Do we need a FFe for it do you think?
[12:09] <ahasenack> given it will warrant a release notes entry, I'm inclined to think it does
[12:10] <teward> yes it needs an FFe
[12:11] <ahasenack> I don't think I can overload the same bug with it
[12:11] <ahasenack> let me file a new one and do the paper work, you good with that?
[12:11] <teward> yep, if Release Team acks it I'll upload it :)
[12:13] <ahasenack> ok
[12:30] <AsciiWolf> kenvandine, would it be possible to set a high priority on https://bugs.launchpad.net/snap-store/+bug/1866998 ? this is a quite serious issue that will lead to many users unintentionally uninstalling the Snap Store
[12:30] <AsciiWolf> thanks
[12:41] <rafaeldtinoco> cpaelzer: quick question.. i had issues with kmod in ppa and not locally
[12:41] <rafaeldtinoco> MY_DEB_BUILD_PROFILES="nocheck nodoc noudeb"
[12:42] <rafaeldtinoco> having "noudeb" in the DEB_BUILD_PROFILES makes the build ok.. but ppa probably does not use that build profile
[12:42] <rafaeldtinoco> you know what is special about kmod and the libkmod-udeb pkg ?
[12:47] <ogra> sil2100, gentle poke about https://github.com/snapcore/pi-gadget/pull/33 ...
[12:50] <kenvandine> AsciiWolf: thanks, i'll look into that
[12:52] <cpaelzer> rafaeldtinoco: no I don't know its special bells and whistles :-/
[12:56] <rafaeldtinoco> yep, I wonder if its something the builders have and ppas dont
[12:56] <rafaeldtinoco> xnox: would u know ? kmod pkg ^
[12:58] <xnox> one second, brb.
[13:01] <xnox> rafaeldtinoco:  what is your failure?
[13:01] <rafaeldtinoco> xnox: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1864992/+build/18828616
[13:01] <rafaeldtinoco> it complains about udeb and a debian helper param
[13:01] <rafaeldtinoco> dh_makeshlibs: The udeb libkmod2-udeb does not contain any shared libraries but --add-udeb=libkmod2-udeb was passed!?
[13:02] <rafaeldtinoco> i have this locally as well if not using "noudeb"
[13:03] <sil2100> ogra: eeek, ok, I'll try to look in a bit
[13:03] <xnox> rafaeldtinoco:  if you read the log, it does create two builds build-udeb & build-deb thus it must build a full-fat libkmod2-udeb and it must contain a shared library
[13:04] <xnox> rafaeldtinoco:  possibly some regression somewhere, i.e. changed paths or debhelper, thus something is not building/installing libkmod shared libraries from the build-udeb/* into debian/libkmod2-udeb/*
[13:04] <rafaeldtinoco> yep that is what I was afraid
[13:04] <xnox> rafaeldtinoco:  and we still need the udeb
[13:04] <rafaeldtinoco> ok.. ill verify it
[13:05] <rafaeldtinoco> thanks!
[13:05] <rafaeldtinoco> i wanted to discard something builders wise
[13:06] <xnox> rafaeldtinoco:  does 27 rebuild fine? it has this https://salsa.debian.org/md/kmod/-/commit/e5ab645e12ba8a23275d4a0e352febc7bea101ca
[13:07] <rafaeldtinoco> havent tried, will do
[13:32] <AsciiWolf> kenvandine, thanks! btw. there's another smaller issue that would be also good to fix and should be easy to fix: https://bugs.launchpad.net/snap-store/+bug/1866997 - should be fixed by setting a packagekit_autoremove meson build option to true :)
[13:39] <ahasenack> teward: hi, can you add your debdiff to https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1867150 ? Or branch
[13:40] <ahasenack> teward: I'll link to the pastebin from yesterday, but I think you updated it already
[13:40] <ahasenack> ah, it's in the other bug?
[13:40]  * ahasenack checks
[13:40] <ahasenack> yep
[13:43] <bdmurray> seb128: Is there anything I can do to fix it?
[13:44] <seb128> bdmurray, I've no idea, maybe the code could check what glibc version is in use and test one string or the other according?
[13:44] <seb128> bdmurray, or maybe now it's done and we just need glibc to migrate to fix it...
[14:09] <teward> ahasenack: yeah i already uploaded the debdiff to that first bug ;)
[14:14] <ahasenack> teward: ok, I attached it to the ffe one as well
[16:12] <cpaelzer> doko: (and FYI ahasenack) the postgresql-12 build issue is indeed llvm
[16:12] <cpaelzer> a segfault
[16:12] <cpaelzer> doko: the install log has a few details https://paste.ubuntu.com/p/3hKrfH3sJJ/
[16:12] <cpaelzer> eventually it crashes with
[16:12] <cpaelzer> #0 0x000003ff7faab14a (/usr/lib/s390x-linux-gnu/libLLVM-10.so.1+0x9ab14a)
[16:12] <cpaelzer> Segmentation fault
[16:14] <cpaelzer> it is reproducible by re-issugin that looong command to /usr/lib/llvm-10/bin/llvm-lto
[16:15] <cpaelzer> doko: I'll install dbgsyms and try to get you a backtrace
[16:15] <cpaelzer> doko: can you look if that is any kind of known issue from there?
[16:16] <xnox> cpaelzer:  is there a bug report? we can escalate it to IBM llvm maintainers
[16:17] <xnox> cpaelzer:  is it reproducible if one builds with '-march=z13' set in all the build flags?
[16:17] <xnox> cpaelzer:  i wonder if you should build with llvm-9 for now, to get postgresql migrating, whilst this is investigated
[16:18] <cpaelzer> xnox: PGsql is fine, this is triggered by the llvm-10 rebuild that dodko did
[16:18] <xnox> ah, ok
[16:18] <cpaelzer> I'm filing a bug with details right now
[16:18] <cpaelzer> doko can then decide if he wants to pass that to IBM or anything else
[16:21] <doko> xnox: that's already done
[16:21] <doko> cpaelzer: yes, a stacktrace would be nice
[16:22] <cpaelzer> hmm the stack tarce isn't super useful
[16:22] <cpaelzer> do we have a gdb issue in focal or is llvm hard to debug?
[16:22] <cpaelzer> Python Exception <class 'gdb.error'> PC not saved:
[16:23] <cpaelzer> http://paste.ubuntu.com/p/8ffXqvmGWN/
[16:23] <cpaelzer> doko: ^^ this isn't enough to help you I guess right?
[16:24]  * cpaelzer installs more dbgsyms
[16:25] <cpaelzer> ah better now
[16:25] <cpaelzer> doko: xnox: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-10/+bug/1867173 has all the data including the backtrace
[16:25] <cpaelzer> doko: anything I should check immediately ?
[16:30] <doko> cpaelzer: forwarded
[16:36] <cpaelzer> doko: I attached a core file I saved with gdb
[16:36] <cpaelzer> let me know if you ever need more on it
[20:30] <mwhudson> xnox: have you looked at the casper bug yet?
[20:40] <ahasenack> teward: hi, debian doesn't have this geoip2 module?
[20:41] <teward> nope
[20:41] <teward> debian doesn't have nginx-core either
[20:41] <ahasenack> k
[20:41] <ahasenack> I mean, the geoip2 .so isn't shipped in any other package, right?
[20:42] <teward> the nginx geoip2 .so?  nope.
[20:42] <ahasenack> ok
[21:14] <ahasenack> teward: mir on geoip2 filed
[22:40] <Laney> https://launchpadlibrarian.net/468839824/buildlog_ubuntu-focal-s390x.gobject-introspection_1.64.0-1_BUILDING.txt.gz
[22:40] <Laney> what does that mean
[22:40] <Laney> :/ :/ :/ :\ :\ :\
[22:43] <sarnold> "The use of ‘#include_next’ can lead to great confusion" https://gcc.gnu.org/onlinedocs/gcc-7.5.0/cpp/Wrapper-Headers.html
[22:53] <Laney> dunno right now how limits.h from glibc is meant to find the one from the compiler
[22:53] <Laney> any hints welcome, will have to come back to this tomorrow