[01:15] <jawn-smith> mwhudson, cjwatson: the ac_cv_func_closefrom configuration flag seems to have done the trick on armhf, but oddly I failed to recreate it on amd64. I'll try again to recreate on amd64 in the morning
[07:26] <TJ-> Eickmeyer: I've updated your bug #1944468 with a highly probably cause
[07:26] <ubottu> Bug 1944468 in gtk+3.0 (Ubuntu) "Electron applications all crash upon launch" [High, New] https://launchpad.net/bugs/1944468
[07:52] <seb128> TJ, Eickmeyer, 'gpu_data_manager_impl_private.cc(415)] GPU process isn't usable. Goodbye.', sounds like rather an issue with your video drivers
=== cpaelzer_ is now known as cpaelzer
[11:09] <mapreri> ddstreet: other tools that I'd be fine giving green light to do constant backports of to all releases (because most likely I'd do them myself :P) are devscripts, u-d-t and pbuilder.  with the assumption that plenty of ubuntu devs stay on the latest release it might make sense to generalize that "dev tools" can always go.
[11:09] <mapreri> just throwing an idea that just came to me for later
=== locutusofborg_ is now known as locutusofborg
[13:13] <ema> there's a broken link to https://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ on https://wiki.ubuntu.com/UbuntuArchitecture (section Packages, "Ubuntu policy manual")
[13:14] <ema> does such a document exist anywhere, I don't seem to be able to find it :)
[14:38] <Eickmeyer> TJ-, seb128: Tried downgrading the video drivers as well, same issue. Same issue also comes up on an all-Intel machine. seb128's suspicion of glibc is very likely.
[14:53] <seb128> Eickmeyer, well, my testcase is pretty minimal, use hirsture, upgrade only libc6 and get the bug
[14:54] <Eickmeyer> seb128: My testcase didn't involve that, but did involve downgrading gtk to no avail, downgrading my video drivers to no avail, trying on different DEs, and trying on an all-Intel machine.
[14:55] <Eickmeyer> The only thiing that makes it behave properly is hirsute, but then once impish sources are introduced it breaks.
[14:56] <Eickmeyer> seb128: glibc is the only thing that makes sense at this point.
[14:56] <mapreri> ddstreet: add debootstrap to the list :3
[14:57] <Eickmeyer> I worked for about 4 hours on this issue yesterday trying to triage it.
[14:58] <seb128> Eickmeyer, I got lucky I started the reverse way, it's easier to upgrade than downgrade :)
[14:58] <seb128> also I managed to pick the right package on first try which helps
[14:59] <Eickmeyer> seb128: Also, you happened to have a reasonable suspicion of glibc since that broke a lot of stuff when it was introduced.
[15:02] <Eickmeyer> seb128: Either way, I'm glad you were able to finish what I started with that whole process. I just simply ran out of time in the day.
[15:02] <seb128> well, now we need to get the issue fixed
[15:02] <seb128> hopefully someone from foundations picks that up
[15:03] <Eickmeyer> Yeah. Honestly, it would be embarassing for us to release something that breaks Electron apps.
[15:04] <Eickmeyer> Especially ones as widely-used as the ones I tested.
[15:08] <teward> ddstreet: mapreri i'm still playing catchup for the latest email threads due to work and may be late by a few min (~5) for the backport meeting
[15:10] <jawn-smith> cjwatson, mwhudson: I've re-done the openssh tests on both arm64 and amd64, and am unable to recreate the failure on those architectures. I'm now re-doing the amd64 test with strace to look for similar ENOSYS errors.
[15:35] <dbungert> I'd like opinions on LP: #1943008 - we have a fix in flight in snapd (but it won't be soon), but there is the matter of what to do for packages that are blocked in migration by systemd such as squashfs-tools and 3 kernel packages.  We could throw some hints around, but based on my understanding of the bug I don't get why any of the snapd autopkgtests are passing at the moment.
[15:35] <ubottu> Launchpad bug 1943008 in squashfs-tools (Ubuntu) "squashfs-tools: needs to depend on libgcc-s1" [Undecided, Confirmed] https://launchpad.net/bugs/1943008
[15:36] <dbungert> s/systemd/snapd/
=== genii-core is now known as genii
[16:34] <dbungert> bdmurray: thoughts on the above?  if we try we can coax some debug info from autopkgtest but I'm unsure if we want to bother.
[16:38] <bdmurray> dbungert: maybe xnox has some insight into the kernel autopkgtests?
=== lucas_ is now known as lucascastro
[20:03] <jawn-smith> mwhudson, cjwatson: disregard what I said earlier about failing to recreate. I've successfully recreated on amd64, and will now be filing the upstream bugs and preparing an Ubuntu/Debian patch
[20:03] <jawn-smith> ^referring to openssh sftp-chroot failure
[21:10] <mwhudson> jawn-smith: ah good