[07:10] <LocutusOfBorg> Unit193, yes, because I want to do the debian transition asap
[07:11] <Unit193> Heh, it was on the TODO for today, but thanks!  (I closed a couple other Debian bugs in the meantime, so all's good)
[09:33] <LocutusOfBorg> doko, https://launchpadlibrarian.net/432385023/buildlog_ubuntu-eoan-armhf.sbcl_2%3A1.5.4-1_BUILDING.txt.gz
[09:33] <LocutusOfBorg> cc: error: unrecognized -march target: armv5
[09:33] <LocutusOfBorg> cc: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8-m.base armv8-m.main armv8-r iwmmxt iwmmxt2 native; did you mean 'armv4'?
[09:33] <LocutusOfBorg> is that normal?
[09:37] <LocutusOfBorg> looks like it is https://www.phoronix.com/scan.php?page=news_item&px=GCC-9-Dropping-Older-ARM
[09:39] <LocutusOfBorg> maybe armv7 is the correct replacement?
[10:43] <doko> LocutusOfBorg: armhf is armv7 both in Debian/Ubuntu
[13:18] <doko> amurray, apw, infinity: https://bugs.launchpad.net/ubuntu/+source/gcc-9-cross/+bug/1836045  I haven't figured out the root cause yet. for now just rebuilding the c-t-b packages
[13:32] <doko> infinity, apw: also https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1836064
[13:34] <apw> sforshee, ^
[13:59] <sforshee> doko: I reponded on bug 1836064, looks like glibc has a fix upstream for that
[14:03] <sforshee> doko, infinity, amurray: while on the topic of kernel headers changes breaking glibc, I had also filed bug 1830044 a while back
[14:27] <doko> sforshee: any idea about the powerpc constants?
[14:35] <sforshee> doko: looking
[15:03] <Laney> what's up with this dkms breakage? e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/o/oss4/20190708_225935_da9bd@/log.gz which is https://paste.ubuntu.com/p/QXfgjvDDnM/
[15:07] <doko> Laney: duflu asked about that yesterday ...
[15:07] <Laney> doko: unfortunately we aren't the same person :(
[15:07] <doko> well, it was on #u-d: https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040741.html
[15:08] <doko> -desktop even
[15:08] <Laney> I've seen the announcement
[15:09] <Laney> is it expected that it breaks builds?
[15:09] <doko> yes
[15:09] <doko> anything that is not user space
[15:13] <Laney> might it be worth calling this out?
[15:13] <Laney> I see oss4-dkms and fwts-efi-runtime-dkms so far looking at the glib2.0 autopkgtest regressions
[15:20] <doko> don't call me, I'm neither security nor kernel
[15:20] <Laney> & are we expected to fix this or turn the flag off? if the latter, could dkms do that for us?
[15:21] <Laney> https://launchpadlibrarian.net/432423025/nvidia-graphics-drivers-430_430.26-0ubuntu2_430.26-0ubuntu3.diff.gz I see that tseliot1 turned it off there
[15:21] <Laney> amurray: ^---
[15:26] <tseliot> I don't know if my message showed up, so I am going to write it again
[15:27] <tseliot> doko: did you notify the kernel team before making that change?
[15:27] <doko> tseliot: not my area, please ask security
[15:27] <doko> amurray: ^^^
[15:28] <doko> tseliot: did the kernel team notify ubuntu-devel before uploading 5.2?
[15:30] <tseliot> doko: I don't deal with kernel releases. I only fix the nvidia dkms packages when they fail to build against a new kernel (usually, either in our PPA or in -proposed)
[15:31] <tseliot> doko: also, I don't see the point of that question, since I can reproduce the problem with Linux 5.0
[15:32] <sforshee> tseliot: the kernel in -proposed add -fcf-protection=none to the kernel's retpoline flags to fix the issue, I've sent a patch upstream too
[15:32] <doko> tseliot: and I don't see the point why you are asking me ...
[15:33] <tseliot> sforshee: ok, that's good. Is that only for 5.2? (just so I know when I shouldn't apply my patch)
[15:33] <doko> something broken, must be doko ...
[15:34] <tseliot> doko: because of your name in the changelog? https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961/comments/14
[15:34] <sforshee> tseliot: so far it's only applied to 5.2, I'm not sure there's a reason to apply it to 5.0 now that 5.2 is in eoan-proposed
[15:34] <doko> tseliot: please read amurray's email about the hardening flags
[15:35] <Laney> sforshee: oho, so it should fix itself when that migrates?
[15:35] <sforshee> Laney: yes
[15:35] <Laney> nice
[15:36] <tseliot> sforshee: ok, I'll drop the patch when that is in then, thanks
[15:41] <tseliot> doko: I saw his email now. I imagine our testing framework caught the dkms failures with the new gcc, maybe when it was already in. Anyway, I'm glad it will be fixed soon.
[17:57] <doko> sforshee: do a fgrep -r SO_RCVTIMEO, for the 5.0 and 5.2 sources. It looks like all archs except powerpc were updated ...
[18:58] <seb128> bdmurray, hey, on bug #1551623 the submitter replied to your comment pointing to a dpkg fix for triggers, maybe that would make sense to get instead (and SRU), can you get that one on the foundations agenda to discuss?
[19:01] <bdmurray> seb128: Will do, thanks!
[19:02] <seb128> bdmurray, thx!
[19:18] <seb128> xnox, bug #1835968 claims to be a regression from your openssl 1.1 patch/SRU
[19:19] <seb128> bdmurray, I never know, what's the best way to flag SRU regressions?
[19:19] <seb128> just tagging the bug?
[19:20] <seb128> that doesn't ping the SRU team members though right? e.g doesn't lead to have the bug reviewed in priority to decide what's the next action needed?
[19:22] <bdmurray> seb128: I think vorlon and I are both subscribed to regression-update tagged bug reports.
[19:22] <seb128> ah ok, I didn't even know you could subscribe to a tag
[19:22] <seb128> good to know, thx :)
[19:22] <vorlon> yep
[19:22] <bdmurray> lol, that's old
[19:24] <bdmurray> well my +subscriptions page is timing out
[19:25] <seb128> same here :-/
[19:31] <rbasak> TIL
[19:31] <tsimonq2> I often wonder if that timeout threshold should be raised.
[19:31] <tsimonq2> Some pages I expect to take some time to load.
[20:58] <Unit193> doko: Re: dwz on compressed sections.  I had found https://sourceware.org/bugzilla/show_bug.cgi?id=24725 upstream and presumed that sufficed, or did you specifically want one reported in Ubuntu(/Debian)?
[21:37] <doko> Unit193: yep, but not much we can do downstream. There is discussion elsewhere if and when error codes should just be ignored
[21:38] <Unit193> Indeed not, that's why I figured that was the best option.  Some of the ruby team members were wondering if it'd be better to wait for dwz to be fixed, or fix it in ruby2.5.
[21:56] <doko> Unit193: does ruby compress debug sections by default?
[21:59] <Unit193> doko: As noted in the other channel, for some odd reason yeah it's an upstream default.