[05:41] Where can I find git repos for how packages are built? Debian uses salsa.debian.org, is there an equivalent for Ubuntu? [05:53] The_Ball: It's often specified in the package metadata [05:54] If you run apt-cache showsrc , see if there are "Vcs-" fields [05:55] Skuggen, ah, thank you very much [05:56] Many Ubuntu packages are just synced from Debian (or with small patches applied on top) [05:57] Skuggen, doesn't look like python-twisted has the vcs fields, but I was able to find the source -> git clone https://git.launchpad.net/ubuntu/+source/twisted [05:58] The twisted package is lagging a bit from Debian so I have to backport one fix [05:58] Looks like it's just synced directly from debian. At least on bionic it has a debian version string === kklimonda_ is now known as kklimonda === coreycb_ is now known as coreycb === rsalveti_ is now known as rsalveti === dkessel_ is now known as dkessel === fabiomirmar_ is now known as fabiomirmar === popey__ is now known as popey [06:27] Yep, it's in sync between Debian unstable and Ubuntu eoan right now [08:29] vorlon, xnox I'm syncing mono, the s390x build has been successful! [08:30] nice [08:36] xnox, to be honest, instead of building with -O0, Debian decided to disable docs generation on s390x with --with-mcs-docs=no [08:36] * LocutusOfBorg updates bug https://bugs.launchpad.net/ubuntu/+source/mono/+bug/1525454 [08:36] Launchpad bug 1525454 in mono (Ubuntu) "bootstrapping mono compiler fails at mdoc" [Undecided,Fix released] [09:01] bdrung, https://launchpad.net/~videolan/+members#active can you please add me back? [15:03] tsimonq2: i noticed in the tests that they are using snapped Chromium to power Selenium. I wonder if that's what's broken on their test... [15:04] blorp [15:04] Laney: TL;DR it's broken and it's your fault :p [15:04] just kidding ;) [15:05] I feel like that *should* work [15:05] teward: can you file a bug please? [15:05] Laney: bug on...? [15:05] will ask if oSoMoN can take a look [15:05] kopano thing [15:05] ah yes [15:05] Laney: if you can take a peek at the autopkgtest failures as well and see if I'm right that it's Chromium related [15:05] and if I can badtest it temporarily [15:06] or get it badtested* [15:06] I would expect that's the relevant change [15:06] probably. [15:07] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/k/kopano-webapp/20190624_082152_0ef6d@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/arm64/k/kopano-webapp/20190624_084645_0ef6d@/log.gz [15:07] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/armhf/k/kopano-webapp/20190624_082623_0ef6d@/log.gz [15:07] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/i386/k/kopano-webapp/20190624_082523_0ef6d@/log.gz the 4 buildfailures [15:07] s/buildfailures/test failures/ [15:07] 3 of them are CHromium crashes [15:07] 4th said something about snaps not working on the arch [15:08] Laney: bug against chromium or the kopano-webapp package? [15:08] probably chromium for now [15:11] Laney: i filed an autopkgtest failures bug against kopano-webapp reporting the test failures; if it's indeed a Chromium issue they can still look into it. https://bugs.launchpad.net/ubuntu/+source/kopano-webapp/+bug/1834052 [15:11] Launchpad bug 1834052 in kopano-webapp (Ubuntu) "autopkgtest failures: Chromium-Related" [Undecided,New] [15:11] thanks [15:12] kenvandine: ^---- is ok to ask Olivier to look at this? [15:12] Laney: may still ask for it to be badtested if "No Easy Fix" is the problem here. [15:12] since one of them was some complaint about incompatible architecture or something [15:13] yeah maybe, but I feel like we should be able to run snaps there [15:13] give us a couple of days [15:14] Laney: indeed. armhf seems to be the hjeadache: ==> Installing the chromium snap error: system does not fully support snapd: apparmor detected but insufficient permissions to use it [15:14] but i'm more concerned with the chromium crashes on the other ones [15:14] i'm also confused WHY the test pulls in Chromium just to test what's in the title of the navbar [15:14] they could just curl that... [15:15] (seems like an overly heavy test IMO) [15:15] Not sure - I'm just concerned that we don't break Selinium on Chromium [15:15] ack [15:16] the only reason I care as of late is because I pushed the distropatch from TJ that fixes NGINX's pidfile race conditions in SystemD [15:16] which are addressed by changing how NGINX handles pidfiles [15:16] and it SEEMS to work in production [15:19] 🤘 [15:19] cpaelzer, thanks for the lmdb MIR review! [15:24] yw seb128 [15:36] Laney: check with seb128, oSoMoN is on his team now [15:37] Laney, create a card on the trello board please and yes it's fine to ping Olivier about it [15:39] ah sry I forgot that [15:39] I am making a card, it's a -proposed item after all :> [15:40] thx === dannf is now known as dannf` === acheronuk is now known as rikmills [20:09] https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts \o/ [20:10] now that we know i386 will only be running on amd64 hardware, is it possible to raise the baseline to i386+sse2 or so? [20:24] doko, vorlon: ^ [21:01] xnox: hi, have you seen bug 1832295? [21:01] bug 1832295 in lighttpd (Ubuntu) "lighttpd broken by OpenSSL update" [Critical,Confirmed] https://launchpad.net/bugs/1832295 === hays_ is now known as hays [23:13] mitya57: thanks! [23:51] ginggs, tsimonq2, doko: making a change to raise the baseline for i386 introduces the possibility of build regressions; I think we should certainly consider i386 to be in maintenance mode [23:53] is it worth selecting which packages we will build i386? or which packages we will not? (I'm thinking specifically of The Big Browsers and LO.. ceph?) [23:56] sarnold: https://blog.ubuntu.com/2019/06/24/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts explicitly says we will select, with community input [23:58] vorlon: yay, thanks