[14:59] <jawn-smith> o/
[14:59] <slyon> o/
[14:59]  * vorlon waves
[14:59] <ogayot> o/
[14:59] <bdmurray> o/
[15:00] <bdmurray> #startmeeting Weekly Ubuntu Foundations team
[15:00] <meetingology> Meeting started at 15:00:02 UTC.  The chair is bdmurray.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:00] <dbungert> o/
[15:00] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:00] <sil2100> o/
[15:00] <bdrung> o/
[15:01] <bdmurray> The team's update has been posted herehttps://discourse.ubuntu.com/t/foundations-team-updates-thursday-28-april-2022/28035
[15:02] <bdmurray> Let's take a moment to review and ask any questions
[15:04] <bdmurray> vorlon: how is the opening of Kinetic going?
[15:04] <vorlon> well, I don't know where the autopkgtests for base-files are going
[15:04] <vorlon> which we need to get in the release pocket, along with debootstrap, before we move along further
[15:05] <bdmurray> all right
[15:05] <bdmurray> Any other questions?
[15:06] <vorlon> ah base-files autopkgtest results seem to actually be coming in now https://autopkgtest.ubuntu.com/packages/b/bash/kinetic/amd64
[15:06] <bdmurray> #topic Release Incoming Bugs
[15:06] <bdmurray> I think it's premature to look at the rls-kk report but it has been created
[15:06] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html#foundations-bugs
[15:07] <bdmurray> bug 1968997 is already carded so just needs the tag removed and targetting
[15:07] <bdmurray> bug 1969810
[15:07] <bdmurray> schopin: ^
[15:08] <schopin> This needs some upstream work, and is a security concern.
[15:08] <bdmurray> Okay, let's card it then
[15:09] <bdmurray> bug 1962751
[15:09] <bdmurray> I'm pretty sure we tested this machine at the sprint last week
[15:09] <bdmurray> and it wasn't an issue
[15:09] <sil2100> Was that a Z-Book?
[15:09] <bdmurray> given that and sil2100's test let's untag it
[15:10] <sil2100> Yeah, we saw no other reports during and after the release, so +1
[15:10] <bdmurray> bug 1962454
[15:11] <bdmurray> The desktop team is pretty keen to see this done so let's card it
[15:11] <bdmurray> bug 1969394
[15:12] <bdmurray> vorlon: what do you think about the last comment there?
[15:12] <jawn-smith> I just created a new bug and tagged it as rls-jj-incoming
[15:12] <bdmurray> well we already have too many
[15:13] <vorlon> it's true that it requires design work, and is not a "release issue" in the sense of something to try to get done by release day, but the comment was added a week after release, so :)
[15:13] <jawn-smith> so before we move to ii I'll have ubottu fetch it
[15:13] <vorlon> I don't want to drive fixing it
[15:13] <vorlon> so if that means we're declining, so be it
[15:13] <bdmurray> Well we could tag it for the next LTS
[15:14] <bdmurray> Is that NN?
[15:14] <bdmurray> bug 1968912
[15:14] <bdmurray> That looks rather ugly but seems low priority
[15:15] <bdmurray> so I'll update the importance
[15:15] <bdmurray> Let's go ahead and set it to notfixing for jj
[15:16] <vorlon> does it affect noninteractive invocations of vi?
[15:16] <bdmurray> bug 1969464
[15:16] <bdmurray> vorlon: Oh, IDK
[15:16] <vorlon> if it does, that should be considered higher-severity
[15:17] <bdrung> i vaguely remember seeing that error message.
[15:17] <sil2100> hmmm
[15:18] <bdmurray> So we should finish that casper bug
[15:18] <bdmurray> Let's card it
[15:18] <bdmurray> bug 1970402
[15:18] <vorlon> I don't mind it being carded, but reiterate that the root bug is a user ever having casper installed on a target system
[15:19] <sil2100> Yeah, I think the main issue to figure out there is why casper ended up installed, as we tried install tests in London and we never ended up with casper on our systems
[15:19] <bdmurray> Is there a way to better convey that?
[15:19] <vorlon> well, I have just marked the bug incomplete, since I asked the user for logs and haven't gotten them
[15:19] <sil2100> I think carding the bug is enough, as comments from Steve are in the bug
[15:20] <vorlon> initramfs-tools: aren't our compression defaults in jammy supposed to use less memory?
[15:20] <bdmurray> I didn't recall when I tagged it
[15:20] <waveform> vorlon, the zstd default was changed from -19 to -1 which should use substantially les
[15:21] <waveform> *less
[15:21] <bdmurray> and they had the latest version of initramfs-tools
[15:22] <bdmurray> so let's leave that incomplete but keep an eye out for other reports
[15:22] <vorlon> and the error is at boot time hmm
[15:22] <bdmurray> bug 1896772
[15:23] <bdmurray> vorlon: you'd tagged this one
[15:23] <slyon> there is an easy reproducer for this issue, and a (partial?) fix for the permission issue in ifupdown.
[15:23] <vorlon> oh had I
[15:23] <bdmurray> I think we'd talked about it before release week
[15:24] <vorlon> ok
[15:24] <vorlon> yeah I don't have any insight into the actual bug, but the description is serious and warrants investigation
[15:24] <bdmurray> Okay so let's card that then
[15:24] <slyon> I agree, we should investigate how it affects the other two packages
[15:25] <bdmurray> bug 1959475 enr0n tagged this one
[15:26] <enr0n> Yeah, I had not had time to actually test thi, but there was upstream activity and a patch
[15:26] <enr0n> test this*
[15:26] <slyon> interestingly the referenced upstream commit, that supposedly fixes the issue is already included in v249
[15:26] <enr0n> I think there is another one further down
[15:26] <slyon> err.. i clicked the wrong link.
[15:27] <slyon> hmm seems like this is mostly a Focal issue, right @enr0n ?
[15:27] <enr0n> Or maybe it just needs to be SRU'd
[15:27] <enr0n> Ha, yeah
[15:28] <bdmurray> Either way let's card it
[15:28] <slyon> So let's target to Focal and card it.
[15:28] <bdmurray> bug 1968845
[15:29] <jawn-smith> waveform: could this be related to the debhelper changes you worked on?
[15:30] <bdmurray> sarnold also pointed at the snapd bug
[15:30] <waveform> erm ... I don't *think* so off the top of my head as that was preventing debhelper from auto-restarting dbus on upgrade. This is doing what it *should* which is upgrade dbus but leave the existing daemon running
[15:30] <bdmurray> So I think we should test this again to see if it is still valid
[15:30] <bdmurray> I'll test that today
[15:31] <bdmurray> bug 1969375
[15:31] <bdmurray> enr0n: ^
[15:32] <enr0n> Yeah debian enabled this in 250, so maybe we just get it in kk. But it seemed like something to consider for LTS
[15:32] <bdmurray> I guess that is something we could just add to the Jammy SRU list for systemd
[15:32] <slyon> IMO this is something we can include with the next systemd merge, but not enable this after feature freeze in jammy
[15:32] <slyon> do we SRU new features?
[15:33] <bdmurray> For hardware support
[15:33] <slyon> ack
[15:33] <vorlon> not super useful to have enabled in jammy, we don't have a cryptographically-secure measured boot path
[15:34] <bdmurray> Okay, then let's untag it
[15:35] <bdmurray> bug 1969786
[15:36] <bdmurray> In this one ubuntu-desktop got removed somehow
[15:36] <enr0n> Yeah
[15:38] <bdmurray> let's card that for juliank to have a look at
[15:38] <bdmurray> jawn-smith: you have something for us?
[15:38] <jawn-smith> bug 1970761
[15:39] <bdmurray> jawn-smith: which "older releases"?
[15:39] <jawn-smith> great question: waveform?
[15:41] <waveform> I would assume "anything older than jammy"; block is definitely in hirsute+impish, *may* be in focal but either way should be removed
[15:41] <bdmurray> The reason I ask is there may need to be 2 quirks one for each release from which you are upgrading. Regardless, that's an implementation detail and let's just fix it.
[15:42] <bdmurray> Also please remember to set importances for bug tasks so we can better prioritze
[15:42] <bdmurray> pi-oritize
[15:43] <bdmurray> rls-ii is empty
[15:43] <bdmurray> and we should probably stop looking at it rather soon
[15:43] <jawn-smith> \o/
[15:44] <bdmurray> #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[15:44] <bdmurray> bug 1970411
[15:45] <bdmurray> It looks like the desktop team is working on that so skip
[15:45] <bdmurray> and we already talked about machinectl
[15:45] <bdmurray> so next topic
[15:45] <bdmurray> #topic Team proposed-migration report
[15:45] <bdmurray> vorlon:
[15:46] <vorlon> #link https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:46] <vorlon> we're still in the process of opening the archive, so nothing to be done here
[15:46] <vorlon> once we get base-files and debootstrap through, the fun begins
[15:46] <vorlon> but nothing else to say on this right now :)
[15:46] <bdmurray> #topic AOB
[15:47] <jawn-smith> my half day for today got cancelled, so you're stuck with me all day
[15:48] <bdmurray> okay, thanks everybody
[15:48] <bdmurray> #endmeeting
[15:48] <meetingology> Meeting ended at 15:48:49 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-04-28-15.00.moin.txt


