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