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