[04:28] <emdub> anyone awake familiar with the upgrade process with a local mirror?  i'm able to do an upgrade successfully, but have always wondered what the "no valid mirror" thing is about when running do-release-upgrade, if there is something in my apt-mirror i am not mirroring properly or something?
[04:30] <emdub> this is what i see: http://pastie.org/private/wwzjnnc41hodygwqh1tgqq
[04:31] <emdub> again, everything seems to work, just wondering if there is a way to clean up those errors
[10:33] <xnox> does ubi-prepare.py plugin actually uses ubuntu-drivers to activate wifi drivers/firmware during non-oem install & hence improve chances of activating wifi in ubi-wireless step?
[11:14] <xnox> mpt: looking at the new connect to the internet step https://docs.google.com/a/surgut.co.uk/document/preview?id=1bZ4yQIVgGaUGSYu3qiUHnQt3ieBZoqunP_DcleHCr3I#heading=h.1if37baf38j0
[11:15] <xnox> there is something that doesn't quite fit.
[11:15] <xnox> "Install Driver Now" - actually means that the driver is third-party & proprietary (otherwise it would be included in our kernel by default)
[11:16] <xnox> but there are no legal warning about that & by default we should not encourage third-party software (Ubuntu Technical Board resolution)
[11:17] <xnox> Also I've checked other bugs and people complain about keyboard layouts not setup for wifi passwords...
[11:18] <xnox> maybe moving the keyboard early would be also appropriate to fix: wifi & crypto passwords?!
[11:27] <stgraber> you could even argue that the keyboard dialog should be shown first as we have a text field on ubi-language (OEM tag) that may need the proper layout to be configured
[11:27] <stgraber> though I'd tend to prefer having the oem field moved to ubi-usersetup or similar as it always looked a bit weird on ubi-language and having the keyboard layout dialog first would be really weird
[11:27] <cjwatson> But the keyboard dialog's defaults depend on language (and timezone)
[11:28] <cjwatson> Moving the oem field would make a degree of sense, yes
[11:28] <cjwatson> The wifi vs. keyboard thing is unresolvable by reordering; that's why we have the keyboard indicator
[11:29] <stgraber> except that the indicator can only show you the 4 most likely layout based on language (because of a stupid X limitation) so in a lot of cases it's not terribly useful...
[11:29] <cjwatson> Well, yeah, but I mean the general idea
[11:31] <stgraber> but yeah, no amount of reordering will fix the problem for good as we have input fields everywhere... one option would be to always show an icon that lets you jump to the keyboard page and then back to where you were but I'm not sure it's worth the effort at this point
[11:32] <stgraber> especially as gfxboot lets you override the layout anyway
[11:33] <cjwatson> Although we try not to show you the gfxboot menu by default
[11:33] <cjwatson> It all sucks
[11:33] <cjwatson> One way or another
[11:34] <xnox> *sigh*
[11:35] <xnox> and the broadcom&etc wifi drivers?
[11:36] <xnox> currently we offer to install updates (grayed out if no network) and the bundle of (drivers + restricted-addons), then open/show wifi settings...
[11:37] <xnox> moving wifi settings before the prepare step, may require taking wifi drivers with us, but then the drivers will be split into two: wifi & graphics....
[11:40] <cjwatson> xnox: The TB decision you refer to was specifically about non-driver software
[11:41] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-March/000834.html
[11:42] <xnox> cjwatson: so it should be ok to run ubuntu-drivers autoinstall by default, unless we are booted in the free software only mode?
[11:43] <xnox> reading the "Software installed by default" http://www.ubuntu.com/project/about-ubuntu/licensing seems appropriate.
[11:43] <xnox> plus ubuntu-drivers will only install necessary stuff.
[11:45] <cjwatson> xnox: You should talk about that with the kernel team; I expect there are cases where automatically installing proprietary drivers is harmful, not least to our ability to diagnose kernel bugs
[11:45] <cjwatson> Legal reasons aren't the only ones why those drivers are opt-in
[11:47] <xnox> cjwatson: right. Currently we have checkbox which bundles: restricted-addons and all ubuntu-drivers.
[11:47] <xnox> there is a suggestion to move the wifi step before prepare, but that may need wifi drivers.
[11:47] <xnox> but not the rest.
[11:48] <cjwatson> Which is the result of a series of careful compromises, so talk about it fairly widely before changing it, would be my recommendation ...
[11:48] <cjwatson> But I should get back to working out how to get CI working :)
[11:48] <xnox> and generally if you need a wifi driver, there is no options.... you won't have the internetz....
[11:49] <xnox> cjwatson: ok. I will publicize it.
[11:50] <cjwatson> Broadcom drivers are tricky
[11:50] <cjwatson> My wife's laptop used to crash if you used the one that jockey offered
[11:50] <cjwatson> But it was fine if you shovelled in the firmware necessary to make b43 work
[11:50] <cjwatson> (I think it was that way round)
[11:50] <cjwatson> It was better to not have network during installation than to have it crash solid
[11:52] <xnox> so how about switch wifi step before prepare, such all people with normal wifi's can install updates while installing. And those with crippled wifi cards will be left without network. Which is an improvement for the general & free case, over let's cripple everyone because of some cripped wifis.
[11:53] <xnox> ...or we can show network page twice.
[11:53] <cjwatson> Don't we show a network-manager indicator or something?
[11:54] <xnox> yeah we do.... no usability studies to see if it's discoverable by new users though.
[11:54] <xnox> we could attempt to show wireless page twice.
[11:54] <xnox> If there is wifi card - show before prepare step.
[11:55] <xnox> If no wifi card go to prepare & show it after prepare page instead.....
[11:55] <xnox> but that won't give you the "install updates checkbox" =(
[11:55] <xnox> with proprietary card.
[18:38]  * xnox ponders about 512MB servers and zram-config
[18:39]  * infinity is reminded that he needs to move zram-config into initramfs-tools.
[18:43] <xnox> ogra_: ^^^
[18:43] <ogra_> infinity, ++