[07:10] Unit193, yes, because I want to do the debian transition asap [07:11] Heh, it was on the TODO for today, but thanks! (I closed a couple other Debian bugs in the meantime, so all's good) === mitya57_ is now known as mitya57 [09:33] doko, https://launchpadlibrarian.net/432385023/buildlog_ubuntu-eoan-armhf.sbcl_2%3A1.5.4-1_BUILDING.txt.gz [09:33] cc: error: unrecognized -march target: armv5 [09:33] 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] is that normal? [09:37] looks like it is https://www.phoronix.com/scan.php?page=news_item&px=GCC-9-Dropping-Older-ARM [09:39] maybe armv7 is the correct replacement? === ricab is now known as ricab|bbl [10:43] LocutusOfBorg: armhf is armv7 both in Debian/Ubuntu === ricab|bbl is now known as ricab === ricab is now known as ricab|lunch [13:18] 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:18] Launchpad bug 1836045 in gcc-9-cross (Ubuntu) "ftbfs: gnat cross targeting powerpc" [High,Confirmed] === ricab|lunch is now known as ricab [13:32] infinity, apw: also https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1836064 [13:32] Launchpad bug 1836064 in linux (Ubuntu) "linux-5.2 (?) breaks the c-t-b builds" [Undecided,New] [13:34] sforshee, ^ [13:59] doko: I reponded on bug 1836064, looks like glibc has a fix upstream for that [13:59] bug 1836064 in linux (Ubuntu) "linux-5.2 (?) breaks the c-t-b builds" [Undecided,New] https://launchpad.net/bugs/1836064 [14:03] doko, infinity, amurray: while on the topic of kernel headers changes breaking glibc, I had also filed bug 1830044 a while back [14:03] bug 1830044 in glibc (Ubuntu) "glibc 2.29-0ubuntu2 ADT test failure with linux 5.2.0-0.1" [Undecided,New] https://launchpad.net/bugs/1830044 [14:27] sforshee: any idea about the powerpc constants? [14:35] doko: looking [15:03] 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] Laney: duflu asked about that yesterday ... [15:07] doko: unfortunately we aren't the same person :( [15:07] well, it was on #u-d: https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040741.html [15:08] -desktop even [15:08] I've seen the announcement [15:09] is it expected that it breaks builds? [15:09] yes [15:09] anything that is not user space [15:13] might it be worth calling this out? [15:13] I see oss4-dkms and fwts-efi-runtime-dkms so far looking at the glib2.0 autopkgtest regressions [15:20] don't call me, I'm neither security nor kernel [15:20] & are we expected to fix this or turn the flag off? if the latter, could dkms do that for us? [15:21] 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] amurray: ^--- [15:26] I don't know if my message showed up, so I am going to write it again [15:27] doko: did you notify the kernel team before making that change? [15:27] tseliot: not my area, please ask security [15:27] amurray: ^^^ [15:28] tseliot: did the kernel team notify ubuntu-devel before uploading 5.2? [15:30] 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] doko: also, I don't see the point of that question, since I can reproduce the problem with Linux 5.0 [15:32] 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] tseliot: and I don't see the point why you are asking me ... [15:33] sforshee: ok, that's good. Is that only for 5.2? (just so I know when I shouldn't apply my patch) [15:33] something broken, must be doko ... [15:34] doko: because of your name in the changelog? https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961/comments/14 [15:34] Launchpad bug 1830961 in virtualbox (Ubuntu) "Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible]" [Critical,Confirmed] [15:34] 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] tseliot: please read amurray's email about the hardening flags [15:35] sforshee: oho, so it should fix itself when that migrates? [15:35] Laney: yes [15:35] nice [15:36] sforshee: ok, I'll drop the patch when that is in then, thanks [15:41] 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] 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] 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? [18:58] bug 1551623 in gconf (Ubuntu) "[SRU] package gconf2 3.2.6-3ubuntu6 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [Critical,Triaged] https://launchpad.net/bugs/1551623 [19:01] seb128: Will do, thanks! [19:02] bdmurray, thx! [19:18] xnox, bug #1835968 claims to be a regression from your openssl 1.1 patch/SRU [19:18] bug 1835968 in ruby2.5 (Ubuntu) "Regression in backported patch for openssl 1.1" [Undecided,New] https://launchpad.net/bugs/1835968 [19:19] bdmurray, I never know, what's the best way to flag SRU regressions? [19:19] just tagging the bug? [19:20] 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] seb128: I think vorlon and I are both subscribed to regression-update tagged bug reports. [19:22] ah ok, I didn't even know you could subscribe to a tag [19:22] good to know, thx :) [19:22] yep [19:22] lol, that's old [19:24] well my +subscriptions page is timing out [19:25] same here :-/ [19:31] TIL [19:31] I often wonder if that timeout threshold should be raised. [19:31] Some pages I expect to take some time to load. [20:58] 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)? [20:58] sourceware.org bug 24725 in default "[dwz] Support compressed debug sections" [Enhancement,New] [21:37] Unit193: yep, but not much we can do downstream. There is discussion elsewhere if and when error codes should just be ignored [21:38] 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] Unit193: does ruby compress debug sections by default? [21:59] doko: As noted in the other channel, for some odd reason yeah it's an upstream default.