[07:24] <seb128> vorlon, retrying n-m autopkgtests isn't going to work, the log is having those kernels errors that seem the issue/a fallout from the new gcc
[07:24] <seb128>  error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible
[07:24] <seb128> (e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/i386/n/network-manager/20190708_231002_6fa4a@/log.gz)
[07:26] <seb128> also dkms/nvidia drivers seem broken now, would be good to have some autopkgtest to prevent gcc migrating if it breaks drivers next time maybe?
[07:26] <seb128> doko, ^
[07:29] <seb128> vorlon, the n-m warnings look like bug #1835764
[08:03] <doko> seb128: please see the announcement from amurray and contact the security team for the hardening changes
[08:03] <seb128> doko, what announcement de amurray?
[08:03] <seb128> from*
[08:04] <amurray> seb128: https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040741.html
[08:05] <seb128> amurray, ah, thanks, that's some week old and scrolled out from my first page
[08:05] <seb128> doko, would have been nice to include a reminder to that one in your gcc transition email, maybe a tip for next time :)
[08:06] <seb128> since that only got active with the gcc change
[08:06] <amurray> the best fix for this would be to update the eoan kernel to add -fcf-protection=none I think
[08:06] <amurray> seb128: it *should* have been in gcc-8 already
[08:06] <seb128> amurray, doko, it seems a bit backward to have landed the changes before fixing the kernel
[08:06] <seb128> now we are in a situation were drivers are broken on eoan archive
[08:07] <seb128> nothing even blocked that breakage to limit it to proposed :-/
[08:07] <doko> dude, the kernel team is just binary copying kernels to eoan, and yes, they know about that
[08:07] <amurray> seb128: apologies, it slipped off my radar with some embargoed security stuff which just went out the door
[08:07] <seb128> what has how they upload to do with that?
[08:08] <seb128> amurray, no worry, I just wodner if we need some sort of autopkgtest to avoid having $things  migrated when dkms gets screwed next time
[08:08] <amurray> doko: oh well that fixes my mental model then - I was wondering why the eoan kernel builds weren't failing as well but if they are being done on disco gcc that would make sense
[08:09]  * amurray will look at cooking up something for the eoan kernel and will discuss with kernel-team
[08:09] <doko> ta
[08:09] <seb128> amurray, thx
[08:10]  * seb128 brb, need to change location for a meeting
[08:12]  * amurray dinner etc - back later
[08:53] <seb128> cyphermox, hey, what's the status of the grub2 buildfix for eoan? any chance that lands this week?
[08:58] <sladen> bout time
[09:17] <Unit193> Hrm, it seems to me when you select a compressor in /etc/initramfs-tools/initramfs.conf, mkinitramfs shouldn't silently bail if the compressor is missing.
[09:19] <Unit193> Something like http://paste.openstack.org/show/M6SOlCnADce7eUXS1W4c
[09:22] <seb128> powersj, hey, unsure if you are the right person to ping about that but do you know if daily ISO utah test env is having issue? seems like bionic/eoan test are bailing out on an error 7
[10:24] <rbasak> Could someone review https://code.launchpad.net/~racb/ubuntu-transition-tracker/mysql-8/+merge/369878 please? I've not done this before, and I can't figure out how to test locally (seems that ben can't download from Ubuntu and the go script is a workaround but not suitable for use outside the machine it runs on)
[10:34] <rbasak> paride: see seb128's question from about an hour ago please - can you help? ^
[10:36] <paride> seb128, oh yes jibel and me were looking at the issue
[10:36] <paride> seb128, error 7 is defined as a command line parsing error, but it seems that what's actually happen is that a URLChecker method is failing, probably because of networking issues
[10:36] <paride> and the error is deceptive
[10:37] <paride> (thanks rbasak for the ping)
[11:23] <seb128> rbasak, paride, thx! do you know what needs to be done?
[11:38] <paride> seb128, looks like it's back to normal, but let me re-launch another couple of jobs manually
[11:39] <seb128> paride, thx
[11:40] <seb128> paride, I'm curious but what part of the log hinted out that it was an infra issue? just the knowledge of what is behind error7 ? (can you point me to where those are defined?)
[11:46] <paride> seb128, the log wasn't really useful. We observed a couple of things: (1) nothing was changed on venonat, utah, or the job definitions (2) the build didn't always fail, but they were very flaky (3) utah took a long time to parse its arguments, hinting it was trying to do something over the network (4) there is this URLChecker class which the parser
[11:46] <paride>  uses to check if the URL which are passed to UTAH are valid, but which actually makes things more difficult to debug
[11:46] <paride> and so that's what we're blaming and why
[11:46] <seb128> paride, k, thx for the details, let's see how the retries goes then!
[11:47] <paride> seb128, if you want to have a look, `git clone lp:utah`, grep URLChecker and follow it back
[11:47] <seb128> k
[11:47] <seb128> thx!
[11:47] <paride> yw!
[11:50] <seb128> paride, seems it worked, I got 'back to normal' emails for bionic and eoan now ;-)
[11:51] <seb128> and the pending ISO migrated to be current
[11:51] <paride> excellent :)
[12:52] <rbasak> Could someone review https://code.launchpad.net/~racb/ubuntu-transition-tracker/mysql-8/+merge/369878 please? I've not done this before, and I can't figure out how to test locally (seems that ben can't download from Ubuntu and the go script is a workaround but not suitable for use outside the machine it runs on)
[13:37] <Laney> rbasak: it looks reasonable, I suggest just committing it and seeing what happens
[14:03] <rbasak> Laney: thanks!
[14:06] <cyphermox> seb128: I have the fix staged, I'm finishing up on testing the new grub post-merge
[14:07] <seb128> cyphermox, ok, so likely this week?
[14:08] <cyphermox> yes, likely
[14:08] <seb128> ups
[14:08] <seb128> cyphermox, great :)
[14:09] <seb128> cyphermox, oh, also what's the status for the plymouth patches upstreaming/new version update from your side? I had it on my june backlog but failed to got to it, I plan to try again this month!
[14:13] <kenvandine> vorlon: can you please promote xdg-desktop-portals and xdg-desktop-portals-gtk in bionic per bug 1750069 and bug 1749672
[14:14] <kenvandine> vorlon: i'm trying to update the seed now, but Laney said i need them promoted first
[14:24] <cyphermox> seb128: I have not yet had time to look at plymouth this cycle
[14:26] <seb128> cyphermox, do you think you are going to be able to squeeze some time for that in the next weeks?
[14:34] <seb128> cyphermox, I will try to have a go at that update since we would like to see the new version in but let me know if you start poking as well so we don't dup work
[14:41] <LocutusOfBorg> xnox, hello, your dh-cargo merge il blocking a bunch of rust packages...
[14:55] <ahasenack> doko: dealing with some gcc9 fallout,
[14:55] <ahasenack> doko: stuff like this: https://pastebin.ubuntu.com/p/nSBdGN3xy4/ and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780
[14:55] <ahasenack> doko: googling brought up https://bugs.squid-cache.org/show_bug.cgi?id=4969, is that a thing for gcc9?
[14:55] <ahasenack> er, switch the bugs, "is that a thing" is the gcc bug
[14:56] <ahasenack> let me refrase
[14:56] <ahasenack> doko: stuff like this: https://pastebin.ubuntu.com/p/nSBdGN3xy4/ and https://bugs.squid-cache.org/show_bug.cgi?id=4969
[14:56] <ahasenack> doko: googling brought up https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780, is that a thing for gcc9?
[15:00] <doko> ahasenack: are you seeing this with GCC 9 only? according to the report it should be in 8 as well
[15:01] <ahasenack> yeah, the squid build works with gcc8
[15:01] <ahasenack> the gcc 9 release notes say that this stringop-truncation check was expanded a bit
[15:01] <ahasenack> I'm still digging, for example, it only happened with -O2 or higher
[15:02] <doko> well, -Wno-error=stringop-truncation is your friend ...
[15:02] <ahasenack> with just -Wall -Werror -Wstringop-truncation it works, but if I add -O2 then it fails
[16:05] <vorlon> seb128: hopefully the new kernel in eoan-proposed has fixed this - I'm retrying those nm tests with --all-proposed to see
[16:07] <vorlon> kenvandine: bionic only, or both bionic and xenial?
[16:08] <kenvandine> please promote both
[16:08] <kenvandine> vorlon: i haven't prepared the seed for xenial yet, but i will be this week
[16:09] <vorlon> kenvandine: also, it is normally the case that we add things to seeds /first/ and then change the archive, so that we can use component-mismatches as a guide for what needs promoting; we don't generate c-m reports for !devel, but I'm not sure why it should be promoted before the seed change anyway
[16:09] <kenvandine> the update script won't find it
[16:09] <vorlon> update script?
[16:09] <kenvandine> Laney said we need to promote it first
[16:09] <kenvandine> in ubuntu-meta
[16:09] <vorlon> oh, you do need to promote it before reuploading ubuntu-meta, yes
[16:09] <kenvandine> yes
[16:10] <vorlon> but the ordering is (normally) seed change -> archive promotion -> ubuntu-meta upload
[16:10] <kenvandine> right, for devel
[16:19] <seb128> vorlon, thx
[16:24] <vorlon> kenvandine: the xdg-desktop-portal dependencies look a bit strange on xenial; Depends: default-dbus-session-bus | dbus-session-bus | dbus-x11 but only the third of these exists in the release
[16:24] <kenvandine> yeah
[16:25] <kenvandine> there are other packages in xenial that followed that pattern as well
[16:25] <kenvandine> so the packaging matched debian, for example
[16:25] <vorlon> mm
[16:26] <kenvandine> i can change it
[16:26] <vorlon> anyway, promotions done on both series
[16:26] <kenvandine> thanks
[18:08] <GunnarHj> bdmurray: Just replied to your question at bug #1834406. Any other idea how to reach out to CJK users willing to help out?
[18:12] <bdmurray> GunnarHj: I think the ubuntu-quality list used to be used for calls for testing but I'm not sure how active that list is now
[18:17] <GunnarHj> bdmurray: I don't know either, but that's an idea. Do you think the statements so far are insufficient, so I should try that way? (Personally, and unlike my last dubious SRU proposal, I feel this is a safe one.)
[18:18] <bdmurray> GunnarHj: I was following along with sil2100's comment.
[18:18] <bdmurray> https://bugs.launchpad.net/ubuntu/+source/fonts-noto-cjk/+bug/1834406/comments/4
[18:19] <GunnarHj> bdmurray: Right, and that's the reason for the efforts so far.
[18:22] <bdmurray> GunnarHj: Okay, I'd asked about the call for testing because I wasn't sure what calls had been made.
[18:24] <bdmurray> GunnarHj: Either way let's give it a bit more time to age though.
[18:27] <GunnarHj> bdmurray: Sure, no problem. The new era started May 1, so it's late anyway.. TBH I would have expected some Japanese users to act as drivers to have it tested, so I'm a bit disappointed.
[18:30] <GunnarHj> bdmurray: Maybe it would help if you added a comment to the bug about the decision to wait a bit due to few test reports?
[22:25] <Unit193> LocutusOfBorg: Ah, you already commented on the opensips report, was just about to do that now.  Very well then.