=== ben_r_ is now known as ben_r [10:47] doko, hey, looks like python3-gi/arm64 is unhappy in focal-proposed, do you have about it? [10:47] doko, it looks like maybe some problem with libffi [10:47] testcase [10:47] $ sudo apt install python3-goocalendar [10:48] python3 -c "import goocalendar ; print(goocalendar.__version__)" [10:48] -> segfaults [10:48] #0 0x0000000000000000 in ?? () [10:48] #1 0x0000fffff7390ff8 in ffi_call_SYSV () at ../src/aarch64/sysv.S:114 [10:48] #2 0x0000fffff7390634 in ffi_call_int (cif=0xa12d78, fn=, [10:48] Laney, ^ just as a fyi that's what is creating that stack of python/gi autopkgtest failures on arm64 [10:51] cool, thx for looking at that [11:24] doko, I reported it as bug #1859610 , that's going to block lot of things since any gobject binding is segfaulting much makes the autopkgtest for most desktop components fail on arm64 [11:24] bug 1859610 in libffi (Ubuntu) "python-gi/arm64 segfaults with the focal-proposed libffi version" [High,New] https://launchpad.net/bugs/1859610 [11:42] seb128: yes, known, in the works [11:42] doko, great, thx! [12:37] rafaeldtinoco: we have python-tornado 6.0.3+really5.1.1-2 in focal, how does that change https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/pcs/+git/pcs/+merge/377171/comments/989992 now? [12:37] we can keep requiring >=6 in d/control, like debian [12:38] indeed [12:38] but we didn't have it, right ? (just checking) [12:38] rafaeldtinoco: yeah, it was sycned on the 10th [12:38] https://launchpad.net/ubuntu/+source/python-tornado/+publishinghistory [12:38] ok.. debian dropped the 5.1 patch, we should keep it [12:38] by xnox [12:39] ahasenack: i'll change the merge [12:39] and re-push [12:39] rafaeldtinoco: k [12:43] rafaeldtinoco: debian dropped that work-with-tornado-5 patch, and yet their tests are passing with that tornado 6+really-5 [12:53] rafaeldtinoco: someone also added a badtest hint to pcs, so it migrated [12:55] ... [12:55] =) [12:56] maybe they want to maintain these packages, since they keep racing us [12:57] I'm not sure anymore where we stand now [12:57] i'll have to review my merges [12:57] for us to sync again [13:37] I have a segfault in a package build, but the build environments do not gather crash dumps (at least I found none) [13:37] did anyone ever create a snippet of some sort to configure storing the dump in e.g. sbuild where I could then chroot in and check what is going on [13:38] P.S. of course the issue only appears at the build on LP and sbuild, but works fine when chrooting into sbuild later or LXD or KVm based build envs [13:38] seb128: what to do wirh https://launchpad.net/ubuntu/+source/ubuntuone-dev-tools/13.10-0ubuntu7/+build/18549380 ? [13:40] doko, no idea offhand, I will have a look [13:41] ta [14:22] LocutusOfBorg: why does libsdl2 build-all test run cmake directly instead of with correct options like the package build? [14:35] tjaalton, feel free to fix and commit :D [14:36] * LocutusOfBorg checks [14:36] I'll just disable gles1 from CMakeLists.txt [14:36] it's getting enabled [14:37] unconditionally, if autoconf isn't used [14:41] tjaalton, webkit2gtk started ftbfsing with that error [14:41] ../Source/WebKit/UIProcess/gtk/WaylandCompositor.cpp:134:116: error: ‘EGL_WAYLAND_BUFFER_WL’ was not declared in this scope === ricab is now known as ricab|lunch [14:41] do you know if that's a known issue? [14:41] no [14:43] tjaalton, yes, cmake needs a patch to allow disabling of opengles1 [14:44] seb128: seems to build in experimental [14:56] seb128: EGL_WAYLAND_BUFFER_WL is defined in EGL/eglmesaext.h which is (still) shipped by libegl1-mesa-dev, so dunno why it's not working there [15:11] tjaalton, is the gles1 change somehting I have to commit in Debian too=? [15:23] LocutusOfBorg: it fails to build there, and i filed a bug about it [15:23] needs gles1 disabled [15:24] or the headers fixed, but that's upstream's headache [15:26] rbasak: are there better ways to chroot into an sbuild than sudo chroot /run/schroot/mount/${1} ? [15:27] just in case this might be important as well, $1 is the session ID [15:27] as we are hunting for environment details every little bit could matter [15:38] tjaalton, committed on git === ricab|lunch is now known as ricab [16:56] smb: hi, is this on your radar? https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1859432 [16:56] Launchpad bug 1859432 in xen (Ubuntu) "xen needs to depend on python2 instead of python (or better python3)" [High,Confirmed] [17:00] hm, doko fixed that already [19:55] LocutusOfBorg: llvm-8: are you sure that scripts have a python2 shebang? [21:15] doko, is the libffi no change rebuild fixing the arm64 segfault issue? (just to know if we can/should retry things) [21:54] doko, they haven't [21:55] but I enforce both python2 and python3 at runtime [21:55] so meh [21:55] I had to sed s/python2/python3 for llvm-9 and extract a patch [21:55] I couldn't run dh_python3 to do its job properly and I don't care too much anymore about llvm-8