[00:00] <tomreyn> whewre i'm coming form there is to make users aware they are not running something supported
[00:00] <tomreyn> and that there is not upgrade path to 'the same'.
[00:00] <sarnold> heh, and if there's no users, then there's no one to be dissapointed :D
[00:00] <tomreyn> i haven't really thought about a better way, yet
[00:01] <tomreyn> :) not sure if there are any users, surely not of unreleased flavours
[00:01] <tomreyn> can you suggest how to handle it?
[00:01] <sarnold> I know ther were folks dissapointed that it was dropped, of course :( but it's a big job .. so I'm not surprised it wasn't revived
[00:01] <tomreyn> just remove all the grey lines?
[00:02] <sarnold> dunno. grey at least is an easy way to show that whoever put the table together thought about it.
[00:02] <tomreyn> it certainly does seem to involve a lot of work, yes
[00:02] <tomreyn> my goal was not to point out that i'm thinking ;)
[00:02] <sarnold> :D
[00:03] <tomreyn> what would happen on an installation of a flavour on an LTS release when a new Ubuntu LTS is released, do they get a notice?
[00:04] <tomreyn> what would happen on an installation of a flavour on an LTS release when a new Ubuntu LTS is released, but not for this flavour, do they get a notice?
[00:04] <tomreyn> ^ slightly fixed logic
[00:04] <sarnold> tsimonq2: ^^ this seems like one you'd know, any ideas?
[00:07] <tsimonq2> tomreyn: Yes.
[00:08] <tsimonq2> tomreyn: This is the same reason why each flavor doesn't have a custom GRUB entry.
[00:08] <tsimonq2> tomreyn: The base is updated; so is everything on top of it.
[00:08] <tsimonq2> sarnold: Thanks!
[00:09] <tomreyn> Aha, thanks tsimonq2
[00:09] <tsimonq2> No problem :)
[00:09] <tomreyn> So then I guess we don't actually need the grey lines.
[00:10] <tomreyn> we also have the per release 'official flavours' links above the tables, that covers it.
[00:10] <tomreyn> more opinions?
[00:14] <sarnold> tsimonq2: hmm.. if a flavour's metapackage is missing, would do-release-upgrade remove the thing and any packages that no longer exist? or would it just carry over the old packages from the currently-installed release?
[00:18] <tsimonq2> There's a hardcoded list; it probably wouldn't *remove* it
[00:19] <tomreyn> so you'd end up with extra packages in   ubuntu-support-status --show-unsupported   's "No longer downloadable" paragraph?
[00:20] <tomreyn> hmm maybe i just made up a different scenario. keep discussing yours, i'll stand back.
[00:25] <tomreyn> so i think it's two questions: if you come from e.g. Mythbuntu on 16.04, and upgrade to 18.04, then there will be no longer a mythbuntu-desktop package (I just checked with rmadison, it exists in xenial but not bionic). does this mean that any packages which existed in 16.04 as part of the Mythbuntu installation (1) and still exist in the community maintained sections in 18.04  or (2) no longer exist in 18.04 at all    are removed?
[00:26] <tomreyn> tsimonq2: ^
[00:27] <tsimonq2> tomreyn: They are on the local system but not in the archive.
[00:27] <tsimonq2> bdmurray: Please confirm ^
[00:28] <tomreyn> uh, so effectively you grow vulnerabilities without an upgrade path?
[00:30] <TJ-> That's the usual result when packages are removed from the archive
=== paride7 is now known as paride
=== albert23` is now known as albert23
[10:21] <rbasak> seb128: ah, fair enough, sorry.
[10:22] <seb128> rbasak, no worry ;)
[15:49] <ddstreet> rbasak systemd from usd-import-team repo seems out of date; is the git-ubuntu importing paused until eoan is ready?
[15:50] <rbasak> ddstreet: it's known broken. I'm working on a fix.
[15:50] <ddstreet> ah
[15:50] <ddstreet> ok
[15:50] <ddstreet> thnx!
[15:50] <rbasak> (not eoan related)
[16:16] <tomreyn> a couple users were asking what to putinto the secure boot password prompt and whether they'd need to remember this password lately: https://i.stack.imgur.com/cCTiK.png
[16:17] <tomreyn> IMO, despite the "Learn more..." link this screen creates a serious issue for those users. Many will not keep the passphrase they enter there, will try to rmemeber it but forget it since they aren't ever prompted for it until they forgot.
[16:18] <tomreyn> (this image is from 16.04, but i assume it looks similar on later installations still)
[16:18] <tomreyn> It should at least say something like "this password is saved into your firmware and xyou need to store it in a secure place where you will find it in years from now.
[16:29] <rbasak> tomreyn: file a bug against ubiquity please?
[16:40] <tomreyn> will do
[17:09] <tomreyn> bug 1826026
[17:09] <ubottu> bug 1826026 in ubiquity (Ubuntu) "Secure Boot initialization UI needs improvements" [Undecided,New] https://launchpad.net/bugs/1826026
[17:15] <tomreyn> sarnold / tsimonq2 / bdmurray: should we file a bug about what we discussed here yesterday, too?
[17:16] <tomreyn> (unsupported packages may remain installed when release upgrading)
[17:17] <bdmurray> tomreyn: if its important to you sure
[17:22] <tomreyn> personally, i know how to recover form this, but most people we support in #uubntu don't even know they have such apckages, and that they could cause not just only dependency resolver but also security issues.
[17:22] <tomreyn> so i guess it's important to me, yes. ;-)
[17:54] <vorlon> seb128: hmm, my slow unlock screen has resurfaced; it's not linear w/ the number of notifications, but I'm not sure what it is
[18:10] <tomreyn> sarnold, tsimonq2: i tried to file what we discussed yesterday here: bug 1826044 - would appreciate any comments - thanks.
[18:10] <ubottu> bug 1826044 in ubuntu-release-upgrader (Ubuntu) "Packages unavailable in target release should be removed" [Undecided,New] https://launchpad.net/bugs/1826044
[18:11] <sarnold> tomreyn: wonderful! thanks
[18:11] <tomreyn> :) and thanks for your comment on 1826026, too.
[18:14] <sarnold> I hope it made sense
[18:49] <vorlon> infinity, stgraber, kees, mdeslaur: meeting today?
[18:49] <mdeslaur> sure
[18:51] <seb128> vorlon, but clearing the notifications fixes it?
[18:54] <vorlon> seb128: this time, no
[18:54] <vorlon> so I don't know what's going on or how to debug it
[18:54] <seb128> :-/
[18:54] <seb128> there is nothing special/no js warnings in the journal corresponding to the slowness?
[19:23] <vorlon> seb128: ok, found some evidence pointing to fprintd
[19:26] <seb128> vorlon, ah, nice!
[19:26] <vorlon> fsvo ;
[19:26] <vorlon> ;)