[00:03] <doko> tsimonq2: well, how to make progress?
[00:04] <tsimonq2> doko: Is kde-l10n-* the last blocker for something, out of curiosity?
[00:04] <Unit193> Perhaps a qt4-rm transition tracker could help?
[00:04] <tsimonq2> That's a good idea.
[00:07] <doko> tsimonq2: just saw that as a big delta compared to debian unstable
[00:08] <tsimonq2> doko: I doubt that's from Kubuntuers of our time.
[00:08] <doko> tsimonq2: well, then file removal bugs
[00:09] <tsimonq2> RikMills: ^ are you okay with this?
[00:58] <RAOF> tjaalton: Hm. Is there any reason to migrate bug #1825940 to -updates? Its only changes are to ICL support, right, and it doesn't actually work?
[00:58] <RAOF> (As in, it will need another mesa upload before it will work?)
[00:59] <RAOF> That sounds more like a “please remove from -proposed” than “it's good to release into -updates” 😸
[01:02] <RAOF> Ah, no, it also includes the 19.0.8 stable release.
[01:03] <tjaalton> RAOF: needs to move to updates, I'd then stage the next upload in proposed which would stay there until the kernel is released
[01:07] <tjaalton> the stablw update fixed some bugs that I probably duped to the tracker bug
[02:45] <rbasak> vorlon: please could you binNEW review src:poco for the MySQL transition? It's not on the critical path yet but will be soon.
[02:46] <rbasak> The binNEW is unrelated to the transition AFAICT.
[02:46] <rbasak> Skuggen, cpaelzer, rafaeldtinoco, bryce, ahasenack: I highlighted in red on the worksheet the packages on the critical path.
[02:47] <rbasak> Please grab when you can, adding yourself to the "Driver" column.
[02:47] <rafaeldtinoco> rbasak: alright
[02:47] <rafaeldtinoco> adding myself
[11:24] <Skuggen> rbasak: Will do
[12:39] <lag> cyphermox: sil2100: waveform: Are you guys aware of this 'critical' Grub2 bug?
[12:39] <lag> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1839317
[13:46] <cyphermox> lag: as I recall that had been fixed in the past
[13:47] <cyphermox> however, not on aarch64; and I'm not certain how well that's been working before either
[13:47] <cyphermox> lag: are you able to reproduce that yourself?
[13:49] <lag> cyphermox: It worked great before - this is a regression
[13:49] <lag> cyphermox: Yes
[13:49] <cyphermox> ok
[13:49] <cyphermox> lag: how does the failure present? would you be able to add a video of it to the bug, just to make sure it's crystal clear for me what the failure looks like?
[13:50] <cyphermox> I think I know what piece of code is the culprit, but still it would help ;)
[13:54] <lag> cyphermox: The failure is 0.25s of black screen - then back to the menu
[13:54] <cyphermox> lag: ok
[13:55] <cyphermox> then, if I may ask for something else
[13:55] <lag> Nope
[13:55] <lag> ;)
[13:55] <lag> Of course
[13:58] <lag> cyphermox: ?
[13:58] <cyphermox> could you modify the grub entry to include: set debug="chain,secureboot,dl"
[13:59] <cyphermox> then run it again, and video (if possible)
[13:59] <cyphermox> there would be debug text shown on screen very briefly
[14:21] <vorlon> rbasak: poco done
[14:21] <rbasak> Ta!
[16:59] <juliank> Hmm, is there like a weird scheduler bug in 5.2.0-10-generic or something?
[16:59] <juliank> I'm having applications randomly lock up on me
[16:59] <juliank> for short period of times
[16:59] <juliank> well, sometimes the entire desktop locks up for like 10 seconds or so
[17:00] <juliank> and suspend does not really work
[17:00] <juliank> but no issues reported in dmesg
[17:00] <juliank> I guess it could also be a bug in gnome-shell where it just prevents the window from rerendering or stuff
[17:01] <juliank> df -h just took 4 seconds to execute
[17:02] <juliank> I feel like I/O is blocking somehow (it's an NVME SSD -> LUKS -> LVM -> btrfs or xfs)
[17:07] <juliank> maybe btrfs is going crazy somehow
[17:10] <juliank> yes, it seems to be the case
[17:10] <juliank> time to move away from it I guess
[18:07] <rbasak> cpaelzer, bryce, ahasenack: I think tdbcmysql is now false positive in the transition tracker because the old libmysqlclient20 dependency did not go away. But it does now have libmysqlclient21 as an alternative, so it should be fine. I suppose the transition tracker isn't well suited to this type of package that does everything manually and therefore more readily supports multiple ABIs at once.
[18:19] <seb128> juliank, aptdaemon/arm64 autopkgtest seems unhappy, is that something you are looking at?
[18:19] <juliank> seb128: Well, not really looking at it. I think we should go back to ignoring them
[18:20] <juliank> There's a weird race or sth that only triggers on arm64
[18:20] <seb128> we ignored them before?
[18:20] <juliank> they were always-failed
[18:20] <juliank> now they passed once
[18:20] <seb128> hum, right
[18:21] <juliank> armhf is similar, but succeeds a lot more often
[18:23] <seb128> seems like a real bug in the test worth fixing though?
[18:24] <cpaelzer> rbasak: yes this is why I added it as alternative
[18:25] <cpaelzer> rbasak: it might be off that list if we add it in front, but that is not worth it IMHO
[18:32] <juliank> seb128: optimally yes
[18:33] <juliank> seb128: but it's a bit unclear whether it's really worth allocating time for
[18:33] <seb128> juliank, if not can you at least get the skip rule added?
[18:33] <juliank> like all the code is arch-independent, so ...
[18:33] <juliank> yeah
[18:34] <seb128> thx
[19:20] <nacc> xnox: not sure if you'd be the relevant point of contact or not, but we're able to reproduce LP: #974454 at will on Bionic. The Debian patch does resolve it in our testing. Would you be opposed to a debdiff to apply it to 19.10 and backport to 18.04? I can do the bug work/SRU template
[22:06] <tomreyn> there's someone in -arm trying to make contact in terms of what looks like a commercial partnership. logs  https://irclogs.ubuntu.com/2019/08/14/%23ubuntu-arm.html
[22:06]  * tomreyn afk