[00:55] <feoh> Hi all. I filed a crappy 20.04 bug and I'm looking for advice on how to improve it: https://bugs.launchpad.net/ubuntu/+source/meta-gnome3/+bug/1872870
[00:55] <feoh> I'm seeing little square outlined outline trails left behind when my mouse cursor moves with the latest update. Just started yesterday.
[00:55] <feoh> I filed the bug under gnome but I wonder if I should target some other more specific target
[00:56] <feoh> and I tried to provide evidence but the trails don't show up in a screen grab
[02:23] <feoh> FWIW added a screencast. That's the only thing I can think of
[02:54] <lotuspsychje> good morning
[08:41] <benjam2000> With ubuntu 20.04 the preseed automation style (debian installer) for automated installs wont be supported anymore?
[09:17] <benjam2000> There are already netinstall or mini images available for 20.04?
[09:29] <benjam2000> Ok, netinstall and mini.iso images seem to be available: http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/
[11:32] <ubuking> hiiiiiii
[13:16] <iconoclasthero> is there an eta for 20.04 RC1?
[13:19] <lotuspsychje> as always, its out when its out iconoclasthero 
[13:50] <sdeziel> I've already described my problem in #ubuntu-server (no response) so apologies for those in both channels.
[13:50] <sdeziel> I was about to apply updates on a Focal server when I noticed the unusually long list that apt wants to pull in. This all seems to be coming from the kernel upgrade that suddenly wants to bring DKMS and all that
[13:51] <sdeziel> here's what it looks like: https://paste.ubuntu.com/p/hfmV6BwTd9/
[13:51] <sdeziel> to be precise, I don't want DKMS nor kernel headers and didn't need them in the previous weeks
[13:59] <sdeziel> there seems to be a link with wireguard and its -dkms package. I've now moved to only installing wireguard-tools to stop trying to go the DKMS route
[14:00] <lotuspsychje> sdeziel: you might wanna bring that up in #ubuntu-quality too, maybe someone noticed aswell
[14:00] <sdeziel> so only wireguard-tools is installed now but it still wants to pull wireguard-dkms
[14:01] <sdeziel> lotuspsychje: yeah, but I'm now suspecting a behavior change in apt that would explain why it wants to pull in Recommends during upgrades
[14:02] <sdeziel> s/upgrades/dist-upgrades/
[14:02] <lotuspsychje> i just did the upgrades, but i dont have wireguard installed, so didnt notice
[14:03] <sdeziel> apt upgrade behaves normally, it's just apt dist-upgrades now wants to bring those Recommends
[14:05] <sdeziel> I'm lost now. I ran apt upgrade and it pulled just the kernel which is good. Then I ran apt dist-upgrade and it said nothing needed to be updated
[14:08] <sdeziel> maybe that was all triggered by the fact that I initially had the wireguard package installed without having wireguard-dkms (weird though as it's listed as Depends)
[14:08] <sdeziel> thanks lotuspsychje
[14:12] <lotuspsychje> sdeziel: when i try to install wireguard here, it pulls all dependencies so it seems
[14:13] <sdeziel> lotuspsychje: yeah, I don't understand how it worked for me here without the wireguard-dkms package
[14:13] <sdeziel> I know the .ko is shipped by the kernel but the wireguard metapackage is really supposed to insist on wireguard-dkms
[14:14] <sdeziel> so it was a mistake to install wireguard to begin with as I really only want wireguard-tools
[14:19] <mcphail> I think the wireguard thing is just a messy transition from 19.10, where the kernel didn't have the module built in
[14:21] <sdeziel> mcphail: I thing the wireguard metapackage is less relevant now and potentially confusing
[14:21] <sdeziel> s/thing/think/
[14:21] <sdeziel> I would guess that the vast majority of users will want what wireguard-tools + the built-in module provides
[14:22] <lotuspsychje> sdeziel: maybe you installed it, during a stage dependencies were still being worked on?
[14:22] <mcphail> Yes. Now sure how these things are supposed to be handled. I mean, having the wireguard-dkms package doesn't seem to break anything but itis annoying
[14:27] <sdeziel> lotuspsychje: indeed, at some point, wireguard-dkms was installed without me realizing
[14:39] <lotuspsychje> sdeziel: yeah suspected something like that
[14:43] <lotuspsychje> sdeziel: affected your bug
[14:45] <sdeziel> lotuspsychje: thx
[16:13] <howarth> What's the deal with the kernel update? Part of it shows 5.4.0.24.29 but most of it still shows 5.4.0.24.28. Yet according to https://launchpad.net/ubuntu/focal/+package/linux-generic it has the former (5.4.0.24.29) as in Release.
[16:14] <lotuspsychje> !info linux-image-generic
[16:16] <lotuspsychje> howarth: sudo apt autoremove
[16:19] <howarth> But linux-image-5.4.0-24-generic, linux-modules-5.4.0-24-generic and linux-modules-extra-5.4.0-24-generic, etc are all still at 5.4.0.24.28. Yet https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+build/19145415 shows new 5.4.0.24.29 copies should have been pushed, no?
[16:20] <howarth> Looks like an incomplete update to the 5.4.0.24.29 kernel build in the repo.
[16:20] <howarth> Same issue still exists (for several days now) in proposed-updates.
[16:21] <lotuspsychje> do you have -proposed enabled?
[16:21] <howarth> On a second test drive.
[16:21] <howarth> This one, my main drive, has proposed-updates off.
[16:22] <howarth> I never filed a bug report because I figured it would get fixed before the next kernel push into the release repo.
[16:22] <lotuspsychje> howarth: pastebin please: dpkg --list | grep linux-image
[16:22] <howarth> ii  linux-image-5.4.0-24-generic               5.4.0-24.28                                amd64        Signed kernel image generic
[16:22] <howarth> ii  linux-image-generic                        5.4.0.24.29     
[16:25] <lotuspsychje> from my dpkg logs: 2020-04-16 14:42:38 status installed linux-image-generic:amd64 5.4.0.24.29
[16:26] <howarth> But where is the matching linux-image-5.4.0-24-generic               5.4.0-24.29
[16:26] <howarth> I don't see any evidence on https://packages.ubuntu.com/focal/main/newpkg that it ever got pushed into the repo like it should have
[16:26] <howarth> They built it but for some reason never pushed it
[16:27] <lotuspsychje> howarth: did you full-upgrade?
[16:28] <howarth> One was a dist-upgrade from 19.10 and the other a clean install from the beta
[16:28] <lotuspsychje> !uptodate
[16:29] <howarth> Unless I am missing something, no one has shown evidence that they got linux-image-5.4.0-24-generic               5.4.0-24.29 installed automatically
[16:29] <howarth> I'm not talking about   linux-image-generic
[16:29] <lotuspsychje> howarth: when you uname -a it hides the last number
[16:30] <lotuspsychje> so current should be .29
[16:30] <lotuspsychje> if you fully upated system
[16:30] <lotuspsychje> *updated
[16:30] <howarth> This is checking with 'dpkg --list | grep linux-image'... does it show that you have a 'linux-image-5.4.0-24-generic               5.4.0-24.29'?
[16:31] <howarth> Show me your output for 'dpkg --list | grep linux-image | grep 29'
[16:31] <howarth> ii  linux-image-generic                        5.4.0.24.29                                amd64        Generic Linux kernel image
[16:31] <lotuspsychje> http://dpaste.com/1GPBHHM
[16:32] <howarth> Exactly what I am saying
[16:32] <howarth> You also don't have a linux-image-5.4.0-24-generic               5.4.0-24.29 installed for a signed kernel
[16:32] <howarth> The issue is that ubuntu built it but never pushed into the repo
[16:33] <howarth> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+build/19145415
[16:33] <lotuspsychje> lets reboot first holdon
[16:36] <howarth> My guess is that ubuntu does some manual steps for the kernel signing and dropped the  5.4.0-24.29 copy by accident
[16:56] <howarth> Looking at https://lists.ubuntu.com/archives/focal-changes/2020-April/date.html I see https://lists.ubuntu.com/archives/focal-changes/2020-April/017325.html and https://lists.ubuntu.com/archives/focal-changes/2020-April/017327.html
[16:57] <howarth> For [ubuntu/focal-proposed] linux-signed 5.4.0-24.28 (Accepted) and [ubuntu/focal-proposed] linux-meta 5.4.0.24.29 (Accepted)
[16:57] <howarth> It certainly looks like ubuntu dropped the ball on doing the required  [ubuntu/focal-proposed] linux-signed 5.4.0-24.29 (Accepted)
[16:57] <howarth> which is MIA
[16:59] <howarth> https://launchpad.net/ubuntu/+source/linux-signed/5.4.0-24.28 exists but https://launchpad.net/ubuntu/+source/linux-signed/5.4.0-24.29 doesn't
[17:10] <lotuspsychje> bug #1873315
[17:10] <luna_> Moving from 20.04 Betas to RC now
[17:14] <luna_> howarth: lotuspsychje: i got .24 today
[17:15] <lotuspsychje> yeah we all did
[17:16] <howarth> https://launchpad.net/ubuntu/+source/linux-meta/5.4.0.24.29
[17:16] <howarth> linux-meta (5.4.0.24.29) focal; urgency=medium
[17:16] <howarth>   * Bump ABI 5.4.0-24
[17:16] <howarth>   * Miscellaneous Ubuntu changes
[17:16] <howarth>     - [Packaging] Remove support for riscv64
[17:16] <howarth> linux-meta (5.4.0.23.28) focal; urgency=medium
[17:16] <howarth>   * Bump ABI 5.4.0-23
[17:17] <hggdh> yes, this is a packaging change
[17:19] <howarth> But it is opaque if those linux kernel builds for 5.4.0.24.29 that didn't land in the repo would have actual changes
[17:21] <luna_> Running RC now
[18:28] <wlan2> So I just upgraded a machine to 20.04 and got openmpi-bin as a broken package because something is wrong with /var/lib/dpkg/alternatives/mpi
[18:29] <wlan2> It says update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc
[18:30] <wlan2> I've never encountered this before, and was wondering how to proceed.
[18:47] <wlan2> I think I fixed it, but I don't like the way I did it. I removed /var/lib/dpkg/alternatives/mpi , purged and installed.
[18:47] <wlan2> Just saying in case somebody else gets this issue.
[18:47] <wlan2> Have a nice day.